| Re: Proposed Text for Issue 244 (was: Closure of Issue 244) | <– Date –> <– Thread –> |
From: Pat Calhoun (pacalhou) (pcalhoun cisco.com)
|
|
| Date: Mon, 14 May 2007 12:02:11 -0700 (PDT) | |
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); Dorothy.Gellert [at] nokia.com;
capwap [at] frascone.com
Cc: margaret [at] thingmagic.com; rbonica [at] juniper.net
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
------------------------------------------------------------------------
-----
<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: Dorothy.Gellert [at] nokia.com [mailto:Dorothy.Gellert [at] nokia.com]
Sent: Monday, April 23, 2007 6:40 PM
To: capwap [at] frascone.com
Cc: margaret [at] thingmagic.com; rbonica [at] juniper.net
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
- Re: Proposed Text for Issue 244 (was: Closure of Issue 244), (continued)
- Re: Proposed Text for Issue 244 (was: Closure of Issue 244) Abhijit Choudhury (achoudhu), April 24 2007
-
Re: Proposed Text for Issue 244 Jim Murphy, April 24 2007
- Re: Proposed Text for Issue 244 Jim Murphy, April 24 2007
-
Re: Proposed Text for Issue 244 (was: Closure of Issue 244) Abhijit Choudhury (achoudhu), May 11 2007
- Re: Proposed Text for Issue 244 (was: Closure of Issue 244) Pat Calhoun (pacalhou), May 14 2007
- Re: Proposed Text for Issue 244 (was: Closure of Issue 244) Pat Calhoun (pacalhou), July 18 2007
Results generated by Tiger Technologies using MHonArc.