Capwap Mailing List: Re: FW: Proposed Text for Issue 254

[Abhijit Choudhury (achoudhu) (achoudhu]

Hi Sudhanshu,

 

I was trying to first define the notion that the control

or data channel refers to a 5-tuple without specifying what

the transport is.  Later in the Transport

section, the specifics are nailed down:

the Protocol is defined to be UDP or UDP-Lite

and the ports to be well-known or not. Since the Terminology

section comes at the beginning of the document, it doesn't

seem like the right place to define in detail like you

are proposing.

 

So, based on this, would you like to suggest some changes to

(1) that you'd be satisfied with ?

 

Thanks,

Abhijit

 

 

 

---

From: Sudhanshu [mailto:sudhanshu.ietf [at] gmail.com]
Sent: Tuesday, April 17, 2007 1:40 PM
To: Pat Calhoun (pacalhou); Abhijit Choudhury (achoudhu); 'capwap'
Subject: RE: [Capwap] FW: Proposed Text for Issue 254

Abhijit/Pat,

 

I am ok with changes 3 and 4.

 

For change #1, I think definition is not sufficient.

 

• Define the control (and also data) channel is between WTP IP address, AC IP address, IP Protocol, well known port at AC and WTP assigned (or well know UDP) port at WTP.
• It may be good idea to define the well know UDP port also as part of terminology, as it is referred in the previous definition.
• It may be good idea also to define the WTP IP address here, as it may be different than section 4.5.52.

 

For change #2, there is no point of repeating the definition again. Instead it should refer to term “CAPWAP Control Channel” and “CAPWAP Data Channel “ in section 1.4

 

_Suds

 

---

From: Pat Calhoun (pacalhou) [mailto:pcalhoun [at] cisco.com]
Sent: Monday, April 16, 2007 3:03 AM
To: Abhijit Choudhury (achoudhu); capwap
Subject: Re: [Capwap] FW: Proposed Text for Issue 254

 

Does anyone have any issues with the adoption of the proposed text below?

 

PatC

 

---

From: Abhijit Choudhury (achoudhu)
Sent: Friday, April 13, 2007 2:15 PM
To: capwap
Subject: [Capwap] FW: Proposed Text for Issue 254

The changes to resolve issue 254 (see below) seems to be missing from

version 06 of the capwap protocol spec.

 

 

Thanks,

Abhijit

 

 

 

 

---

From: Abhijit Choudhury (achoudhu)
Sent: Wednesday, April 04, 2007 12:57 PM
To: capwap; Pat Calhoun (pacalhou); Puneet Agarwal
Subject: Re: [Capwap] Proposed Text for Issue 254

While trying to address Issue 254, I realized that there are a number of

places in the CAPWAP protocol spec that we need to fix.

I also noticed that in the spec, we start using "data channel"

and "control channel" without defining what they are.

 

I propose the following changes:

 

1. Add the following to Terminology (Section 1.4)

 

      CAPWAP Control Channel:  A connection defined by (WTP-IP-Addr, AC-IP-Addr,

        IP Protocol, WTP-Control-Layer4Port, AC-Control-Layer4Port) over which CAPWAP control 

        packets are sent.

 

        CAPWAP Data Channel:  A connection defined by (WTP-IP-Addr, AC-IP-Addr,

        WTP-Data-Layer4Port, IP Protocol, AC-Data-Layer4Port) over which CAPWAP data packets

        are sent.
 

2. In Section 3.1

    Replace

        CAPWAP protocol control packets sent between the WTP and the AC use
        well known UDP port [to be IANA assigned].  CAPWAP protocol data
        packets sent between the WTP and the AC use UDP port [to be IANA
        assigned].

    With
         CAPWAP protocol control packets sent from the WTP to the AC use
         well known UDP port [to be IANA assigned] at the AC and any

         port selected by the implementation at the WTP. CAPWAP protocol data
         packets sent from the WTP to the AC use UDP port [to be IANA
         assigned] at the AC and any port selected by the implementation 

         at the WTP. In either case, for packets sent by the AC to the WTP, 
         the source and destination ports are reversed.

3. In Section 4.1

    Replace

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

 

          0 -  Clear text.  If the packet is received on the data UDP port,
             the CAPWAP stack MUST treat the packet as a clear text CAPWAP
             data packet.  If received on the control UDP port, the CAPWAP
             stack MUST treat the packet as a clear text CAPWAP control
             packet.  If the control packet is not a Discovery Request or
             Response packet, the packet MUST be dropped.

 

          1 -  DTLS Payload.  The packet is a DTLS packet and MAY be a data
             or control packet, based on the UDP port it was received on
             (see Section 3.1).

 

    With

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

 

          0 -  Clear text.  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
             Response packet, the packet MUST be dropped.

 

          1 -  DTLS Payload.  The packet is a DTLS packet and MAY be a data
             or control packet, based on the channel it was received on
             (see Section 3.1).

 

 

4. In Section 4.3

   Replace

      Both CAPWAP data messages are transmitted on the data channel UDP port.

   With

       Both CAPWAP data messages are transmitted on the data channel.

Thanks,

Abhijit