Subject: RE: [Capwap] Proposed Resolution for Issue 46 - WTP Model and Serialnumber

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 13 Apr 2006 06:18:22 -0700

Dorothy, if you could add the MAC address back into the attribute, then
I'm happy with the proposal.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Dorothy Stanley [mailto:[email-masked]] 
	Sent: Monday, April 10, 2006 1:21 PM
	To: capwap
	Subject: [Capwap] Proposed Resolution for Issue 46 - WTP Model
and Serialnumber

	All,
	
	Issue 46 - WTP Model and Serial number currently has the
following discussion in the issues list:

	The length of wtpModel in Section 7.2.4 is specified as 8 bytes.
I think this 
	space could be small for some model types. 
	
	Same way, 24 bytes WTP Serial Number could be small depending
upon how serial 

	number is assigned.

	Section 7.2.4, WTP Board Data
	
	The WTP model and serial number value lengths will vary with
product and vendor, and are likely
	to have a wide range of lengths. The current spec fixes the
lengths at
	model number - 8 bytes, and the serial number at 24 bytes. The
comment is that these fixed lengths
	are likely to be too small for some vendors.
	
	We could increase the fixed values, with the risk that the
values we select will not serve some vendor, or make
	them excessively long to meet all needs.
	Another approach is to give the model and serial number a
type/length value structure, including a vendor identifier, and
	allow a variety of lengths. 
	
	Additional comments on other WTP Board data fields:
	Need more explicit definition for  Card ID and Card Revision
values. For some vendors, these are not applicable. 
	If not generally applicable, leave as vendor specific. Indicated
these as optional to include, renaming to "board" from "card"
	to be consistent with the message element name. Can open a new
issue for this if needed.
	.
	WTP Board Data also includes the Ethernet MAC address. Why is
the layer 2 MAC address needed? Recommend 
	removing the Ethernet MAC address field from the WTP Board Data
message element (similar to AC MAC address
	in Issue 39)
	
	Recommendation: Change WTP Board Data definition from:
	
	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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
	
	|                       Card ID         |           Card
Revision                      |
	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
	|                                     WTP Model
|
	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
	|                                     WTP Model
| 
	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
	|                             WTP Serial Number
|
	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
	|                             WTP Serial Number
|
	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 
	|                             WTP Serial Number
|
	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
	|                             WTP Serial Number
|
	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
	|                             WTP Serial Number
|
	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
	|                             WTP Serial Number
|
	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 
	|                       Ethernet MAC Address
|
	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
	|                        Ethernet MAC Address|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++++
	
	Type: 50 for WTP Board Data
	 Length: 26 
	Card ID: A 2 byte hardware identifier. 
	Card Revision: A 2 byte Revision of the card. 
	WTP Model: 8 byte WTP Model Number. 
	WTP Serial Number: 24 byte WTP Serial Number. 
	Ethernet MAC Address: MAC Address of the WTP's Ethernet
interface. 
	
	to
	
	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

	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
	|                                Vendor Identifier
|
	 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|                  Type=0              |            Length
|
	 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
	|                                  Value.....

	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
	|                  Type=1              |            Length
|
	 +-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
	
	|                                  Value....

	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 
	| Optional additional vendor specific WTP board data TLVs

	Type: 50 for WTP Board Data
	Length: >= 3
	Vendor Identifier: A 32-bit value containing the IANA assigned
"SMI Network Management Private Enterprise Codes"
	Type: The following values are supported
	0 - WTP Model Number; The WTP Model Number MUST be included in
the WTP Board Data message element.
	1 - WTP Serial Number; The WTP Serial Number MUST be included in
the WTP Board Data message element.
	2 - Board ID; A  hardware identifier, which MAY be included in
the WTP Board Data message element.
	3 - Board Revision, A revision number of the board, which MAY be
included in the WTP Board Data message element.
	
	Length: The length of the value field
	
	Value: The value of the indicated field.
	
	The Vendor Identifier, WTP Model Number and WTP Serial Number
are optionally followed by additional 
	vendor specific values.
	
	Comments please.
	
	Thanks,
	
	Dorothy

_________________________________________________________________
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: Thu, 13 Apr 2006 06:15:08 -0700

This works for me as well.

Pat Calhoun

> -----Original Message-----
> From: David T. Perkins [mailto:[email-masked]] 
> Sent: Tuesday, April 11, 2006 10:06 PM
> To: Dorothy Stanley
> Cc: capwap
> Subject: Re: [Capwap] Proposed Resolution for Issue 46 - WTP 
> Model and Serialnumber
> 
> HI,
> 
> I believe that both the "WTP descriptor" (section 5.1.2) and 
> the "WTP Board data" (section 7.2.4) message elements need work.
> 
> Previous work has been done that covers both of these 
> elements is in RFC 4133, which contains the Entity MIB 
> module. In it, there are the following definitions which come 
> close the the info in the "WTP descriptor" and "WTP board date"
> message elements:
>   entPhysicalIndex - index of physical component (an integer)
>   entPhysicalVendorType - hardware type, value is an OID
>   entPhysicalHardwareRev - hardware revision, value encoded 
>                            in UTF-8 (max length of 255 octets)
>   entPhysicalFirmwareRev - firmware revision, (value encoded
>                            same as hardware rev)
>   entPhysicalSoftwareRev - software revision, (value encoded
>                            same as hardware rev)
>   entPhysicalSerialNum - serial number,- value encoded in 
>                            UTF-8 (max length of 32 octets)
>   entPhysicalMfgName - manufacturer name, (value encoded
>                            same as hardware rev)
>   entPhysicalModelName - model name, (value encoded
>                            same as hardware rev)
> 
> The entity MIB module allows all of the physical commponents 
> of a device to be described. I can't determine when reading section
> 7.2 (and section 7.2.4) whether or not multiple "WTP board data"
> message elements are returned. It's certainly the case that a 
> majority of current WTPs are "nonmodular", but there may be 
> ones that have "field replacable units" for radios or other 
> components. Thus, I suggest that multiple "board data" 
> message elements be returnable.
> 
> In addition the Entity MIB has the following definitions 
> which I suggest be supported by CAPWAP message "board data" 
> message element:
>   entPhysicalAssetID - asset ID, (value encoded
>                            same as serial number)
>   entPhysicalMfgDate - manufacture date, a date/time value
>                            encoded in format defined by
>                            TC DateAndTime found in RFC 2579
>   entPhysicalIsFRU - indication if component is a field
>                            replacable unit
>   entPhysicalUris - a list of URIs (the intent is to support 
>                            CLEI codes, see RFC 4152)
> 
> The Entity MIB also has the following definitions, which I 
> suggest are not too useful:
>   entPhysicalDescr - textual description of the component
>                            (its redundant with manufacturer
>                             and model name)
>   entPhysicalContainedIn - info on physical containment
>                            (WTPs don't have complex physical
>                             relationships of components)
>   entPhysicalParentRelPos - info on physical arrangement
>                            (WTPs don't have complex physical
>                             relationships of components)
>   entPhysicalClass - class of physical component (WTPs
>                             will not have different classes)
>   entPhysicalName - name used in CLI commands (not needed by
>                             CAPWAP)
>   entPhysicalAlias - an operator specified alternative name
>                             (not needed by CAPWAP)
> 
> Thus, I suggest that the "WTP info" and the "WTP Board data"
> message elements be change to the following to align with the 
> data model defined in the Entity MIB module:
> 
> WTP Info would have the following fields:
>  1) manufacturer name (encoded in UTF-8, max length 255 octets)
>  2) model name (same encoding as mgt name)
>  3) serial number (encoded in UTF-8, max length of 32 octets)
>  4) optional hardware rev (same encoding as mgt name)
>  5) optional manufacturing date (encoded in text, not binary
>                                  as defined in DateTime TC)
>  6) optional firmware rev (note: this is NOT the image
>     rev) (same encoding as mgt name)
>  7) optional asset ID (encoded the same as serial number)
>  8) boot software version (same encoding as mgt name)
>  9) list of images, with fields:
>     a) is running - flag
>     b) source - memory, store1, store2, etc
>     c) version (same encoding as mgt name)
>  10) Number of radios
> 
> "Board data" would be renamed "component data" and would only 
> be returned if the WTP contained separatably identifiable 
> components. It would have only fields
> 1 through 6 of WTP info, plus a "isFRU" field.
>  
> More on this later in the "boot model" description.
>  
> On Mon, 10 Apr 2006, Dorothy Stanley wrote:
> > All,
> > 
> > Issue 46 - WTP Model and Serial number currently has the following 
> > discussion in the issues list:
> > 
> > The length of wtpModel in Section 7.2.4 is specified as 8 bytes. I 
> > think this space could be small for some model types.
> > 
> > Same way, 24 bytes WTP Serial Number could be small 
> depending upon how 
> > serial
> > 
> > number is assigned.
> > 
> > 
> > The WTP model and serial number value lengths will vary 
> with product 
> > and vendor, and are likely to have a wide range of lengths. The 
> > current spec fixes the lengths at model number - 8 bytes, and the 
> > serial number at 24 bytes. The comment is that these fixed 
> lengths are 
> > likely to be too small for some vendors.
> > 
> values we 
> > select will not serve some vendor, or make them excessively long to 
> > meet all needs.
> type/length 
> > value structure, including a vendor identifier, and allow a 
> variety of 
> > lengths.
> > 
> > Need more explicit definition for  Card ID and Card 
> Revision values. 
> > For some vendors, these are not applicable.
> > If not generally applicable, leave as vendor specific. 
> Indicated these 
> > as optional to include, renaming to "board" from "card"
> > to be consistent with the message element name. Can open a 
> new issue 
> > for this if needed.
> > .
> > WTP Board Data also includes the Ethernet MAC address. Why is the 
> > layer 2 MAC address needed? Recommend removing the Ethernet MAC 
> > address field from the WTP Board Data message element 
> (similar to AC 
> > MAC address in Issue 39)
> > 
> > |                             WTP Serial
> > Number                                       |
> > |                             WTP Serial
> > Number                                       |
> > |                             WTP Serial
> > Number                                       |
> > |                             WTP Serial
> > Number                                       |
> > |                             WTP Serial
> > Number                                       |
> > |                             WTP Serial
> > Number                                       |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
> > |                       Ethernet MAC Address
> >                                      |  
> > Ethernet MAC Address: MAC Address of the WTP's Ethernet interface.
> > 
> > to
> > 
> > 0                           1                          2
> >      3
> > |                  Type=0              |
> > Length                        |
> > |                  Type=1              |
> > Length                         |
> > Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 
> > Network Management Private Enterprise Codes"
> > Type: The following values are supported 0 - WTP Model 
> Number; The WTP 
> > Model Number MUST be included in the WTP Board Data message element.
> > 1 - WTP Serial Number; The WTP Serial Number MUST be 
> included in the 
> > 2 - Board ID; A  hardware identifier, which MAY be included 
> in the WTP 
> > Board Data message element.
> > The Vendor Identifier, WTP Model Number and WTP Serial Number are 
> > optionally followed by additional vendor specific values.
> > 
> > Comments please.
> > 
> > Thanks,
> > 
> > Dorothy
> > 
> Regards,
> /david t. perkins
> 
> 
> 
> 
> 
>