Subject: Re: [Capwap] Proposed Text for Issue 244 (was: Closure of Issue 244)

From: "Abhijit Choudhury (achoudhu)" <[email-masked]>
Date: Fri, 11 May 2007 16:24:38 -0700

Hi Pat,

I would like to propose some minor changes in the text
that you had sent out. They are mostly editorial in
nature.
 
The basic change is that I think it's confusing
if we call the CAPWAP preamble a header. It's
really a field (or 2 fields) that is embedded in
the CAPWAP DTLS header and the CAPWAP header. Also,
I have updated the figure on CAPWAP Plain Text Data Packet
to make it consistent with the text.

Thanks,
Abhijit
 
------------------------------------------------------------------------
-----
<proposed text>

4.  CAPWAP Packet Formats

   This section contains the CAPWAP protocol packet formats.  A CAPWAP
   protocol packet consists of one or more CAPWAP Transport Layer packet
   headers followed by a CAPWAP message.  The CAPWAP message can be
   either of type Control or Data, where Control packets carry
   signaling, and Data packets carry user payloads.  The CAPWAP frame
   formats for CAPWAP Data packets, and for DTLS encapsulated CAPWAP
   Data and Control packets are defined below.

   The CAPWAP Control protocol includes two messages that are never
   protected by DTLS: the Discovery Request message and the Discovery
   Response message.  These messages need to be in the clear to allow
   the CAPWAP protocol to properly identify and process them.  The
   format of these packets are as follows:

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

   All other CAPWAP control protocol messages MUST be protected via the
   DTLS protocol, which ensures that the packets are both authenticated
   and encrypted.  These packets include the CAPWAP DTLS Header, which
   is described in Section 4.2.  The format of these packets is as
   follows:

    CAPWAP Control Packet (DTLS Security Required):
    +------------------------------------------------------------------+
    | IP  | UDP | CAPWAP   | DTLS | CAPWAP | Control| Message   | DTLS |
    | Hdr | Hdr | DTLS Hdr | Hdr  | Header | Header | Element(s)| Trlr |
    +------------------------------------------------------------------+
                           \---------- authenticated -----------/
                                  \------------- encrypted ------------/

   The CAPWAP protocol allows optional protection of data packets, using
   DTLS.  Use of data packet protection is determined by AC policy.
   When DTLS is utilized, the optional CAPWAP DTLS Header is present,
   which is described in Section 4.2.  The format of CAPWAP data packets
   is shown below:

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

       DTLS Secured CAPWAP Data Packet:
       +--------------------------------------------------------+
       | IP  | UDP |  CAPWAP  | DTLS | CAPWAP | Wireless | DTLS |
       | Hdr | Hdr | DTLS Hdr | Hdr  |  Hdr   | Payload  | Trlr |
       +--------------------------------------------------------+
                              \------ authenticated -----/
                                     \------- encrypted --------/

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

   CAPWAP DTLS Header:  All DTLS encrypted CAPWAP protocol packets are
      prefixed with the CAPWAP DTLS header (see Section 4.2).

   DTLS Header:  The DTLS header provides authentication and encryption
      services to the CAPWAP payload it encapsulates.  This protocol is
      defined in RFC 4347 [8].

   CAPWAP Header:  All CAPWAP protocol packets use a common header that
      immediately follows the CAPWAP preamble or DTLS header.  The
      CAPWAP Header is defined in Section 4.3.

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

   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.5.1.
      CAPWAP data packets do not contain a Control Header field.

   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.6.

   A CAPWAP implementation MUST be capable of receiving a reassembled
   CAPWAP message of length 4096 bytes.  A CAPWAP implementation MAY
   indicate that it supports a higher maximum message length, by
   including the Maximum Message Length message element, see
   Section 4.6.29 in the Join Request message or the Join Response
   message.

4.1.  CAPWAP Preamble

   The CAPWAP preamble is common to all CAPWAP transport headers and
   is used to identify the header type that immediately follows.  The
   reason for this header is to avoid needing to perform byte
   comparisons in order to guess whether the frame is DTLS encrypted or
   not.  It also provides an extensibility framework that can be used to
   support additional transport types.  The format of the preamble is as
   follows:

         0
         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
        |Version| Type  |
        +-+-+-+-+-+-+-+-+

   Version:  A 4 bit field which contains the version of CAPWAP used in
      this packet.  The value for this specification is zero (0).

   Payload Type:  A 4 bit field which specifies the payload type that
      follows the UDP header.  The following values are supported:

      0 -  CAPWAP Header.  The CAPWAP Header (see Section 4.3)
         immediately follows the UDP header.  If the packet is received 
         on the CAPWAP data channel, the CAPWAP stack MUST treat the 
         packet as a clear text CAPWAP data packet.  If received on the 
         CAPWAP control channel, the CAPWAP stack MUST treat the packet 
         as a clear text CAPWAP control packet.  If the control packet 
         is not a Discovery Request or Discovery Response packet, the 
         packet MUST be dropped.

      1 -  CAPWAP DTLS Header.  The CAPWAP DTLS Header, and DTLS packet,
         immediately follows the UDP header (see Section 4.2).

4.2.  CAPWAP DTLS Header

   The CAPWAP DTLS Header is used to identify the packet as a DTLS
   encrypted packet.  The first eight bits includes the common CAPWAP
   Preamble.  The remaining 24 bits are padding to ensure 4 byte
   alignment, and MAY be used in a future version of the protocol.  The
   DTLS packet [8] always immediately follows this header.  The format
   of the CAPWAP DTLS Header is as follows:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |CAPWAP Preamble|                    Reserved                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   CAPWAP Preamble:  The CAPWAP Preamble is defined in Section 4.1.  The

      CAPWAP Preamble's Payload Type field MUST be set to one (1).

   Reserved:  The 24-bit field is reserved for future use.  All
      implementations complying with this protocol MUST set to zero any
      bits that are reserved in the version of the protocol supported by
      that implementation.  Receivers MUST ignore all bits not defined
      for the version of the protocol they support.

4.3.  CAPWAP Header

   All CAPWAP protocol messages are encapsulated using a common header
   format, regardless of the CAPWAP Control or CAPWAP Data transport
   used to carry the messages.  However, certain flags are not
   applicable for a given transport.  Refer to the specific transport
   section in order to determine which flags are valid.

   Note that the optional fields defined in this section MUST be present
   in the precise order shown below.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |CAPWAP Preamble|  HLEN   |   RID   | WBID    |T|F|L|W|M|K|Flags|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Fragment ID          |     Frag Offset         |Rsvd |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 (optional) Radio MAC Address                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            (optional) Wireless Specific Information           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Payload ....                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   CAPWAP Preamble:  The CAPWAP Preamble is defined in Section 4.1.  The

      CAPWAP Preamble's Payload Type field MUST be set to zero (0).  If 
      the CAPWAP DTLS Header is present, the version number in both 
      CAPWAP Preambles MUST match.  The reason for this duplicate field 
      is to avoid any possible tampering of the version field in the 
      preamble which is not encrypted or authenticated.

   HLEN:  A 5 bit field containing the length of the CAPWAP transport
      header in 4 byte words (Similar to IP header length).  This length
      includes the optional headers.

   RID:  A 5 bit field which contains the Radio ID number for this
      packet.  Given that MAC Addresses are not necessarily unique
      across physical radios in a WTP, the Radio Identifier (RID) field
      is used to indiciate which physical radio the message is
      associated with.

   WBID:  A 5 bit field which is the wireless binding identifier.  The
      identifier will indicate the type of wireless packet associated 
      with the radio.  The following values are defined:

      1 -  IEEE 802.11

      2 -  IEEE 802.16

      3 -  EPCGlobal

   T: The Type 'T' bit indicates the format of the frame being
      transported in the payload.  When this bit is set to one (1), the
      payload has the native frame format indicated by the WBID field.
      When this bit is zero (0) the payload is an IEEE 802.3 frame.

   F: The Fragment 'F' bit indicates whether this packet is a fragment.
      When this bit is one (1), the packet is a fragment and MUST be
      combined with the other corresponding fragments to reassemble the
      complete information exchanged between the WTP and AC.

   L: The Last 'L' bit is valid only if the 'F' bit is set and indicates
      whether the packet contains the last fragment of a fragmented
      exchange between WTP and AC.  When this bit is 1, the packet is
      the last fragment.  When this bit is 0, the packet is not the last
      fragment.

   W: The Wireless 'W' bit is used to specify whether the optional
      Wireless Specific Information field is present in the header.  A
      value of one (1) is used to represent the fact that the optional
      header is present.

   M: The M bit is used to indicate that the Radio MAC Address optional
      header is present.  This is used to communicate the MAC address of
      the receiving radio.

   K: The 'Keep-alive' K bit indicates the packet is a Data Channel Keep
      Alive packet.  This packet is used to map the data channel to the
      control channel for the specified Session ID and to maintain
      freshness of the data channel.  The K bit MUST NOT be set for data
      packets containing user data.

   Flags:  A set of reserved bits for future flags in the CAPWAP header.
      All implementations complying with this protocol MUST set to zero
      any bits that are reserved in the version of the protocol
      supported by that implementation.  Receivers MUST ignore all bits
      not defined for the version of the protocol they support.

</text>

________________________________

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, April 23, 2007 6:40 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Capwap] Closure of Issue 244

Dear WG: 

Based on the WG response to re-open Issue 244:  Preamble Header
Optimization, this issue will be moved to the active issues database and
resolved with the solution proposed in:
http://lists.frascone.com/pipermail/capwap/msg04161.html
<http://lists.frascone.com/pipermail/capwap/msg04161.html> 

There were some objections to resolve since its late to consider
optimizations at this stage of the draft, however most responses were in
favor of adding the change.

Issue 244 will be reflected in the updates to the CAPWAP drafts during
upcoming WGLC. 

If there are no further comments by Thursday, April 26th, Issue 244 will
be moved to the active database and closed as agreed by consensus.

Best Regards, 
Mani, Margaret and Dorothy 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 14 May 2007 12:00:02 -0700

Created issue 261 to track this issue.

I have no issues with the proposed resolution.

PatC 

-----Original Message-----
From: Abhijit Choudhury (achoudhu) 
Sent: Friday, May 11, 2007 4:25 PM
To: Pat Calhoun (pacalhou); [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Capwap] Proposed Text for Issue 244 (was: Closure of Issue
244)

Hi Pat,

I would like to propose some minor changes in the text that you had sent
out. They are mostly editorial in nature.
 
The basic change is that I think it's confusing if we call the CAPWAP
preamble a header. It's really a field (or 2 fields) that is embedded in
the CAPWAP DTLS header and the CAPWAP header. Also, I have updated the
figure on CAPWAP Plain Text Data Packet to make it consistent with the
text.

Thanks,
Abhijit

4.  CAPWAP Packet Formats

4.1.  CAPWAP Preamble

         0
         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
        |Version| Type  |
        +-+-+-+-+-+-+-+-+

4.2.  CAPWAP DTLS Header

        0                   1                   2                   3

4.3.  CAPWAP Header

        0                   1                   2                   3

      1 -  IEEE 802.11

      2 -  IEEE 802.16

      3 -  EPCGlobal

</text>

Dear WG: 

Best Regards,