| Re: Proposed Text for Issue 244 (was: Closure of Issue 244) | <– Date –> <– Thread –> |
From: Pat Calhoun (pacalhou) (pcalhoun cisco.com)
|
|
| Date: Wed, 25 Apr 2007 08:51:36 -0700 (PDT) | |
Would there be any objections to not changing the figure, but including
the following text? The issue is living within the 74 character limit,
which is a challenge with ASCII artwork. I could add the '*' as proposed
by Abhijit, but it is clumsy.
<proposed text>
UDP Header: All CAPWAP packets are encapsulated within either UDP,
or UDP-Lite when used over IPv6. Section Section 3 defines the
specific UDP or UDP-Lite usage.
</proposed text>
PatC
-----Original Message-----
From: Abhijit Choudhury (achoudhu)
Sent: Tuesday, April 24, 2007 4:43 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)
Some text changes are needed as well:
Replace
UDP Header: All CAPWAP packets are encapsulated within UDP. Section
Section 3 defines the specific UDP usage.
With
UDP/UDP-Lite Header: All CAPWAP packets are encapsulated within UDP
(for IPv4)
or UDP-Lite (for IPv6). Section 3 defines the specific UDP or
UDP-Lite usage.
Thanks,
Abhijit
-----Original Message-----
From: Pat Calhoun (pacalhou)
Sent: Tuesday, April 24, 2007 4:03 PM
To: Dorothy.Gellert [at] nokia.com; capwap [at] frascone.com
Cc: margaret [at] thingmagic.com; rbonica [at] juniper.net
Subject: [Capwap] Proposed Text for Issue 244 (was: Closure of Issue
244)
Given that, I would like to send the proposed text to the list. Please
note that it is nearly identical to Jim's original text, with a couple
of very small tweaks, which I believe are necessary given the change in
direction. These are all editorial in nature.
<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 | CAPWAP | Wireless |
| Hdr | Hdr | Preamble| 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
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 encrytion
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 header common to all CAPWAP transport headers and
is used to identify the header type that immediately follows. The
reason for this header to is 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 frame 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 preamble header. The following values are supported:
0 - CAPWAP Header. The CAPWAP Header (see Section 4.3)
immediately follows the the CAPWAP Preamble 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 CAPWAP Preamble 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 Header. 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 header is defined in
Section 4.1. The CAPWAP Preamble Header'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 header is defined in
Section 4.1. The CAPWAP Preamble Header's Payload Type field MUST
be set to zero (0). If the CAPWAP DTLS Header is present, the
version number in both CAPWAP Preamble Headers MUST match. The
reason for this duplicate field is to avoid any possible tampering
of the version field in the preamble header 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 type
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>
Comments please,
PatC
________________________________
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) Abhijit Choudhury (achoudhu), April 24 2007
- Re: Proposed Text for Issue 244 (was: Closure of Issue 244) Pat Calhoun (pacalhou), April 25 2007
Results generated by Tiger Technologies using MHonArc.