Subject: Re: [Capwap] Proposed text for issue resolution

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 22 Jun 2006 18:13:15 -0400 (EDT)

Hi Dorothy,

Dorothy Stanley wrote:
>All,
>
> Draft -02 of the CAPWAP protocol specification will be published shortly, and we are looking
> forward to resolving as many issues as possible in the next revision, -03, tentatively targeted
> for late August.
>
> With this  mail, we'd like to
>
> (1) Thank all those who have contributed proposed text for issue resolution to date.
> We'll be sending out a list of the issues that have been resolved in -02, and your contributions
> enabled forward progress on the draft.
>
> (2) Ask for volunteers to develop and post text reflecting the changes that would need to be made
>  to draft-02 to incorporate the proposed single port and dual port alternative solutions 
>
> (see issue 115,  "To MUX or not to MUX" and issue 82, "UDP port assignment(s) for control and
>  data traffic").
> 
> To date we have not seen proposed draft text for either alternative, and would like to avoid a
> situation where say at the end of July the WG has not seen and been able to review a reasonably
> solid draft of text that would need to be incorporated. Available text would also help quantify/define
> the work involved.
>
> Thank you,
> 
> The editors -Pat Calhoun, Mike Montemurro, Dorothy Stanley

Text for the single-port approach follows:
------------------------------------------------------------------------------------------------------
3.  CAPWAP Transport (No Change)

(no changes to introductory paragraph)

3.1.  UDP Transport (replaces existing text)

   Communication between a WTP and an AC is established according to the
   standard UDP client/server model.  A datagram protocol has the following
   advantages as compared to a connection-oriented protocol like TCP:

      o UDP provides the CAPWAP protocol with fine-grained control over retransmit
        timeouts, latency, responsiveness, etc. This is important both
        for control packets (e.g. echo request/response) and data
        packets (e.g. tunneled data packets carrying real-time protocols
        such as VoIP).

      o UDP provides for a lighter-weight implementation; a WTP need
        not implement a TCP stack if this is not desirable for
        other reasons.

      o The CAPWAP protocol is designed as a synchronous request-response protocol,
        so providing reliability at layer 4 is redundant

   CAPWAP protocol packets sent between the WTP and the AC use
   well known UDP port 12222.  

3.2   Transport Protocol Data Unit (new section)

   The CAPWAP protocol uses 3 distinct Transport Protocol Data Unit (Transport PDU)
   types:  Discovery, Control,  and Data. The Transport PDU type header is defined
   below in the CAPWAP Packet Formats section.

3.3.  AC Discovery

(no changes to current AC Discovery text)

3.4.  Fragmentation/Reassembly

(no changes to current frag/reassem text)

4.  CAPWAP Packet Formats

   This section contains the CAPWAP protocol packet formats.  A CAPWAP
   protocol packet consists of a CAPWAP Transport Layer packet header
   followed by a CAPWAP message.  The CAPWAP message can be of
   type Discovery, Control or Data, where Discovery packets are intended
   for discovering ACs on the network, Control packets carry signaling,
   and Data packets carry user payloads.  The frame formats for CAPWAP
   Discovery packets, Data packets, and for DTLS encapsulated CAPWAP
   Data and Control packets are as shown below:

  CAPWAP Discovery Packet:
  +-----------------------------------------------+
  | IP  |UDP |PDU | CAPWAP | Control | Message    |
  | Hdr |Hdr |Hdr | Header | Header  | Element(s) |
  +-----------------------------------------------+

  CAPWAP Data Packet :
  +--------------------------------------+
  | IP  |UDP  |PDU  | CAPWAP | Wireless  |
  | Hdr |Hdr  |Hdr  | Header | Payload   |
  +--------------------------------------+

  CAPWAP + Optional DTLS Data Packet Security:
  +----------------------------------------------------+
  | IP  |UDP |PDU | DTLS | CAPWAP  | Wireless | DTLS   |
  | Hdr |Hdr |Hdr | Hdr  | Hdr     | Payload  | Trailer|
  +----------------------------------------------------+
                  |<------authenticated------->|
                          |<---------encrypted--------->|

  CAPWAP Control Packet (DTLS Security Required):
  +----------------------------------------------------------------+
  | IP  |UDP |PDU | DTLS | CAPWAP | Control | Message    | DTLS    |
  | Hdr |Hdr |Hdr | Hdr  | Header | Header  | Element(s) | Trailer |
  +----------------------------------------------------------------+
                  |<--------authenticated--------------->|
                         |<--------------encrypted---------------->|

   UDP: All CAPWAP packets are encapsulated within UDP.  Section
      Section 3.1 defines the specific UDP usage.

   PDU Header: All CAPWAP protocol packets use a common Transport PDU
       header that immediately follows the UDP header. This
       header is defined in section 4.1

   CAPWAP Header: All CAPWAP protocol packets use a common transport 
      header that immediately follows the MUX header in unsecured
      packets, and the DTLS header in secured packets. The CAPWAP
      transport header is defined in Section 4.2.

   Wireless Payload: A CAPWAP protocol packet that contains a wireless
      payload is known as a data frame.  The CAPWAP protocol does not
      dictate the format of the wireless payload, which is defined by
      the appropriate wireless standard.  Additional information is in
      Section 4.3.

   Control Header: The CAPWAP protocol includes a signalling component,
      known as the CAPWAP control protocol.  All CAPWAP control packets
      include a Control Header, which is defined in Section 4.4.1.

   Message Elements: A CAPWAP Control packet includes one or more
      message elements, which are found immediately following the
      control header.  These message elements are in a Type/Length/value
      style header, defined in Section 4.5.

4.1 CAPWAP Transport PDU Header

   CAPWAP currently defines 3 distinct Transport PDU types: Discovery, 
   Control, and Data. The Transport PDU header is provided as a transport-independent
   way to delineate between these. 

   The functionality provided by the Transport PDU header currently only requires
   a few bits; however, it is defined as a 32-bit value for byte
   alignment. The least significant bits are currently
   defined:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     RESERVED                              | P |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The following values are defined for P (PDU type):

      0 - RESERVED (do not use) 
      1 - CAPWAP Control
      2 - CAPWAP Data
      3 - CAPWAP Discovery

   The reserved portion of the Transport PDU header MUST be all zeroes.  

(increment remaining 4.x subsections by one)

12.  NAT Considerations

  Since all CAPWAP protocol communication is UDP-based, is initiated by the WTP,
  and since CAPWAP provides a channel keepalive facility, the presence
  of a middlebox which translates the WTP address will be nearly
  transparent. The only requirement is that the EchoInterval timer is
  configured to be less than the NAT binding lifetime of the middlebox.

  NAT binding lifetimes are not standardized, and there is some
  variability in practice. For practical operational reasons, such 
  bindings are typically not less than 30 seconds, and frequently 
  are 60 seconds or more. Thus, setting the CAPWAP EchoInterval 
  timer to a value of 30 seconds or less should suffice in most
  situations. However, lack of standardization implies that some
  experimentation may be required under some circumstances. Hence,
  CAPWAP implementations MUST provide the ability to configure
  the EchoInterval timer in order to support NAT traversal.

  Note that some NAT devices may, under heavy load conditions,
  arbitrarily delete datagram NAT bindings. If this occurs, neither
  control nor data will pass until a new binding is created, and this
  requires a transmission from the WTP to the AC. Note that this is
  guaranteed to occur within no more than EchoInterval seconds, so 
  such binding losses, while certain to cause operational "blips"
  whenever they occur, are also self-healing.

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap