802.11 Using a compressed reassociation exchange to facilitate fast handoff

[0001] This application claims the benefit of U.S. Provisional Application No. 60/429,714, filed Nov. 26, 2002. This application claims the benefit of U.S. Provisional Application No. 60/439,419, filed Jan. 10, 2003.

[0002] A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyrights whatsoever.

[0003] The present invention is generally related to wireless networking, more specifically to methods and systems for authenticating and provisioning wireless devices as the devices roam among access points.

[0004] Most current 802.11 network-level authentication protocols require a substantial amount of time to re-establish a wireless station's connectivity to the network after that station roams from one access point (AP) to another access point. Typically, when a station associates with a first access point, it has to be authenticated through a central authentication server. When the station roams to a new access point, the station loses the session to the network and must again authenticate itself with the authentication server which typically involves a full challenge request and response. A new accounting session is then established. This method introduces a new key hierarchy that commences on the initial authentication and allows for the authentication key to persist across the duration of a session to the network versus an 802.11 link. Further, this new key hierarchy is based on counter mode key generation to allow the precomputation of the 802.11 key obviating the need for unnecessary session teardown and restart.

[0005] This delay in re-establishing connectivity greatly impacts 802.11 service to the point that some upper-level protocols, such as Voice-over-IP (VoIP), actually fail. Furthermore, each roam commonly necessitates interaction with a site's Authentication, Accounting, and Authorization (AAA) servers, resulting in a significant increase in server load, to the point at which some servers fail to provide the necessary rate of authentications requests for the 802.11 lo stations. More importantly, after the authentication has succeeded, the 802.11 station must then use the key provisioned at authentication to establish a fresh key used to secure the 802.11 link with the access point.

[0006] Thus, the need exists for a fast, secure and reliable method for authenticating and provisioning a station when the station roams from one access point to another that decreases is traffic to the authentication server and optimizes the generation of a fresh 802.11 key. In designing a fast secure and reliable method for seamlessly roaming a station between access points, the following underlying assumptions and requirements are desirable:

[0007] 1) Fast handoff must minimize the message transactions and computations between MN and AP

[0008] 2) Fast handoff is affected only in intra-subnet mobility, though an infrastructure is built to allow for future support for inter-subnet mobility

[0009] 3) The handoff must be secure

[0010] 4) The overall design must leverage existing standards to the extent possible

[0011] 5) The overall design must not interfere with existing protocols.

[0012] 6) The handoff mechanism is based on key management and thus is independent of the authentication mechanism. Note however that any key management mechanism must be aware of chosen authentication type as it must know how to properly retrieve and interpret the NSK.

[0013] 7) The handoff mechanism relies on a centralized service to provide secure key distribution services

[0014] Current authentication protocols such as PEAP or TLS require interaction with the authentication state. PEAP touts the ability to shorten roam time by allowing a MN to bypass a full challenge-response authentication exchange by affecting a resume operation. IEEE 802.11 security task group i e.g. TGi have accommodated for the means of pre-authenticating. These two mechanisms presume a need for re-establishment of the network session key (NSK) before the link between the AP and MN can establish a pairwise transient key (PTK) for protecting 802.11 and 802.1X traffic. However, with a defined key hierarchy, TGi also alludes to the ability of transferring the NSK from one AP to another. This design also uses the notion of retaining the NSK and relies only on the key management mechanisms to affect a fast handoff during a roam. However, to provide freshness and uniqueness of a session key for each access point, CCKM defines an initial authenticated key exchange by which the MN and first associated AP contribute material for deriving fresh keys for authenticating key requests, KRK, and a base transient key, BTK for deriving PTKs.

[0015] The following is a list of acronyms and their corresponding definition as used throughout this specification:

[0016] AKMAuthenticated Key Management

[0017] APAccess Point

[0018] ASAuthentication server

[0019] BSSIDBasic Service Set Indetifier

[0020] BTKBase Transient Key

[0021] CCKMCentral Key Management

[0022] CCMCampus Context Manager

[0023] CCXClient Enablement

[0024] CTKContext Transfer Key

[0025] GTKGroup Transient Key

[0026] KRKKey Request Key

[0027] MNMobile Node

[0028] MN-IDMobile Node Identifier

[0029] NSKnetwork session key

[0030] PRFPseudoRandom Function

[0031] PMKPairwise Master Key

[0032] PTKpairwise transient key

[0033] RNrekey request sequence number

[0034] SCMSubnet Context Manager

[0035] SSIDService Set Identifier

[0036] SSNSimple Security Network

[0037] VLANVirtual Local Area Network

[0038] WLCCPWireless Local Context Control Protocol.

[0039] Along with the aforementioned acronyms, defined below is a definition of terms appearing throughout this application:

[0040] IEEEInstitute of Electrical and Electronics Engineers, Inc.

[0041] IEEE 802.11The 802.11 protocol and 802.11 terms are defined in IEEE Std 802.11, 1999 Edition

[0042] IEEE 802.11 TGia task group in IEEE 802.11 currently focused in addressing 802.11 security.

[0043] 802 address. A canonical IEEE 48 bit Ethernet address. 802.11 and Ethernet addresses are 802 addresses.

[0044] 802.11 bridgeAn 802.11 bridge is a transparent bridge with an Ethernet bridge port and one or more 802.11 bridge ports. A parent 802.11 bridge has a secondary 802.11 port which links to a primary 802.11 port in a child 802.11 bridge.

[0045] 802.11 stationA MN or AP.

[0046] 802.1XThe IEEE 802.1X protocol and 802.1X terms are defined in . 802.1X defines a protocol where an 802.1X Supplicant mutually authenticates with an 802.1X Authenticator via an Authentication Server.

[0047] AAAAuthentication Authorization Accounting. A node will request network access by executing a protocol to a (typically) Authentication Server that provides protocols and services for providing authentication, authorization and session accounting.

[0048] AKMAuthenticated Key Management. New selector in both the SSN and TGi negotiated element present in beacons, probe response and reassociation request/response messages. This selector allows for definition of authentication type and key management.

[0049] APAccess Point. In this document, AP is used as a general term to refer to any 802.11-to-Ethernet or 802.11-to-802.1 1 relay devices.

[0050] Association MessageAn 802.11 station sends an Association Request message to initially associate with a parent AP. The parent AP replies with an Association Response message.

[0051] ASAuthentication Server. A node that provides AAA (specifically authentication) service.

[0052] BDPUan 802.1D Bridge Protocol Data Unit.

[0053] BSSAn 802.11 Basic Service Set. A BSS is the set of 802.11 stations associated with a single 802.11 AP. A logical BSS port in an AP is used to access stations in the BSS.

[0054] Base Transient Key (BTK)the base transient key that is mutually derived between MN and SCM to serve as the key for generating PTKs.

[0055] Campus Netowkran aggregate seamless roaming domain which implies a geographic locality which may include one or more 802.11 Extended Service Sets. A physical campus network may contain multiple campus networks.

[0056] Central Key Management (CCKM)the key management scheme of the present invention. It utilizes a central node, an AP, as the key distributor to enable protected communications between a link (e.g. an AP and MN).

[0057] Context Transfer Key (CTK)A key shared between two nodes to establish protection of its data packets. The CTK may consist of a pair of keys if the protection mechanism requires a unique key for each encryption and packet authentication (e.g. a MIC).

[0058] Correspondent Host (CH)A mobile or non-mobile node that is actively communicating with a MN.

[0059] DescednantA node that is in the sub tree of a Topology Tree that is roonated in an ancestor node.

[0060] DRRDescendant Registration Record. A DRR contains state information for descendant nodes. An MN-DRR is a DRR for a mobile node. An AP-DRR is a DRR for an AP.

[0061] DPRDescendant Path Record (DPR). A DPR contains path state information for descendant nodes.

[0062] DownlinkThe logical radio path from an 802.11 AP radio to a child 802.11 station.

[0063] ESSAn 802.11 Extended Service Set. An ESS includes one or more BSSes and may span one or more subnets. MNs can roam between APs in the ESS. A SWAN Campus Network may include multiple ESSes.

[0064] FAA Mobile Ipv4 foreign agent.

[0065] Group Transient Key (GTK)A key owned and managed by an AP. It is used to protect multicast and broadcast traffic.

[0066] HAA Mobile Ipv4 home agent.

[0067] Hopwise RoutingHopwise routing is used when an inbound or outbound WLCCP message must be forwarded to intermediate APs on the path from the Originator to the Responder.

[0068] IAInfrastructure Node Authenticator. In standalone mode, the SCM is the IA; in a full SWAN configuration, the CCM is the IA.

[0069] IGMPInternet Group Management Protocol. IGMP is used to determine IP multicast group membership.

[0070] IGMP SnoopingSwitches and APs snoop IGMP messages, received on a port, to determine which IP multicast addresses must be transmitted on the port.

[0071] InboundAn inbound frame is forwarded toward the CCM, in the SWAN Topology Tree. An inbound node is accessed via the primary port. (An inbound node is not necessarily an ancestor node.)

[0072] INInfrastructure Node. An IN is an AP, SCM, LCM, or CCM.

[0073] IRRInbound Registration Record.

[0074] KDCKey Distribution Center. This is a service provided by the IN Authenticator to distribute CTKs to be consumed by registered infrastructure nodes.

[0075] Key Request Key (KRK)the portion of the expanded NSK used to authenticate key refresh request/response handshakes

[0076] Layer 2The data link layer, as defined in the ISO 7-layer model.

[0077] L-CTKLateral Context Transfer Key.

[0078] Linkthe logical link between two immediate neighbors in the SWAN Topology tree.

[0079] Link StateEach SWAN node is responsible for monitoring the link to each of its lo immediate neighbors. The Link State can be Connected or Disconnected.

[0080] MIPMobile IPv4 as defined in RFC 2002.

[0081] MN802.11 Mobile Node.

[0082] MN-ID802.11 Mobile Node identifier represented as the node's MAC address

[0083] Network Session Key (NSK)the key established by a successful authentication between a node an its authenticator. With the CCM being the authenticator for all infrastructure nodes and the LCM being the authenticator for all MNs. In the case where an SCM is acting in standalone mode, the SCM is the authenticator for all nodes.

[0084] MNRMobile Node Record. A Mobile Node Record contains state information for MNs.

[0085] Mobility bindingsThe mobility bindings for a station are used to determine the current path to the station. APs, context managers, and MIP agents maintain mobility bindings for 802.11 stations.

[0086] MSCMessage Sequence Counter. This is effectively the RC4 IV and replay protector.

[0087] Native VLAN IDA switch port and/or AP can be configured with a native VLAN ID. Untagged or priority-tagged frames are implicitly associated with the native VLAN ID.

[0088] Network Access Identifier (NAI)An NAI is used to identify a user within a network domain. For example, joecisco.com is a typical NAI.

[0089] NSKNetwork Session Key. An NSK is the key established by a successful authentication between a node and its authenticator. (The CCM is the authenticator for all infrastructure nodes and the LCM is the authenticator for all MNs, in a campus network. In a standalone subnet domain, the SCM is the authenticator for all nodes in the subnet.)

[0090] OriginatorThe node that originates a WLCCP request message.

[0091] OutboundAn outbound frame is forwarded away from the CCM, in the SWAN Topology Tree. An outbound node is a descendant node that is relatively further from the CCM in the SWAN Topology Tree.

[0092] OMNROutbound Mobile Node Record

[0093] Pairwise Master Key (PMK)the key established by a successful authentication. This is the term used in both the TGi and SSN draft specification and is a key used to derive PTKs.

[0094] Pairwise Transient Key (PTK)the key mutually derived by AP and MN and is a function of BTK and RN

[0095] Path AuthenticationPath authentication refers to the process where an AP or child CM mutually authenticates and establishes a path CTK with each of its ancestors. Path-Init and (optionally) intial Registration messages are used for path authentication.

[0096] PortThe logical entity that provides access to a SWAN Topology Tree link. Multiple logical ports may exist on a single hardware interface.

[0097] PNRParent Node Record

[0098] Primary LANThe wired Ethernet LAN directly attached to the SCM. Each subnet has one Primary Ethernet LAN. The primary LAN may include multiple Ethernet segments and wired transparent bridges/switches.

[0099] Primary PortThe port that is used to attach to the SWAN topology tree. In an SCM, it is the port that is used to access the parent LCM or CCM. In an AP, it is the port that is used to transmit frames toward the primary LAN. An AP primary port can be an Ethernet or 802.11 port. The AP primary port is the default port for unicast flooding purposes. If an AP is co-located with an SCM, then a logical internal link exists between the AP and SCM. A logical AP internal primary port provides access to the SCM; however, the Ethernet port is still the primary port for frame forwarding purposes.

[0100] PTKPairwise Transient Key. This key is used to protect 802.1X and 802.11 data packets between a MN and AP. PTKs are mutually derived by each node in the link based on a predefined strong pseudorandom function, BSSID, RN and BTK.

[0101] Reassociation MessageAn 802.11 station sends an 802.11 Reassociation Request message to associate with a new parent AP after it roams. The parent AP replies with a Reassociation Response message.

[0102] Rekey Request Number (RN)the counter used to protect PTK key refreshes from replay attacks. The counter is also used as part of the PTK key generator.

[0103] RepeaterA repeater is a wireless AP that is attached to a parent AP on an 802.11 primary port.

[0104] RNRequest Number. A sequence value used to rotate PTKs used between an authenticated MN and Root AP.

[0105] Root APA root AP is directly attached to the primary LAN on its primary Ethernet port.

[0106] Root CMThe CM that is at the root of the active SWAN Topology Tree. The CCM is the root CM in a campus network. The SCM is the root CM in a stand-alone subnet control domain.

[0107] ResponderThe destination of a WLCCP Request message or the node that originates a WLCCP Reply message.

[0108] SARpMSCM-Advertisement Reply Message

[0109] SCMSubnet Context Manager. An SCM provides a central control point for each subnet. The SCM establishes the primary LAN for each subnet. From the perspective of a MN, a home SCM is the SCM of the home subnet for the MN and a foreign SCM is an SCM on any other foreign subnet.

[0110] Seamless roaming. A MN is said to roam seamlessly if it roams between APs in different subnets without changing its home IP address.

[0111] Secondary LANAny wired Ethernet LAN that is attached to the Primary Ethernet LAN by a wireless link. A secondary LAN may include multiple Ethernet segments and wired transparent bridges/switches.

[0112] Secondary PortA secondary port is any active AP or CM port other than the primary port.

[0113] SSID802.11 Service Set Identifier. Authentication parameters are defined globally per SSID. An SSID can be locally bound to a home subnet or VLAN, in each AP.

[0114] Simple Security Network (SSN)Microsoft's specification for a framework used to provide 802.11 security. It mandates use of 802.1X EAP authentication, TKIP and Microsoft's 802.1X 4-way handshake for managing unicast keys and 802.1X 2-way handshake for managing broadcast and multicast keys.

[0115] STPIEEE 802.1D Spanning Tree Protocol. An STP AP executes the 802.1D STP and the 802.1D STP is operated on an STP link. A non-STP AP does not execute the 802.1D STP.

[0116] SubnetAn IP subnet. A MN is associated with a single home subnet at any given time. Any other subnet is a foreign subnet, from the perspective of the MN.

[0117] SupplicantThe IEEE 802.1X standard defines the term supplicant. A supplicant is a node that is mutually authenticating with an 802.1X authenticator via an authentication server.

[0118] SWANSmart Wireless Architecture for Networking, an architecture for radio, network and mobility management within a secure environment.

[0119] SWAN Topology TreeThe logical structure of a SWAN netowrk as determined by the SWAN parent/child relationships. The SWAN CCM is at the root of the topology tree.

[0120] VLANA Virtual LAN, as defined in the IEEE 802.1Q standard.

[0121] TLVType, Length, Value TLV's contain optional parameters in WLCCP messages.

[0122] UplinkThe logical radio path from an 802.11 child station to its parent AP radio.

[0123] URRUnbound Registration Record.

[0124] VLANA Virtual LAN as defined in the IEEE 802.1Q standard. VLAN tagged frames are transmitted on a VLAN Trunk link.

[0125] Wireless stationA MN, repeater, WGB, or child 802.11 bridge.

[0126] WGBA work-group bridge is a non-STP AP with an 802.11 primary port and a secondary Ethernet port that provides access to a non-STP secondary Ethenet LAN segment.

[0127] WLAN-Wireless LAN.

[0128] WLCCPWireless LAN Context Control Protocol.

[0129] In addition to the aforementioned acronyms, unless otherwise defined acronyms from the 802.11 specification should be given their usual and customary meaning as defined by the 802.11 specification. The 802.11 specification is hereby incorporated by reference.

[0130] In view of the aforementioned needs, the invention contemplates a design that reduces both message and computational burdens by employing a key hierarchy that decouples authentication session time from key management. Current 802.11 implementations tightly bind authentication and key management and enforce full backend (re)authentications because they are bound to the cipher suite selection. For Wired Equivalent Privacy (WEP), this can result in very frequent (re)authentications due to WEPs rekey requirements. For roaming, current implementations also enforce a full (re)authentication.

[0131] The key hierarchy defines keys established on a successful authentication as network session keys (NSKs), which are independent of the 802.11 cipher suite selection. The NSK is used to generate a key refresh key (KRK) to authenticate key refresh requests and a base transient key (BTK) which serves as the base key from which pairwise transient keys (PTK) are derived.

[0132] Only PTKs are bound to the selected 802.11 cipher suite and thus must be managed based on the cipher suite security policies. The longevity of the NSK is defined by the Authentication Server (AS) as a session timeout which can now be defined as a function of the NSK entropy versus the 802.11 negotiated cipher suite. It is desired is to strongly encourage the use of authentication types that result in generation of dynamic NSK with more good entropy.

[0133] Keys are managed by a centralized node that provides subnet context management (SCM). Preferably, the SCM is the 802.1X authenticator for all MNs and APs enforcing all MN nodes to implicitly register. The registration process ensures that all nodes in the registry have successfully associated, authenticated and have security credentials cached. The mechanisms described in this proposal are defined as Central Key Management (CCKM) and negotiated as a proprietary value in the Authenticated Key Management (AKM) information element as defined in SSN/TGi's drafts.

[0134] While the authentication mechanism remains unchanged, e.g. 802.1X Extensible Authentication Protocol (EAP) authentication, this design introduces a new key management scheme: Central Key Management (CCKM). This new capability is advertised and negotiated using SSN's IE or RSN's IE as described herein infra.

[0135] One aspect of the present invention is a method for authenticating a mobile node with a network, the steps comprising associating with an access point, authenticating the mobile node using an extensible authentication protocol by the access point, and establishing a network session key and registering the mobile node into the network infrastructure. The network session key is used to establish a key request key and a base transient key.

[0136] After the initial authentication, the network session key is sent to a Subnet Context Manager. The present invention further contemplates authenticating key refreshes using the network session key. It is further contemplated that pairwise transient keys are derived using the network session key.

[0137] Another aspect of the present invention is a method of re-association by a mobile node, the steps comprising sending a re-association request from a mobile node to an access point, the re-association request comprising a mobile node identification, a rekey request number, and an authentication element, validating the re-association request, the validating step comprising computing a new pairwise transient key, sending a response, the response comprising an authentication element, to the mobile node, the authentication element comprising the new pairwise transit key and an extensible authentication protocol over local area network key; and confirming the response by verifying the new pairwise transit key to a second computed pairwise transit key.

[0138] Typically the response is validated by verifying the new pairwise transient key. The response may also be verified by verifying a timestamp included in the response. The authentication element preferably uses a current pairwise transient key. The validating step is performed by either a subnet context manager (SCM), an authentication server (AS), or the access server (AAA server). Other methods for validating the request include but are not limited to verifying that the timestamp of the re-association request is within a configurable value, verifying the sequence number is greater than a previous value, sending to a query to a subnet context manager to validate the re-association request, wherein the access point (AP) receives a rekey request number and a base transient key from the subnet context manager and generates

[0139] Another aspect of the present invention is a rekey sequence, the steps comprising: computing an authentication element, the authentication element comprising a rekey request number and a new pair transient key, transmitting to a responder a call for a new pair transient key, receiving an response authentication element from the responder; and verifying the response authentication element, the response authentication element comprising the new pair transient key. The rekey sequence may further comprise sending an extensible authentication protocol over local area network key confirm message. Prior to computing the authentication element, the rekey request number is incremented.

[0140] Another aspect of the present invention is a rekey sequence, the steps comprising: receiving a rekey request, the rekey request comprising a rekey request number and an authentication element, computing a new pair transient key; and sending a ready to transmit and receive with the new pair transient key message. The rekey sequence may further comprise receiving an extensible authentication protocol over local area network key confirm message, verifying the rekey request number is greater than a cached rekey request number, verifying all attributes of an extensible authentication protocol over local area network key request, updating a cached rekey request number, or a combination thereof. Furthermore, the authentication element may comprise a new initiator pair transient key and the steps may further comprise comparing the new pair transient key with the new initiator pair transient key.

[0141] Still other objects of the present invention will become readily apparent to those skilled in this art from the following description wherein there is shown and described a preferred embodiment of this invention, simply by way of illustration of one of the best modes best suited for to carry out the invention. As it will be realized, the invention is capable of other different embodiments and its several details are capable of modifications in various obvious aspects all without from the invention. Accordingly, the drawing and descriptions will be regarded as illustrative in nature and not as restrictive.

[0142] The accompanying drawings incorporated in and forming a part of the specification, illustrates several aspects of the present invention, and together with the description serve to explain the principles of the invention. In the drawings:

[0143] FIG. 1 is a block diagram illustrating a key hierarchy as contemplated by the present invention;

[0144] FIG. 2 is a table of Subnet Context Manager acquisition of network session keys;

[0145] FIG. 3 is a table illustrating authenticated key management selector values;

[0146] FIG. 4 is a table illustrating a Subnet Context Manager's cached credentials;

[0147] FIG. 5 is a table illustrating the credentials cached by an Access Point;

[0148] FIG. 6 is a block diagram illustrating the keys used to secure messages between links;

[0149] FIG. 7 is a flow diagram showing the steps for AP registration to an SCM;

[0150] FIG. 8 shows an example of a successful mobile node Lightweight Extensible Authentication Protocol Authentication and Registration;

[0151] FIG. 9 shows an example of a successful mobile node non-Lightweight Extensible Authentication Protocol authentication and registration;

[0152] FIG 10 is a flow diagram illustrating the sequence triggered to complete a key establishment after a successful authentication;

[0153] FIG. 11 is an example key descriptor for a rekey sequence;

[0154] FIG. 12 is a block diagram showing a rekey sequence;

[0155] FIG. 13 is an example of the authenticating element included in a re-association request sent by a mobile node;

[0156] FIG. 14 is an example of the format of the response to the re-association request by the access point;

[0157] FIG. 15 is a block diagram illustrating the communications that take place between the various network components for a successful mobile node reassocation to a new access point;

[0158] FIG. 16 is a block diagram showing a method for propagating keys for legacy or SSN mobile nodes;

[0159] FIG. 17 is a block diagram exemplifying a topology tree for a full implementation of one aspect of the present invention;

[0160] FIG. 18 is a table illustrating the format of a WLCCP Node ID.

[0161] FIG. 19 is block diagram showing the internal bridging structure in an access point;

[0162] FIG. 20 is an example of an Ethernet-encapsulated WLCCP Context Management frame;

[0163] FIG. 21 is an example of a WLCCP Message Header;

[0164] FIG. 22 is an example of a TLV format;

[0165] FIG. 23 is a block diagram showing how hopwise routing is used;

[0166] FIG. 24 is a block diagram illustrating a handoff from a first access point to a second access point for a mobile node on a campus topology;

[0167] FIG. 25a is an example of the message sequences for initial mobile node association;

[0168] FIG. 26b is an example of the message sequences for a mobile node roaming from a first access point to a second access point;

[0169] FIG. 27 is a block diagram illustrating a handoff of a repeater access point from a first access point to a second access point;

[0170] FIG. 28a is an example of the message sequences for initial repeater access point association;

[0171] FIG. 28b is an example of the message sequences for a repeater access point roaming from a first access point to a second access point;

[0172] FIG. 29 is an example of a root access point authentication;

[0173] FIG. 30 is a block diagram illustrating defined CTK's;

[0174] FIG. 31 is an example block diagram of an AP authenticating and registering to the infrastructure;

[0175] FIG. 32 is an example block diagram of an alternate sequence used for a path update requiring no registration;

[0176] FIG. 33 is an example of an Establish (refresh) CTK's between an access point and a subnet context manager;

[0177] FIG. 34 is a block diagram illustrating an example message sequence for a successful mobile node authentication and registration to full topology;

[0178] FIG. 35 is a block diagram of a WLAN spanning tree for a single subnet;

[0179] Throughout this description, the preferred embodiment and examples shown should be considered as exemplars, rather than limitations, of the present invention.

[0180] The present invention reduces both message and computational burdens by employing a key hierarchy that decouples authentication session time from key management. Current 802.11 implementations tightly bound authentication and key management and enforce full backend (re)authentications because they are bound to the cipher suite selection. For WEP, this can result in very frequent (re)authentications due to WEPs rekey requirements. For roaming, current implementations also enforce a full (re)authentication.

[0181] The key hierarchy defines keys established on a successful authentication as network session keys (NSKs), which are independent of the 802.11 cipher suite selection. The NSK is used to generate a key refresh key (KRK) to authenticate key refresh requests and a base transient key (BTK) which serves as the base key from which pairwise transient keys (PTK) are derived.

[0182] Only PTKs are bound to the selected 802.11 cipher suite and thus must be managed based on the cipher suite security policies. The longevity of the NSK is defined by the Authentication Server (AS) as a session timeout which can now be defined as a function of the NSK entropy versus the 802.11 negotiated cipher suite. The goal is to strongly encourage the use of authentication types that result in generation of dynamic NSK with more good entropy.

[0183] The new key hierarchy 100 is depicted in FIG. 1. Keys (as defined in FIG. 1) are managed by a centralized node that provides subnet context management (SCM). The SCM is the 802.1X authenticator for all MNs and APs enforcing all MN nodes to implicitly register. The registration process ensures that all nodes in the registry have successfully associated, authenticated and have security credentials cached. The mechanisms described in this proposal are defined as Central Key Management (CCKM) and negotiated as a proprietary value in the Authenticated Key Management (AKM) information element as defined in current SSN and TGi's drafts.

[0184] Referring to FIG. 1, the top of the hierarchy 100 is the NSK 102. The NSK 102 is implicitly derived as a result of a successful EAP authentication. From the NSK 102 is generated the KRK and BTK as shown in block 104. The KRK and BTK are generated using a PRF with the NSK, BSSID, STA-ID, Nonce_STA and Nonce_SCM as parameters. The 128 bit KRK 106a and 256 bit BTK 106b are derived from the NSK. From the BTK 106b is generated the PTK_SN using a PRF with the BTK, RN and BSSID as parameters. From the PTK are derived the 802.1X Encrypt Key 110 (16 bytes), the 802.1X MIC key 112 (16 bytes), the 802.11 Encrypt Key 114 (16 byes) and the AP MIC Keys 116 (TKIP only). The AP MIC Keys 116 further comprise a Tx Key 118a, 8 bytes, and a Rx Key 118b, also 8 bytes.

[0185] While the authentication mechanism remains unchanged, e.g. 802.1X EAP authentication, the present invention introduces a new key management scheme: CCKM. This new capability is advertised and negotiated using SSN's IE or RSN's IE, described herein infra.

[0186] An implementation consideration of the present invention is ensuring autonomy from authentication mechanisms. Like TGi and SSN, the present invention also presumes the presence of a (NSK) key upon successful authentication. For security reasons, this key should in general be dynamically configured and managed. The present invention provisions for short NSK's and provides a means to stretch them to the required 384 bit length. Though heavily discouraged, this design can also allow for the use of pre-shared keys to be defined as the NSKs.

[0187] The CCKM must be aware of the authentication type used to interpret and retrieve the NSK. FIG. 2 is a table 200 that describes how the NSK is derived and retrieved by the SCM. Column 202 describes the 802.1X Authentication type. Column 204 describes the NSK computation. Column 206 shows the length of the NSK in bytes, and column 208 describes how the SCM acquires the NSK.

[0188] Authentication types that do not mutually derive dynamic keys, such as EAP-MD5 rely on having a static key to be configured similar to how legacy systems support pre-shared key authentication. These static configurations are traditionally managed at the AP. To allow for backward compatibility, these configurations must persist. Thus, CCKM will request these NSK types from the first associated AP as the session NSK.

[0189] The present invention contemplates a fast handoff system and method (herein referred to as CCKM) that is based on a centralized service, a Subnet Context Manager (SCM) to enable a seamless secure context transfer required to transition a MN from one AP to a new one. To secure such transfers, the SCM relies on each node both APs and MNs to mutually authenticate with the SCM. Upon successful authentication, a shared secret must be established: a network session key (NSK).

[0190] The use of the NSK deviates from IEEE 802.11 TGi's (as well as SSN) use of the key established at authentication. TGi/SSN refers to this key as a PMK which in turn is used as key material to derive both the 802.1X and 802.11 pairwise transient keys (PTKs). While CCKM also derives further key material from the NSK, the derived keys are used to authenticate transient key requests and to derive the PTKs. The key hierarchy is depicted in FIG. 1.

[0191] By defining a key rotation scheme, CCKM allows the MN to derive the new PTK before reassociation. The MN may derive the PTK for the new AP once it determines the new BSSID it is roaming to and before the reassociation request is transmitted. Thus, upon a reassociation request, the MN can be ready to protect unicast communications to the new AP but must await the AP's reassociation response as acknowledgement that both parties can now secure unicast communications. The AP's reassociation response also includes delivery of the broadcast keys (GTK) to enable full protected communications.

[0192] For general PTK rekeying, CCKM introduces EAPOL key descriptor enhancements similar to those defined in SSN/TGi to affect a CCKM rekey.

[0193] Using either SSN or TGi's information elements, SSN EE and RSN IE respectively, CCKM capabilities can be negotiated. Currently both specifications allow the negotiation for an authenticated key management suite. The suite selector encapsulates both an authentication and a key management mechanism, the assigned values are described in table 300 in FIG. 3. Column 302 is the Organization Unique Identifier (OUI), column 304 is the type corresponding to the OUI in column 302, and column 306 is the description for the OUI in column 302.

[0194] Both AP and MN must support CCKM for interoperability. The AP must advertise CCKM capability by using a new value in the Authenticated Key Management Suite Selector as defined in SSN v 0.21 and TGi draft 2.3.

[0195] CCKM capability must be advertised in beacons and negotiated during probe response and association request. Successful negotiation of CCKM enables the centralized key management defined in this specification. Enabling CCKM also implies activation of the

[0196] The SCM is designed to provide context control for a subnet and affect client context transfers upon a roam. The SCM is a module that can coexist in an AP, be a standalone server, or coexist in an AS. While the SCM is designed to affect full inter-subnet mobility, this design only employs the components required to affect intra-subnet mobility. These elements include:

[0197] a repository holding authenticated node's security credentials including the node's NSK, session timeout and security policy

[0198] an MN's security credentials include an NSK, SSID, VLAN, session timeout, associated BSSID and possibly also authentication mechanism, key management mechanism and cipher suite negotiated at association. The credentials are used to validate the session before a context transfer and PTK can be delivered.

[0199] an AP's security credentials include an NSK, session timeout and list of associated MNs

[0200] a context repository including security credentials for all registered nodes

[0201] services required to manage the context repository for registered MNs and APs

[0202] services to identify and enable the SCM as the Authenticator for all APs and MNs

[0203] SCM provides services to automatically provide the new AP with the MNs security credentials without client interaction

[0204] services to generate and secure delivery of PTKs based on security policy.

[0205] The SCM maintains a cache of all registered MN contexts within a given subnet including the MNs' NSKs (shown in FIG. 4). The cached credentials for an AP are slightly different and are described in FIG. 5. Referring to FIG. 4, column 402 lists the SCAM cache of MN credentials, comprising the fields State 408, STA Addr 410, Authentication type 412, Key Management Type 414, Session Timeout 416, KRK 418, BTK 420, RN 422, SSID 424, VLAN ID 426, BSSID 428, Cipher 430, NSK Key length 432, NSK 434, Tx Key Length 436 and Tx Key 438. The length in bytes and a description of these fields are provided in columns 404 and 406 respectively. Referring to FIG. 5, the AP's cached credentials comprise the state 508, Node-ID 510, NSK 512, Session Timeout 514, CTK 516 and key sequence counter 518 as shown in column 502. The length and description of these fields are provided in columns 504 and 506 respectively.

[0206] The SCM establishes shared secrets with both the MN and APs. It uses the Key Request Key (KRK) as the shared secret with MNs to authenticate key requests. The Context Transfer Key (CTK) is the shared secret with APs to protect communications between the SCM and AP. The trust relationship is depicted in FIG. 6.

[0207] CTKs are distributed by the SCM to the AP for protecting link communications Note that while it has been suggested that NSKs be used to protect AP to SCM communications, this would enforce a shorter session timeout and full reauthentications to the AS when link keys need updating.

[0208] FIG. 6 shows the keys used to protect communication between assigned links. Note that BTKs are not used to protect messages directly, rather, it is used to derive PTKs used to protect communications between AP and MN. As shown in FIG. 6, the AS 602 uses NSK0 606 to communicate with the SCM 604. The SCM 604 communicates with AP 608 and AP2 610 using keys CTK1 612 and CTK2 614 respectively. AP1 608 communicates with MN3 616 and MN4 618 using PTK3 622 and PTK4 624 respectively, while AP2 610 communicates with MN5 with PTK5 628. The SCM 604 may also directly communicate with the mobile nodes, MN3 616, MN4 618 and MN5 620 using KRK6 630, KRK7 632 and KRK8 634 respectively.

[0209] PTKs are derived and refreshed based on a Rekey sequence counter and BTKs as defined or refreshed based on the NSK as decribed herein infra.

[0210] By employing Bering's SCM capabilities, the fast handoff design provides a scalable infrastructure that is required to provide inter-subnet roaming in a subsequent release.

[0211] The SCM services coexist in any AP and thus an election mechanism may be defined to allow for the selection of an AP as the SCM provider.

[0212] While there will be no initial support for SCM to SCM (e.g. lateral) communication to enable warm restarts, the election mechanism still enables cold standby. To secure communications with MNs, the AP must first authenticate and register with its SCM. Authentication is required to establish an NSK and registration allows secure communications between the SCM and the AP. The AP's NSK is derived by the AP as a result of a successful 802.1X LEAP authentication with the SCM; the authentication server delivers the NSK to the SCM via the Radius MS-MPPE attribute also as a result of a successful authentication. The AP identifies its SCM by listening to the SCM advertisement messages.

[0213] Upon successful authentication with the SCM, the AP must then register itself with the SCM as a valid AP. Upon pre-registration, the SCM delivers a set of CTKs to the AP that is used to both encrypt and authenticate WLCCP messages between the SCM and the AP.

[0214] A message depiction of how an AP establishes the required NSK and CTKs is shown in FIG. 7. The AP must also establish the CTK to ensure that no rogue AP is introduced and compromise either NSK or CTK. The authentication mechanism is similar to that used for bridges, where the configure LEAP username and password are used to authenticate with the AS. Tasks performed by the AP are in column 702, tasks performed by the SCM are listed in column 704, and tasks performed by the AS are in column 704.

[0215] For some embodiments, the SCM is the 802.1X Authenticator for all nodes. Thus, CTK establishment between the AP and SCM must be mutually derived.

[0216] To secure communications, a MN must first authenticate with the network via 802.1X EAP authentication. The result of a successful authentication establishes a NSK that is used to establish the KRK and BTK used to respectively authenticate key refreshes and derive PTKs.

[0217] Like SSN, CCKM also initiates a session with a 4-way handshake to establish the KRK and BTK, for enabling protection of unicast traffic These handshakes are only required after successful authentication. Rekey requests either upon re-association or due to general key management rekeying (like cipher suite countermeasures) only require an authenticated 3-way handshake. FIG. 8, depicts a successful MN LEAP Authentication and registration with the SCM.

[0218] A mechanism is needed to pass the NSK from EAP supplicants which are independent of the CCKM module. For instance, for non-LEAP EAP authentication on Windows platforms, the MN's NSK is usually generated in the EAP supplicant and passed to the EAP framework. The EAP framework will then pass the NSK to the CCKM module. Since the current SSN-capable EAP framework treats CCKM as non-SSN compliant, it will just process the 802.1X EAP authentication and send down the NSK after an EAP authentication success. Similarly, non-SSN EAP supplicants will simply process the 802.1X EAP authentication and send down the NSK after an EAP authentication success.

[0219] However, it is likely that the NSK will not be delivered until after the group key delivery EAPOL Key message from the AP is received. Thus, as shown in FIG. 8, for non-LEAP EAP authentication, the AP needs to send an additional 802.1X EAPOL key message with a dummy group key right after sending an EAP-Success message to the station.

[0220] It is up to the implementation in the CCKM module to indicate to the AP that it needs to send an additional EAPOL key message. This information could be negotiated during the association request RSNIE. An alternate solution is to always send the dummy EAPOL key message after EAP Success message. The CCKM module can ignore the dummy key if it already has the NSK and establish the real keys post the four-way handshake.

[0221] However, for legacy systems, association exchanges will always trigger a full authentication and 4-way handshake. Receipt of the CCKM rekey elements will be ignored.

[0222] An additional 2-way handshake is used to rekey the multicast/broadcast keys (GTK). The rekey protocol for GTK management is the same as specified in TGi and SSN. The 2-message handshake is initiated by the AP to deliver the GTK over and encrypted EAPOL Key message. The current PTK is used to protect these EAPOL Key messages.

[0223] In a CCKM capable system, an AP will always request the SCM for security credentials during a pre-registration request/reply. Associations imply session initiation and thus, upon an association if security credentials are valid in an SCM and CCKM is negotiated then 802.1X authentication can be bypassed. However fresh KRK and BTKs must be established. If no security credentials exist, then the AP must expect full authentication between MN and AS.

[0224] After a successful authentication, the sequence shown in FIG. 10 is triggered to complete the key establishment and result in the necessary PTKs used to protect packets between AP and MN.

[0225] Since the AP is also provided with the MN's session timeout, policy for managing (re)authentications is assigned to the AP. Similar to current implementations, APs can trigger (re)authentications before the session timeout expires and can also manage the update of the KRK and BTK refreshment as defined herein.

[0226] Either MN or AP can trigger a PTK rekey. Conditions in which either node may request a rekey include: TKIP failures, particularly in Michael countermeasures; Exhaustion of IV (mainly for WEP) and Countermeasures if the node feels the PTK has been compromised.

[0227] The rekey exchange is a 3-message EAPOL Key handshake. A new key descriptor is defined to allow for a secure rekey exchange, which is shown in FIG. 11. The fields are defined as follows:

[0228] Key Information 1102: designates whether it is a request (0), response (1) or confirm (3);

[0229] Status 1104: is used by the responder and confirmer. A zero value means success;

[0230] non-zero means the rekey failed and either a full KRK, BTK or deauthentication must be invoked;

[0231] EAPOL Replay Counter 1106: is the EAPOL Key message counter also used to protect from message replays;

[0232] Reserved field 1108: an extra byte is added to better align the element;

[0233] Key-ID 1110: 1 byte field that stored the key identifier (0, 1, 2 or 3) assignment, it must match the currently assigned key ID;

[0234] MN-ID 1112: the client's MAC address;

[0235] BSSID 1114: the AP's MAC address;

[0236] RN 1116: the rekey request number;

[0237] MIC 1118: authentication element using the current PTK. The MIC is defined as:

MICrequest HMAC-MD5( PTK,
	Key Info EAPOL Replay Ctr Key ID MN-ID
	BSSID RN ),
MICresponse HMAC-MD5( PTK,
	Key Info EAPOL Replay Ctr Key ID MN-ID
	BSSID RN
	Status),
MICconfirm HMAC-MD5( PTK,
	Key Info EAPOL Replay Ctr Key ID MN-ID
	BSSID RN
	Status).

[0238] The rekey sequence 1200 is shown in FIG. 12. The left column 1202 shows tasks performed by the initiator while the right column 1204 shows tasks performed by the responder.

[0239] At block 1206 the State transition calls for a new PTK. The initiator sets RNRN1, the new PTKPTK_RN1, and the compute MIC_request. Transmission to responder is halted until a valid response or timeout is reached. Reception with PTK_RN must be allowed. Request is use of PTK_RN1 in Key ID is sent.

[0240] The responder receives the request. If as shown at block 1208 the MIC_request new RN is not greater than cached RN, or any attribute in EAPOL Key request is invalid, the responder does not update PTK or send a response with non zero status. However, if as shown at block 1210 the MIC_request RN and EAPOL Key attributes are valid, the responder will update RN and compute PTK_RN1, flush MN transmit queue, install PTK_RN1, and Respond ready to xmit and rcv with PTK_RN1 (once response is sent, rcvd packets from MN using PTK_RN will not decrypt properly).

[0241] The initiator then receives the responder's response. As shown in block 1212, if the MIC_response or any EAPOL Key attribute is invalid, the rekey is aborted and the initiator will try again. However, if as shown at block 1204 the MIC_response and EAPOL Key attributes are valid, then the initiator installs PTK_RN1 and is ready to xmit and rcv with PTK_RN1. The initiator then sends an EAPOL Key confirm message.

[0242] The responder then receives the EAPOL confirm message. As shown in block 1216, if the MIC_confirm or any attribute in EAPOL Key confirm is invalid, the responder will either trigger another rekey, determine it's a spoof and disassociate or deauthenticate. As shown in block 1218, if EAPOL confirm is valid, the link is now protected using PTK_RN1

[0243] On a successful rekey, the AP must synchronize the SCM's RN value for the MN. It is recommended that the synchronization be made at every rekey. To update the SCM, a WLCCP_CONTEXT message with a WTLV_UPDATE_RN is sent to the SCM.

[0244] The description above assumes that neither request nor responder is capable of using multiple Key IDs to buffer PTKs. However, the protocol of the present invention allows for this function and thus facilitate a smoother transition during a rekey operation. That is, the requester can install PTK_RN1 into a new KeyID and thus enable reception of packets under either PTK_RN or PTK_RN1. Similarly, the responder could plumb the key in the alternate specified Key ID and also allow transmission and reception under either key. The final confirmation is to halt transmission and reception under the current (old) PTK_RN.

[0245] CCKM uses the SSN and TGi style of rekeying for updating multicast (GTK) keys and is thus not defined in this specification. For details on group/broadcast key updates refer to the latest TGi draft.

[0246] To shorten the re-association handshake, this design minimizes the number of packets exchanged between the client station and the AP to two packetsre-association request and re-association response. Referring to FIG. 13, a new proprietary element 1300 is introduced to facilitate the handoff in the re-association messages. The element in the re-association request includes the rekey request number (RN) and an authenticated element. Where:

[0247] Element ID 1302 is a Cisco defined element whose value is 0x9c

[0248] Length 1304 should be the length of the CCKM element request (e.g. 24 bytes)

[0249] OUI 1306 should be 00:40:96

[0250] OUI 1308 Type should be 0

[0251] MN-ID (not shown) is the MN's MAC address,

[0252] BSSID (not shown) is the AP's MAC address,

[0253] Timestamp 1310 is the current TSF timer value,

[0254] RN 1312 is the rekey request number,

[0255] RSNIE_MN (not shown) is the MN's requesting security policy (e.g. AKM and cipher suite negotiation);

[0256] CCKM (now shown) must be specified in the AKM selector of RSNIE_MN

[0257] The re-association response includes a new element authenticating 1400 the request, confirming use of PTK_RN and delivering the multicast key as shown in FIG. 14. Where:

[0258] Referring now to FIG. 13, there is shown an example of a successful MN reassocation to a new AP. The handoff occurs in the re-associate request/response exchange. The MN 1502 must include CCKM 1528 in the RSNIE 1530 to employ the fast handoff. More importantly, the security policy negotiated by the MN 1502 at reassociation must match to the one specified at initial association. The SCM 1506 must validate that the requesting RN 1532 value is greater than the previous one. The timestamp provided in the request must also be within a configurable value of the AP's TSF timer (not shown); the timestamp is included to ensure that this request is fresh. On a response, the AP 1504 must also provide it's TSF timer value in the CCKM response element to assure the MN 1502 that the response is also fresh.

[0259] When the AP 1504 receives a re-association request and CCKM is negotiated, it must query the SCM 1506 for validation of security credentials and acquire the RN and BTK before it can generate PTK_RN. The request is made using a WTLV_SECURE_CONTEXT request to the SCM 1506. If the SCM 1506 cannot validate credentials, then it will not deliver anything and provide a non-zero status indicating failure. On a successful transfer, the SCM 1506 will deliver the RN and BTK in an encrypted and authenticated WTLV_SECURE_CONTEXT reply. The validation of security credentials prevents an insider from fast reassociation with a different SSID.

[0260] On a successful context transfer, the AP 1504 proceeds to generate the PTK as described herein infa. It will then use the PTK to encrypt and authenticate the new information element to affirm PTK and securely deliver the multicast key, GTK.

[0261] If CCKM is negotiated but no proprietary element is provided, the AP 1504 can still request for security credentials. If credentials are valid then a full WTLV_INIT_SESSION establishment of fresh KRK and BTK is triggered and upon a successful 4-way exchange, KRK and BTK are mutually derived by SCM 1506 and MN 1502 and RN is reset to 1. If there are no credentials or the request to the SCM fails, the AP may choose to enforce a full (re)authentication.

[0262] By utilizing a sequence of PTK the client station is ready to decrypt unicast packets before the client initiates the re-association request. The client confirms its identity in the re-association request by using an incrementing authenticator (request number) and corresponding authentication (MIC). The AP 1504 uses the re-association response to confirm its identity and to piggyback the multicast key information (GTK) to the client STA.

[0263] For each fast re-association attempt, a unique request number (RN) will be used. On each fast re-association attempt, the client will increment the RN. The SCM prevents replay of a fast re-association request by caching the last RN used by the client, and rejecting any request for which the RN is less than or equal to the cached last RN.

[0264] Note that the derivation of the credentials and keying information includes the BSSID to prevent replay attempts across different APs. For example, without the BSSID, a hacker could attempt to reuse a fast-reassociation request for one AP to associate to a second AP. Which attempt will reach the SCM firstthe hacker or the true clientdepends on the delays through the network.

[0265] In another embodiment, there may be included the ability to forward security credentials to registered APs. For networks with large latency between the AP 1504 and the SCM 1506, the SCM 1506 information can also be cached at the AP 1504. In this case, the AP 1504 could perform all of the calculations that would normally be done at the SCM 1506. The AP 1504 can verify the authentication of a client, without having to query the SCM 1506 to obtain the latest RN, as the last RN used for a particular BSSID is sufficient to prevent replay. The AP 1504 should send an update to the SCM 1506 to ensure that the SCM 1506 has the latest RN informationthis is particularly important if the AP should stale the information and request the information from the SCM later.

[0266] The process for the reassociatoin starts at 1510 wherein a MN 1502 advances RN and generates a new PTK_RN. As shown at 1512, the MN 1502 sends the Re-Assoc Request to the AP 1512 which includes RN 1532, RSNIE_MN 1530 with CCKM 1528 as the negotiated key management value. The AP 1504 then sends a WLCCP(MN, Pre-Reg Req, WTLV_SECURE_CONTEXT, MN-ID, BSSID, RN, VLAN, MIC_KRK) to the SCM 1506 as shown by 1514. The SCM 1506 responds with WLCCP(MN Pre-Req Reply, WTLV_SECURE_CONTEXT, MN-ID, BSSID, RN, VLAN, BTK) as shown by 1516. As shown in block 1518, the AP 1504 authenticates and decrypts the BTK for the MN 1502 using it's AP's CTK and derives PTK_RN. At 1520, the AP 1504 sends Re-Assoc Resp(RN, RSNIE_AP Nonce_GTK E(PTK, GTK), MIC(PTK, MN-ID, BSSID, RN, RSNIEAP, Nonce_GTK, E(PTK,GTK)) which completes the liveness of PTK_RN and delivery of the GTK. Then as shown in block 1522 the MN 1502 authenticates and decrypts the GTK for this STA using PTK. Once the AP 1504 has completed the establishment of a secure communication link with the MN 1502, it registers the MN 1502 as being active with the AP 1504. This is accomplished by steps 1524 and 1526. At step 1524 a WLCCP(MN, REg Req) is sent from AP 1504 to SCM 1506 and the reply is sent at step 1526 as WLCCP(MN Reg Reply).

[0267] While this design promotes the use of CCKM, other Authenticated Key Management (AKM) types can be supported. Since CCKM-capable MNs are the only MN types that have their credentials cached at the SCM and thus require registration. However, in order to properly propagate credentials to the AP, all MNs require pre-registration. Whether supporting a legacy or SSN-capable client the credential propagation and pre-registration is the same, as shown in FIG. 16.

[0268] A key hierarchy is defined to allow for stretching keys as well as derivation of fresh keys. This section describes the functions used to derive the keys. A comment must be made though, to address the issue of key entropy.

[0269] CCKM ensures key freshness but relies on the provisioning of strong keys; e.g. having good entropy. If implementations like LEAP which are password based are believed to have low entropy then further crypto tools can be used to improve the key's entropy. TGi has already adopted a variation of PKCS5 as a means of improving key entropy which this design can easily adopt. Note however, that this requires far more computation that some NICs can provide.

[0270] KRK and BTK Derivation:

[0271] To ensure fresh KRK and BTK keys, the AP and MN engage in a 4-way handshake to provide key material required for deriving KRK and BTK. Each node must provide 16 byte nonces that are subsequently used with the NSK to derive the required keys. The function is defined as follows:

GK PRF-384(NSK, Cisco Key Management Base Key Generator
	BSSID STA-ID NonceSTA NonceSCM )
	KRK GK0:127
	BTK GK128:383
	PRF-384 is defined in Section 0.

[0272] Since the same PRF-XXX function is used to generate multiple key types, the string Cisco's Key Management Base Key Generator is introduced to this key derivation function to ensure that these keys are uniquely constructed from other key types.

[0273] Securing WLCCP Messages:

[0274] To protect WLCCP messages from eavesdropping and man-in-the-middle attacks, most WLCCP messages are encrypted using RC4 and authenticated using HMAC-MD5. An AP establishes a CTK with the SCM during pre-registration so that it can commence protection of WLCCP messages.

[0275] The CTK is a 256 bit key that is used to protect WLCCP messages as follows:

[0276] The low order 128 bits of CTK is used as the RC4 key.

[0277] The high order 128 bits of CTK is used as the HMAC-MD5 key

[0278] CTK Key Derivation:

[0279] Context transfer keys used between the AP and SCM are generated and distributed by the SCM. Each node in the link must provide an 16 byte nonce to assure a fresh key:

[0280] The CTK is computed by the SCM and delivered to the AP for protecting subsequent WLCCP messages. Delivery of the CTK is done by encrypting and authenticating the key using the NSK.

[0281] PTK Key Derivation

[0282] PTKs are a maximum of 512 bytes as they are used to protect both 802.1X and 802.11 communications. Its length is dependent on the 802.11 cipher suite negotiation established at association.

[0283] PTKs are derived by use of a one way hash function: SHA-1 and is based on the BTK, RN and BSSID:

[0284] where Len384 for WRAP or CCMP, 512 for TKIP or CKIP

[0285] While the present invention uses PTK liberally, the PTK generated is partitioned into several keys used to protect the following (also shown in FIG. 1):

[0286] EAPOL Key encryption between the AP and MN

[0287] EAPOL Key authentication between the AP and MN

[0288] 802.11 encryption

[0289] For 802.11 TKIP and CKIP: data packet authentication between the AP and MN

[0290] The key assignment for PTK is as follows:

[0291] EAPOL-Key MIC KeyPTK0:127

[0292] EAPOL-Key ENC KeyPTK128:255

[0293] 802.11 Encrypt KeyPTK256:383

[0294] TKIP Michael Authenticator Tx KeyPTK384:447

[0295] TKIP Michael Authenticator Rx KeyPTK448:511

[0296] The definition and pseudocode for generating arbitrary length keys based on given key material is as follows (extracted from TGi draft 2.3):

	H-SHA-1(K, A, B, X) HMAC-SHA-1(K, A Y B X) where Y is
	a single octet
containing 0x00 (zero)
	PRF-384(K, A, B) PRF(K, A, B, 384)
	PRF-512(K, A, B) PRF(K, A, B, 512)
	PRF(K, A, B, Len)
	octet i;
	for (i 0; i < (Len159)/160; i)
	R R H-SHA-1(K, A, B, i)
	L(R, 0, Len)

[0297] The key used in SHA-1 is one generated independently by the SCM and need not be shared by any other party.

[0298] HMAC-SHA1 Reference code

include stdafx.h
define ULONG unsigned long
include <sha.h>
void hmac_sha1(
unsigned char *text, int text_len,
unsigned char *key, int key_len,
unsigned char *digest)
A_SHA_CTX context;
unsigned char k_ipad65; /* inner padding - key XORd with ipad */
unsigned char k_opad65; /* outer padding - key XORd with opad */
int i;
/* if key is longer than 64 bytes reset it to keySHA1(key) */
if (key_len > 64)
A_SHA_CTX tctx;
A_SHAInit(&tctx);
A_SHAUpdate(&tctx, key, key_len);
A_SHAFinal(&tctx, key);
key_len 20;
/*
* the HMAC_SHA1 transform looks like:
*
* SHA1(K XOR opad, SHA1(K XOR ipad, text))
*
* where K is an n byte key
* ipad is the byte 0x36 repeated 64 times
* opad is the byte 0x5c repeated 64 times
* and text is the data being protected
*/
/* start out by storing key in pads */
memset(k_ipad, 0, sizeofk_ipad);
memset(k_opad, 0, sizeofk_opad);
memcpy(k_ipad, key, key_len);
memcpy(k_opad, key, key_len);
/* XOR key with ipad and opad values */
for (i 0; i < 64; i)
k_ipadi 0x36;
k_opadi 0x5c;
/* perform inner SHA1*/
A_SHAInit(&context); /* init context for 1st pass */
A_SHAUpdate(&context, k_ipad, 64); /* start with inner pad */
A_SHAUpdate(&context, text, text_len); /* then text of datagram */
A_SHAFinal(&context, digest); /* finish up 1st pass */
/* perform outer SHA1 */
A_SHAInit(&context); /* init context for 2nd pass */
A_SHAUpdate(&context, k_opad, 64); /* start with outer pad */
A_SHAUpdate(&context, digest, 20); /* then results of 1st hash */
A_SHAFinal(&context, digest); /* finish up 2nd pass */
HMAC-SHA1 Test vectors (extracted from the SSN draft):
	The test vectors for HMAC_SHA1 are from rfc2202 and have been
checked against the reference code above. The PRF test vectors have been
checked against two other implementations.
	test_case	1
	key	0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
	key_len	20
	data	Hi There
	data_len	8
	digest	0xb617318655057264e28bc0b6fb378c8ef146be00
	PRF
	0xbcd4c650b30b9684951829e0d75f9d54b862175ed9f00606e
	17d8da35402ffee75df78c3d31e0f889f012120c0862beb6775
	3e7439ae242edb8373698356cf5a
	testcase	2
	key	Jefe
	key_len	4
	data	what do ya want for nothing
	data_len	28
	digest	0xeffcdf6ae5eb2fa2d27416d5f184df9c259a7c79
	PRF
	0x51f4de5b33f249adf81aeb713a3c20f4fe631446fabdfa58
	244759ae58ef9009a99abf4eac2ca5fa87e692c440eb40023e
	7babb206d61de7b92f41529092b8fc
	test_case	3
	key	0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
	key_len	20
	data	0xdd repeated 50 times
	data_len	50
	digest	0x125d7342b9ac11cd91a39af48aa17b4f63f175d3
	PRF
	0xe1ac546ec4cb636f9976487be5c86be17a0252ca5d8d8df12c
	fb0473525249ce9dd8d177ead710bc9b590547239107aef7b4ab
	d43d87f0a68f1cbd9e2b6f7607

[0299] In addition to the aforementioned method, another aspect of the present invention is a Wireless LAN Context Control Protocol (WLCCP) that is used to establish and manage a network topology, referred to herein as the Smart Wireless Architecture for Networking (SWAN), and it is used to securely manage the operational context for mobile stations in a SWAN campus network.

[0300] A WLCCP registration protocol a) automatically creates and deletes links in the SWAN topology, b) securely distributes operational context, and c) (optionally) reliably establishes Layer 2 forwarding paths on wireless links.

[0301] A WLCCP SCM advertisement/election protocol automatically establishes a single SCM as the central control point for each subnet, and enables APs and MNs to select the parent node that provides the least-cost path to a backbone LAN.

[0302] WLCCP Context messages provide a general-purpose transport for context and management information. WLCCP Trace messages facilitate network diagnostic tools.

[0303] WLCCP is a transaction-oriented request/reply protocol. All WLCCP request and reply messages have a fixed-length header that contains message-type-dependent fields. Optional Type-Length-Value pairs follow the fixed length header; therefore, WLCCP is extensible.

[0304] Ethernet or UDP/IP encapsulation can be used for WLCCP messages. Ethernet encapsulation is restricted to intra-subnet (e.g. AP-to-AP or AP-to-SCM) WLCCP messages. IP encapsulation must be used for inter-subnet WLCCP messages and may also be used for intra-subnet WLCCP messages.

[0305] As those skilled in the art can readily appreciate, a specific WLCCP implementation may not include all of the components described herein.

[0306] A distributed context transfer protocol can be used to directly transfer context from an old AP to a new AP, when a MN roams. The IEEE 802.11f draft protocol, for example, defines a distributed context transfer protocol. There are a number of inherent problems with such a distributed approach. The most notable problems are: 1) Secure context transfer requires a many-to-many trust relationship between APs (or requires some additional hierarchy). 2) A protocol is needed to enable the new AP to determine the old AP when a MN roams. (The old AP 802.11 Reassociation field is not sufficient.) Context is passed around from AP to AP as a station roams; therefore, critical context may be lost (e.g. if the link to an old AP is lost). 4) A distributed protocol is susceptible to an inherent race condition where handoff messages for rapidly roaming stations may arrive out-of-order.

[0307] The SWAN network disclosed herein is organized as a hierarchical Topology Tree. When a station roams from an old AP to a new AP, context is generally transferred via the nearest common ancestor, in the Topology Tree, of both the old and new APs. WLCCP registration includes the necessary routing logic to automatically find the nearest common ancestor. Cached configuration and context information is stored in the network infrastructure. The common ancestor securely forwards the cached information on the new Topology Tree branch for a station that has roamed. Therefore, context transfer is automatically localized and context information is not lost if the link to an old AP is lost. The common ancestor also forwards the old AP bindings to the new AP.

[0308] A many-to-many security relationship between 802.11 APs is not needed for secure context transfer in a SWAN network. Instead, a trust hierarchy is established that corresponds to the SWAN Topology Tree. Operational context is generally forwarded on Topology Tree branches; therefore, WLCCP context transfer keys are pre-established between all SWAN nodes on the same topology tree branch. If it necessary to transfer context laterally between 2 nodes on different topology tree branches, then the nearest common ancestor of the 2 nodes can function as a trusted third party to quickly establish mutual authentication and a transient context transfer key.

[0309] The hierarchical Topology Tree facilitates central management and control points. For example, network-wide parameters can be centrally configured and distributed. A central WLCCP control point establishes and deletes topology links; therefore, it is possible to maintain a consistent network topology even if hand-off messages for rapidly roaming stations arrive out-of-order.

[0310] A locally or globally administered 48-bit IEEE 802 address is used as an internal WLCCP network Node Address. An IP address is not used as a Node Address because: a) A node may change its IP address. b) WLCCP is used to manage Layer 2 mobility; it should generally be independent of any network layer protocol.

[0311] A WLCCP Node Address is an internal WLCCP node identifier and should NOT be used to identify APs and CMs to users in network management applications. Instead, a Network Access Identifier (NAI) or domain name can be used as a user WLCCP node identifier.

[0312] The design of WLCCP of the present invention considers the following underlying assumptions and requirements:

[0313] 1) The target environment is an enterprise campus network.

[0314] 2) 802.11 is an Ethernet access technology, which is used to extend wired Ethernet backbone LANs to Mobile Nodes and select secondary LANs.

[0315] 3) An 802.11 AP is, effectively, a Layer 2 Ethernet bridge.

[0316] 4) An 802.11 Mobile Node (MN) is, effectively, a mobile Ethernet node.

[0317] 5) WLCCP is generally independent of the underlying radio technology.

[0318] 6) A MN should be able to roam seamlessly within a single subnet or between subnets within a campus network and operate as if attached to an Ethernet switch port; therefore, is necessary to transfer location-specific operational context when a MN roams.

[0319] 7) The path between a MN and each Correspondent Host (CH) must be reliably re-established when the MN roams. Simple backward-learning is not sufficient and is susceptible to a race conditions.

[0320] 8) Non-WLCCP Ethernet bridges and switches must support backward-learning, as defined in the 802.1D standard.

[0321] 9) WLCCP must provide context management services for an integrated Proxy-MIP/VLAN seamless inter-subnet mobility solution. The seamless mobility solution must support both IP and non-IP applications; it must not require client support; and it must not require users to significantly change their existing wired topologies.

[0322] 10) WLCCP does NOT facilitate (or preclude) seamless roaming between subnets in different geographic locales.

[0323] 11) A campus network may include a large population of stations that roam frequently; therefore, the overhead for roaming must be minimal.

[0324] 12) WLCCP must support very fast roaming for QoS applications.

[0325] 13) WLCCP must support existing WLAN features, include wireless (i.e. repeater) APs, wireless bridges, and mobile APs and bridges.

[0326] 14) Unicast and multicast frame flooding must be minimized on wireless links.

[0327] 15) WLCCP must support fast, secure context transfer, without introducing a need for many-to-many security relationships between APs.

[0328] 16) WLCCP must operate independently of any underlying Spanning Tree Protocol.

[0329] 17) WLCCP must not significantly increase user configuration requirements; therefore, the underlying topology must be largely self-configuring.

[0330] 18) WLCCP must not introduce single points of failure. The network must continue to operate, possibly with reduced features, if a SWAN node or link fails.

[0331] 19) WLCCP must leverage existing standards, as much as possible.

[0332] 20) WLCCP must not interfere with existing protocols. In particular, WLCCP must not preclude standard Mobile IP clients.

[0333] 21) Client MNs must NOT be required to directly support WLCCP. Instead, MNs can indirectly support WLCCP via 802.11 elements.

[0334] 22) WLCCP must provide building blocks for WLAN management and diagnostic tools.

[0335] 23) The radio coverage of APs on different subnets may overlap.

[0336] 24) WLCCP secure context transfer and message authentication is independent of the underlying security infrastructure, except that it must be possible to mutually authenticate SWAN nodes and establish secret session keys.

[0337] 25) WLCCP does NOT provide MN authentication; however, it must facilitate fast re-authentication by securely transferring dynamic MN security credentials.

[0338] As used herein, a SWAN network is a tree topology rooted at a SWAN CM. WLCCP is used to establish and maintain the Topology Tree. An example Topology Tree for a full WLCCP implementation is shown in FIG. 17. FIG. 17 shows a campus topology with two local control domains (LCM) 1706 and 1706 and three subnet control domains (SCM) 1708, 1710 and 1712. The example network includes a Work-group Bridge (WGB-1) 1714 and its attached Ethernet Nodes (EN-1 and EN-2, 1716 and 1718 respectively). Topology branches that exist over 802.11 links are shown as dashed lines 1720a-f.

[0339] Possible subnet topology components are specific to the WLCCP implementation. An example subnet topology for an implementation that supports Layer 2 path updates and wireless bridges will be illustrated herein infra.

[0340] SWAN CMs and APs are interior nodes (INs) and MNs and secondary Ethernet Nodes (ENs) are leaves in the SWAN Topology Tree. The SWAN CCM 1702 is at the root of the campus Topology Tree. The CCM 1702 is the root CM, in a campus network. An LCM 1704, 1706 is at the root of the sub tree contained in a Local Control Domain. An SCM 1708, 1710, 1712 is at the root of the sub tree contained in each network subnet. A parent AP 1722, 1724, 1726 and 1728 is at the root of a sub tree that contains child MNs 1730, 1732 and 1734 and any child Aps 1736 and 1738.

[0341] The format of a WLCCP Node ID is shown in table 1800 of FIG. 18. A 64-bit WLCCP Node ID identifies each node in a SWAN network. A Node ID is a concatenated 16-bit WLCCP Node Type 1802 and a 48-bit WLCCP Node Address 1804. The Node Address 1804 for a MN, EN, AP, or SCM is a global 48-bit IEEE 802 address. The Node Address 1804 for an LCM or CCM can be a global or locally-administered 48-bit IEEE 802 address. It is contemplated in one embodiment, the CCM can automatically assign local 48-bit addresses to itself and other LCMs. A Node Address of all zeros is used to identify the local WLCCP node in a WLCCP CM or AP. The Node Type is CCM, LCM, SCM, AP, MN, or EN.

[0342] Each physical AP (e.g. Ethernet and 802.11) communications interface is identified by a 48-bit IEEE 802 port address. An SCM's LAN communications interface is also identified by a 48-bit IEEE 802 port address. An 802 port address can be re-used as the WLCCP Node Address. Each WLCCP CM must have an IP communications interface, which is identified by an IP port address. An IP port address is not used as a CM node address because a CM's IP address may change.

[0343] AP communications interfaces generally operate in promiscuous mode; therefore, an AP can receive WLCCP frames destined to its Node Address on any physical interface. In a simple implementation, the AP Node Address can be used to identify an internal WLCCP interface in an AP.

[0344] FIG. 19 shows the internal bridging structure in an AP. The Ethernet 802 port address is also the WLCCP Node Address. A frame, which is destined to the Node Address and received on either the Ethernet or 802.11 interface, is bridged internally to the WLCCP protocol interface; therefore, the Node Address can also be used as the WLCCP Hop Address on any AP port. WLCCP and DDP are shown together because they share the same Ethernet DIX type.

[0345] Each WLCCP AP and CM should be configured with a permanent node name e.g. Network Access Identifier (NAI) or a DNS domain name. An LCM must be configured with a node name to request a locally administered Node Address from the CCM.

[0346] A Node ID is NOT a permanent node identifier and should not be used as such. An NAI can be used to represent network nodes to users.

[0347] An Instance Identifier and its Node ID identify each instance of an Attached AP or CM. In WLCCP, an Instance Age is used as the instance identifier, as described below.

[0348] Each WLCCP CM must maintain cross-referenced tables that are used to map a WLCCP Node ID to a node name or IP address, or vice-versa.

[0349] Referring again to FIG. 17, in a campus network, each SWAN AP 1722, 1724, 1726, and 1728 CM 1704, 1706, 1708, 1710, 1712 other than the SWAN CCM 1702, is bound to a single parent node and to a single parent CM. The parent CM for an LCM is the CCM. The parent CM for an SCM is an LCM. Note that a single device may include multiple logical CMs. The device that contains the CCM always contains a logical LCM. In FIG. 17, the parent node and parent CM, for AP 1720, are AP 1728 and SCM 1712, respectively.

[0350] The SCM for each subnet is the parent CM for all APs on its subnet and for all MNs that are associated with those APs. Note that a MN is a child of the SCM for the parent AP's native subnet even if the MN is bound to a different home subnet via VLAN trunking or Proxy MIP tunneling. For example, in FIG. 17, SCM 1708, AP 1722 and AP 1724 all belong to the same subnet. MN 1730 is a child of AP 1722; therefore, it is a child of SCM 1708. However, MN 1730 may belong to a different subnet if AP-1 is attached on a VLAN trunk link.

[0351] The parent node for an LCM or SCM is the parent CM. The parent node for a MN is the 802.11 parent AP. The parent node for a root AP is an SCM. The parent node for a non-root AP is the 802.11 parent AP. A node is considered a child of its parent. A neighbor is a parent or child node.

[0352] A logical link exists between a node and each of its neighbors. A port is the logical entity that provides access to a link. Each CM and AP has a single primary port and one or more secondary ports. A node attaches to the network on its primary port. Multiple logical ports may exist on top of a single physical communications interface. For example, in FIG. 17, AP 1728 may use the same physical 802.11 interface to access the link to AP 1736 and AP 1738; however, AP 1728 has a separate logical port for each link.

[0353] A branch of the Topology Tree is comprised of a set of nodes and links that provide the shortest path between an ancestor node and a descendant node. An inbound node is an ancestor and an outbound node is a descendant. All nodes are descendants of the root CM 1702. An outbound path originates from an ancestor node and terminates at a descendant node. An inbound path originates at a descendant node.

[0354] SWAN CMs are NOT in the forwarding path for non-WLCCP messages; therefore, a node's SWAN path instance is NOT the same as the node's data forwarding path.

[0355] A Topology Tree link exists between each SWAN node and each of its neighbors. A link is established when a child node selects a parent node and registers with the SWAN infrastructure via its parent node. An SCM-to-AP link is always an Ethernet link. An AP-to-AP link can be an Ethernet or 802.11 link. An AP-to-MN link is (currently) always an 802.11 link. A CM-to-CM link can, conceptually, be any link that supports IP.

[0356] A node is responsible for maintaining the link state for each of its neighbors. An active link is in a connected state. A link transitions to a disconnected state if the underlying physical communications link is lost or if a child roams to a different parent node. A node must be able to detect link state changes in its neighbors; otherwise, links may exist in a half-connected state. AP-to-AP 802.11 link state is transparent to WLCCP implemations where WLCCP is not used for Layer 2 path updates.

[0357] The CCM's IP address or domain name must be statically configured in each LCM and in each SCM candidate. It is contemplated that in one embodiment an LCM or SCM can automatically discover the CCM, via a CCM Advertisement Protocol.

[0358] The list of subnets that are bound to each LCM is configured in the CCM. An SCM sends a request message to the CCM, initially and whenever any parent LCM is lost, to obtain its parent LCM assignment.

[0359] An SCM is automatically elected for each subnet. An AP automatically discovers its parent SCM, via an SCM Advertisement Protocol. A non-root child AP is also bound to a parent AP, as described below. A MN is bound to a parent AP via the 802.11 association protocol.

[0360] A node is either in an Attached or Unattached state. A node is initially in the Unattached state. A CCM candidate transitions to the Attached state when it becomes the active CCM. A CCM transitions to the Unattached state when it relinquishes the CCM role. A non-CCM node transitions to the Attached state when it initially registers with the SWAN infrastructure. An Attached non-CCM node transitions to the Unattached state if a) it detects that is parent node is unattached, or b) it is unable to communicate with its parent node.

[0361] Each CM must maintain an internal Instance Age that contains the elapsed time, in seconds, since the node last transitioned to the Attached state. The Instance Age is initialized to 0 and is reset to 0 each time the node initially registers with a new parent CM. The Instance Age of an SCM is copied into the Instance Age field in SCM-Advertisement Reply messages, so that a child AP can detect a new instance of its parent SCM. A child AP becomes Unattached if it receives an advertisement message with a lower Instance Age. In one embodiment, an AP does not need to maintain an Instance Age if WLCCP is not used for Layer 2 path updates.

[0362] A SWAN network generally operates in campus infrastructure mode with a single CCM and corresponding Campus Control Domain. An LCM and its corresponding Local Control Domain must operate in local stand-alone mode if the LCM cannot communicate with the CCM. An LCM must also operate in stand-alone mode if it is not assigned to a CCM. Likewise, each SCM and corresponding subnet must operate in subnet stand-alone mode, if the SCM is not assigned to a parent LCM.

[0363] In stand-alone mode, a Local Control Domain or Subnet Control Domain operates much like a SWAN campus network. An LCM operating in local stand-alone mode assumes CCM functions. The LCM or SCM at the root of a stand-alone domain functions as the 802.1X authenticator for both infrastructure nodes and MNs. A Local or Subnet Control Domain must be able to transition smoothly between infrastructure mode and stand-alone mode.

[0364] An LCM is configured with the IP address of the CCM, to operate in infrastructure mode. If an LCM is operating in stand-alone mode because it lost the link to its assigned CCM, then it must periodically attempt to re-establish communications with the CCM.

[0365] An SCM is configured with the IP address or domain name of the CCM, to operate in infrastructure mode. The CCM is responsible for assigning each SCM to an LCM, as described below in the section entitled W2Parent LCM Assignment.

[0366] An AP must operate in a fallback distributed mode if it cannot discover an SCM for its subnet. An AP must be able to transition smoothly between infrastructure mode and distributed mode. For example, an AP can use the existing Cisco Datagram Delivery Protocol in distributed mode. Note that a user can force APs to operate in distributed mode by simply not configuring any SCM candidates.

[0367] In general, an LCM or SCM can transition smoothly from infrastructure mode to stand-alone (i.e. when the link to its parent is lost) mode without disconnecting nodes in its sub tree. Nodes in a new stand-alone domain can continue to use existing registration information and security credentials, which were previously established in infrastructure mode.

[0368] The sub tree rooted at an LCM or SCM must be rebuilt when the LCM or SCM transitions from stand-alone mode to infrastructure mode. An SCM or LCM establishes a new Instance ID when it transitions from stand-alone to infrastructure mode. An SCM also establishes a new Instance ID if its parent LCM changes. The sub tree rooted at the SCM or LCM is automatically deleted as nodes in the sub tree detect the new SCM or LCM instance.

[0369] WLCCP Context Management message types are listed below. A request and reply subtype is defined for each message type. An optional confirm and ack subtype is defined for select message types that require additional handshaking.

[0370] SCM-Advertisement

[0371] CCM-Advertisement

[0372] Registration

[0373] Preregistration

[0374] Deregistration

[0375] Detach

[0376] Context

[0377] Path-Update

[0378] Path-Check

[0379] Trace

[0380] AAA

[0381] Path-Init

[0382] WLCCP message formats are defined in the section entitled WLCCP Protocol Definitions.

[0383] A Response-Req Flag is set ON in a Request message to solicit a Reply message. In general, a reply message is used to acknowledge a request message and to return status and/or context information to the Originator. A request message identifier is copied into the corresponding reply message to match request/reply pairs. The same message identifier is used in retransmitted request messages, to identify all request/reply messages that belong to a single transaction.

[0384] An optional Confirm message can be used to acknowledge a Reply message and return status and/or context information to the Responder. The Response-Req Flag is set ON in a Reply message to solicit a Confirm message.

[0385] An optional Ack message can be used to acknowledge a Confirm message and return status and/or context information to the Originator. The Response-Req Flag is set ON in a Confirm message to solicit an Ack message.

[0386] WLCCP messages contained a fixed-length header, followed by optional, variable-length TLVs.

[0387] An SCM sends periodic SCM-Advertisement-Reply messages to advertise network parameters and availability and to facilitate the SCM election protocol, on each AP native subnet. APs automatically discover the active SCM for the local subnet by monitoring SCM advertisements. APs receive SCM advertisements on a primary port and forward SCM advertisements on secondary ports to propagate SCM and subnet information to descendent nodes in the SWAN topology.

[0388] A node can send an SCM-Advertisement-Request message to solicit an SCM-Advertisement-Reply message (e.g. to shorten the discovery period).

[0389] A CCM can, optionally, send periodic CCM-Advertisement-Reply messages to advertise network parameters and availability and to facilitate a CCM election protocol. LCMs and SCMs can automatically discover the active CCM by monitoring CCM advertisements. CCM-Advertisement Request and Reply messages are sent to an IP multicast address.

[0390] A node can send a CCM-Advertisement-Request message to solicit a CCM-Advertisement-Reply message.

[0391] A Registration-Request message is used to request registration for a MN, AP, or CM with the SWAN infrastructure. A SWAN node is always registered with the CCM and each LCM, SCM, and AP on the path to the CCM. A Registration-Request is always forwarded inbound on a single branch in the SWAN topology. There are two Registration Request types: An initial Registration Request is generated to establish a new Path Instance. An update Registration Request is used to refresh a Path Instance and to update cached dynamic context information.

[0392] A CM returns a Registration-Reply to acknowledge receipt of a registration request, establish a path instance, and to return context information, including any old mobility bindings. Registration-Reply messages establish the Layer 2 forwarding path on wireless links. A Registration-Reply is always forwarded outbound on the reverse path of the corresponding request.

[0393] Preregistration Request and Preregistration Reply messages are used to obtain security credentials and establish the authentication state for an 802.11 MN or child AP prior to registration.

[0394] A CM sends a Deregistration-Request message to request deletion an old path instance when a station roams. A Deregistration-Request is always generated by a CM (SCM, LCM, or CCM) and is always forwarded outbound on a single branch in the SWAN topology.

[0395] An AP or CM returns a Deregistration-Reply to acknowledge receipt of a Deregistration Request, delete the respective path instance, and (optionally) to return context and status information. Transient accounting statistics and an activity timestamp are (optionally) returned in the Deregistration Reply.

[0396] An AP or CM sends a Detach-Request message to its parent CM to indicate that a detached child station should be deregistered. A Detach-Request message is forwarded inbound until it reaches either a CM with a newer registration record or the CCM.

[0397] A CM can send a Detach-Reply message to acknowledge a Detach-Request.

[0398] A Context-Request message is used to get or set context, configuration, or management information. Context messages provide a general-purpose transport for exchanging information. A Context-Request can be used, for example, to initiate a lateral handoff when a station roams from an old LCM to a new LCM. The new LCM or the old LCM may send the Context-Request. A Context-Request that is generated by the old LCM may contain context and configuration information. A Context-Request message can also be used to predictively forward mobility context for a MN to SCMs or APs. A Context-Request that is used to get information contains one or more request TLVs.

[0399] A Context-Reply message is used to acknowledge a Context-Request message. It is also used to return status information (e.g. for a set request) or context, configuration, or management information (e.g. for a get request) for a corresponding Context-Request message.

[0400] A Path-Update-Request message is used to re-establish the backward-learned path between a wireless station and each correspondent host, when the wireless station roams from an old AP to a new AP within a single subnet. The Path-Update-Request is sent from the new AP to the old AP, with the source 802 address of the station that roamed.

[0401] A Path-Update-Reply message is, optionally, used to acknowledge a Path-Update-Request message and it is used to transfer transient context information directly from an old AP to a new AP.

[0402] A Path-Check message is used to implement a Reliable Path Update mechanism (i.e. to recover from lost Path-Update-Request messages).

[0403] A Trace-Request message is used for SWAN path testing, response time analysis, and station tracking.

[0404] A Trace-Reply is used to acknowledge a Trace Request.

[0405] AAA messages are encapsulated 802.1X EAPOL messages typically used for authentication. Alternately, AAA messages could also be typed to designate the beginning (START) or end (SUCCESS) of an AAA message exchange. Finally, AAA messages are also encapsulated Cisco accounting messages typically used by the AP to update the session accounting maintained by the AS. When the MN is employing Cisco's Central Key Management (CCKM), initial key establishment between the MN and MN Authenticator, is triggered by the MN Authenticator initiating a 4-way handshake by sending the MN an EAPOL Key message with a 16 byte nonce. To achieve this, a nonce is passed from the MN Authenticator to the AP using an AAA Success message. Details of the key establishment is described in the Fast Handoff Protocol Specification 8. This is the only EAPOL Key message generated by the SWAN Topology, all others are results of 802.1X EAP Authentication.

[0406] AAA messages are WLCCP encapsulations of 802.1X EAPOL or Cisco session accounting messages and thus do not follow the Request-Reply norm. However, since Authenticators can detect authentication failures, the Status field provided in the outbound messages can provide more information to reflect authentication status.

[0407] Path-Init Request, Reply, Confirm, Ack. Path-Init messages are used for IN path authentication, where an IN mutually authenticates and establishes a path CTK with each of its ancestors. The necessary path authentication 4-way handshake may consist of 1) a Path-Init Request/Reply exchange followed by an initial Registration Request/Reply exchange, or 2) a Path-Init Request/Reply/Confirm/Ack exchange. (The second sequence is used to refresh path CTKs for a registered IN.)

[0408] WLCCP fields are defined in network byte and bit order (i.e. big endian). The bits in each field are numbered from left to right starting with 0 (i.e. the high-order bit is bit 0).

[0409] WLCCP messages can be encapsulated in Ethernet frames or UDP/TCP/IP packets. Ethernet encapsulation can be used for intra-subnet messages sent between two APs or an AP and SCM, which are on the same subnet. IP encapsulation must be used for inter-subnet messages. The WLCCP Ethernet DIX type is 0x872d. The WLCCP UDP/TCP protocol port is decimal 2887. It is a well-known protocol port that is registered with the Internet Assigned Number Authority.

[0410] A single WLCCP message format is used for both Ethernet and IP encapsulation. All WLCCP messages share a common header format, which is defined below. The header format is defined so that it is unambiguous with existing Ethernet and IP DDP message formats. The WLCCP message body, which follows the common header, contains SAP-specific message types. This document defines message formats for the WLCCP Context Management SAP, which is 0.

[0411] An example Ethernet-encapsulated WLCCP Context Management frame 2000 is shown in FIG. 20. The frame 2000 comprises the destination MAC address 2002, the source MAC address 2004, the DIX Type (0x872D for this example) 2006, WLCCP Common Header 2008, WLCCP Context management header 2010, Type-specific fields 2012, and Optional TLVs 2014.

[0412] In general, Ethernet encapsulation can be used for WLCCP messages that are limited to a single subnet. IP encapsulation is required for all inter-subnet messages. Ethernet encapsulation is used for SCM-Advertisement messages and intra-subnet Registration, Deregistration, Detach, Path-Update, and Path Check messages. UDP/IP encapsulation is used for CCM Advertisement messages and inter-subnet Registration, Deregistration, and Detach messages. Either Ethernet or UDP/IP encapsulation can be used for Trace messages. Ethernet, UDP/IP, or TCP/IP encapsulation can be used for Context messages.

[0413] Sample definitions for the Ethernet-encapsulated WLCCP Context Management frame 2000 are shown below:

define WLCCP_DIX_ETHER_TYPE 0x872d
define WLCCP_DEF_UDP_PROTO_PORT 2887
define WLCCP_IP_MCAST_ADDRESS 0xE0000128 /* 224.0.1.40 */
define WLCCP_MCAST_ADDRESS_IN 0x01, 0x40, 0x96,
0xff, 0xff, 0xC0
Sample WLCCP Node Type Definitions
define WLCCP_NODE_TYPE_ANY	0
define WLCCP_NODE_TYPE_AP	1
define WLCCP_NODE_TYPE_SCM	2
define WLCCP_NODE_TYPE_LCM	4
define WLCCP_NODE_TYPE_CCM	8
define WLCCP_NODE_TYPE_ICN	0x10 /* infrastructure
	client node */
define WLCCP_NODE_TYPE_CLIENT	0x40
define WLCCP_NODE_TYPE_MULTI_MASK0x8000
Sample WLCCP Port Type Definitions
define WLCCP_PORT_TYPE_ETHER	1
define WLCCP_PORT_TYPE_INTERNAL	2
define WLCCP_PORT_TYPE_DOT11	0x80
define WLCCP_PORT_TYPE_DOT11A	0x81
define WLCCP_PORT_TYPE_DOT11B	0x82
define WLCCP_PORT_TYPE_DOT11G	0x83

[0414] An internal port is a logical port that exists between an AP and SCM that are co-located in the same device.

define WLCCP_PORT_COST_ETHER	10
define WLCCP_PORT_COST_INTERNAL	10
define WLCCP_PORT_COST_DOT11	50
define WLCCP_PORT_COST_DOT11A	30
define WLCCP_PORT_COST_DOT11B	50
define WLCCP_PORT_COST_DOT11G	40
1.1.1 Sample Miscellaneous Constants
define DEF_SCM_ADVERTISE_PERIOD	FIVE_SECONDS
define DEF_SCM_LISTEN_TIME	4 * DEF_SCM_ADVERTISE_PERIOD
define MAX_SCM_ELECT_TIME	6 * DEF_SCM_ADVERTISE_PERIOD
define MAX_SCM_AGE	8 * DEF_SCM_ADVERTISE_PERIOD

[0415] Referring now to FIG. 21 there is a table illustrating the fields for a WLCCP Message Header 2100. The columns comprise the Field Name 2102, Offset 2104, Size 2106 and a Description 2108 of each field of the message header 2100.

[0416] The length of the fixed WLCCP header 2100 is 28 bytes. The fields Protocol ID/Version 2110, WLCCP SAP 2112 and Destination Node type 2114 are common to all WLCCP SAPs. The remaining fixed fields are common to all Context Management frames (i.e. all frames defined in this document). If the Relay Flag is set ON, then the header is immediately followed by an 8-byte Relay Node ID field.

[0417] The WLCCP Protocol ID 2110, 0xC0, is defined so that WLCCP and DDP messages can share the same DIX Ethernet type and UDP protocol port. The DDP message header is defined in Appendix B.

[0418] The Destination Node Type 2114 and WLCCP SAP 2112 fields are used to select the internal destination within the device identified by the Ethernet or IP destination address. The sender must set the Destination Node Type 2114 to the node type of the immediate receiver, before sending a WLCCP message. The Destination Node Type 2114 can be 0 if the SAP uniquely identifies the internal destination.

[0419] The Hop Count 2116 field contains the number of WLCCP hops (minus one) between the Originator and Responder. The Originator or Responder must initialize the Hop Count to 0. The Hop Count is incremented by each intermediate node on the path to the Originator or Responder. A message is discarded if the Hop Count exceeds

WLCCP_MAX_HOP_COUNT.

	define WLCCP_MAX_HOP_COUNT	25
	define WLCCP_PROTO_VERSION	1
	define WLCCP_CONTEXT_MGMT_SAP	0x00 /* WLCCP (mobility/context
control) */
	define WLCCP_SECURITY_SAP	0x01
	define WLCCP_RRM_SAP	0x02 /* radio resource management */
	define WLCCP_QOS_SAP	0x03
	define WLCCP_NM_SAP	0x04 /* network management */
	define WLCCP_MIP_SAP	0x05
	WLCCP message Type 2118 definitions:
	define WLCCP_TYPE_SCM_ADVERTISE	1
	define WLCCP_TYPE_CCM_ADVERTISE	2
	define WLCCP_TYPE_REG	3
	define WLCCP_TYPE_DEREG	4
	define WLCCP_TYPE_DETACH	5
	define WLCCP_TYPE_CONTEXT	6
	define WLCCP_TYPE_PATH_UPDATE	7
	define WLCCP_TYPE_PATH_CHECK	8
	define WLCCP_TYPE_PREREG	9
	define WLCCP_TYPE_TRACE	10
	define WLCCP_TYPE_EAP_AUTHEN	11
	define WLCCP_TYPE_PATH_AUTHEN	12

[0420] WLCCP Reply message types are equal to the corresponding request type ORed with WLCCP_TYPE_REPLY_MASK.

[0421] The Flags field 2120 is used as follows:

[0422] The Retry flag is set ON in retransmitted Request or Confirm messages. The Message ID in a retransmitted message is the same as in the original message. The Retry flag is set ON in a Reply or Ack message if it is set ON in the corresponding request message.

[0423] The Response-Req Flag is set ON in a request message to solicit a reply.

[0424] The TLV flag is set ON to indicate that optional TLVs follow the fixed fields.

[0425] The Inbound Flag, Outbound Flag, and Hopwise-Routing Flag determine how a WLCCP message is forwarded (as described below).

[0426] If the Root CM Flag is set ON in an inbound message, then the message is always forwarded to the CM at the root of the entire Topology Treethe root CM. If the Root CM Flag is set ON in an outbound message, then the message originated at the root CM.

[0427] If the Relay Flag is set ON, then the WLCCP header is immediately followed by a 64-bit Relay Node ID field (a 16-bit Node Type followed by a 48-bit Node Address).

[0428] The MIC flag is set ON to in a message that must be authenticated and contains a WTLV_MIC TLV.

[0429] The Responder Node Type bits contain the Node Type of the WLCCP node that generated the original reply message.

[0430] The Originator Node ID 2122, generally, identifies the node that originated a request message. The Responder Node ID 2124 generally identifies the target of a request message and the source of the corresponding reply message. In a WLCCP Registration message for a MN, the Originator Node ID is the 802 address of the MN. The Responder Node ID may be 0 in Registration Request, Advertisement Request, or Detach Request messages. The Responder Node ID may be 0 in any IP-encapsulated Request message. The Responder Node ID identifies the source of a solicited or unsolicited Advertisement Reply message.

[0431] The Hop Source Node ID contains the WLCCP Node ID of the hop source of a request or reply message.

[0432] Optional parameters may follow the fixed fields in any WLCCP message. Optional parameters are in the TLV format as shown in FIG. 22.

[0433] The TLV Type 2210 field contains a Container Flag, an Encrypted Flag, a Request Flag, a Group ID and a Type ID. A request TLV has the Request Flag set ON in the Type ID field.

	define WLCCP_TLV_CONTAINER_MASK	0x8000
	define WLCCP_TLV_ENCRYPTED_MASK	0x4000
	define WLCCP_TLV_GROUP_MASK	0x0300
	define WLCCP_TLV_REQUEST_MASK	0x0080
	define WLCCP_TLV_TYPE_MASK	0x007f

[0434] TLV Group IDs are used to group TLVs hierarchically. A Group ID can be used to identify the software module in the target node that must process the respective TLV type.

[0435] The Request Flag is set on in a TLV in a WLCCP request message to request information from the target WLCCP node. A request TLV has the Request Flag set ON.

[0436] The TLV Container Flag can be used to group fixed attributes and other optional TLVs into a single container TLV. The Container Flag should only be set ON in a TLV if any required TLV fields are followed by other optional TLVs. Container TLVs can be nested.

[0437] TLV Group IDs:

define WTLV_WLCCP_GROUP_ID	0x00
define WTLV_SECURITY_GROUP_ID	0x01
define WTLV_RRM_GROUP_ID	0x02 /* radio resource management */
define WTLV_QOS_GROUP_ID	0x03
define WTLV_NM_GROUP_ID	0x04 /* network management */
define WTLV_MIP_GROUP_ID	0x05

[0438] WLCCP TLV formats are defined in the tables below. The first row in each table contains the TLV name, TLV ID, and TLV description. The description includes a list of message types that may contain the respective TLV. The Type and Length fields are not included in the field definitions.

WTLV_NULL	0x0000	A NULL TLV can be used to pad a
		message for even alignment. The
		length must be at least 4.
WTLV_CONTAINER	0x0001	The generic Container TLV is
		used to logically group arbitrary
		TLVs.

[0439]

		The type, mode, and address
		of an AP port.
		Msgs: Contained in an
		AP_PORT_LIST
		TLV in an AP Registration
WTLV_AP_PORT_INFO	0x0002	Request
Field Name	Offset	Size	Field Description
Type	4	1	1 Ethernet, 2 Internal,
			0x80 802.11, 0x81 802.11a,
			0x82 802.11b, 0x83
			802.11g
Mode	5	1	1 Parent, 2 Child,
			3 Parent/Child
			0x80 Primary Port mask
Address	6	6	802 hardware address
NIC ID	12	2	An integer that is used
			internally to identify the
			NIC type (e.g. Venus radio).
Version	14	N
String
TLV
(optional)

[0440]

		IP Subnet Address. Msgs:
		Contained in an SCM
		Advertisement Reply to
		advertise the IP address
		and subnet of the SCM.
		Optionally contain in a
		PMIP_SSID_LIST TLV in a
		Registration Request to
		bind a PMIP SSID to a
WTLV_IPV4_SUBNET_ID	0x0003	subnet.
Field Name	Offset	Size	Field Description
IPv4 Address	4	4	IPv4 address
Prefix Length	8	1	Number of bits in the
			subnet mask
Flags	9	1	(reserved - must be 0)

[0441]

		A list of Ethernet
		addresses of stations
		on a secondary LAN.
		Msgs: WLCCP Designated
WTLV_SEC_LAN		Bridge Registration
ADDR_LIST	0x0004	Req.
Field Name	Offset	Size	Field Description
Count	4	2	Number of addresses
			in the list
VLAN ID	6	2	VLAN ID of the
			secondary LAN. A
			value of 0
			is used to indicate
			the native VLAN.
Address	8	N 6	A list of Ethernet
List			addresses.

[0442]

		A list of enabled
		multicast Ethernet
		addresses. Msgs:
		Child AP Registration
		Req. (implementation
WTLV_MCAST_ADDR_LIST	0x0005	is optional)
Field Name	Offset	Size	Field Description
Count	4	2	Number of addresses
			in the list
Address List	6	N 6	A list of multicast
			Ethernet addresses.

[0443]

		A list of enabled multicast
		IPv4 addresses. Msgs: AP
WTLV_IPV4		Registration Req.
MCAST_ADDR_LIST	0x0006	(implementation is optional)
Field Name	Offset	Size	Field Description
Count	4	2	Number of addresses in the list
Address	6	N 4	A list of multicast IPv4 addresses.
List

[0444]

		A list of AP_PORT_INFO
		TLVs (see above). Msgs:
WTLV_AP_PORT_LIST	0x0007	AP Registration Requests.
Field Name	Offset	Size	Field Description
Count	4	2	Number of AP ports
Port List	6	N 16	A list of AP_PORT_INFO
			TLVs.

[0445]

		The SSID of an 802.11 Requester
		Node. If the Broadcast
		Translation flag is set ON,
		then the station used a broadcast SSID.
WTLV_SSID		Msgs: Preregistration and Registration
Field		0x0008	Request/Reply
Name	Offset	Size	Field Description
Flags	4	1	Bit 0 - AAA Assigned (set ON in a Reply
			message to assign a MN to the SSID)
			Bit 1 - Broadcast Translation
			Bit 2 - IN WLCCP SSID
			Bits 3-7 - (reserved - must be zero)
Length	5	1	SSID Length (Max. length 32)
SSID	6	N	802.11 SSID

[0446]

		The IPv4 address of a
		Requester Node -
		registered in a Request
		msg or returned in a Reply
		msg. Msgs: Preregistration,
		Registration, Context
WTLV_IPV4_ADDRESS	0x0009	Request/Reply
Field Name	Offset	Size	Field Description
IP Address	4	4	IPv4 address

[0447]

		The BSSID for the BSS of
		an 802.11 MN or AP
		Requester Node.
		Msgs: Registration
		Request for an 802.11
WTLV_PARENT_AP_BSSID	0x000A	station
Field Name	Offset	Size	Field Description
BSSID	4	6	802.11 BSSID of the
			station's current BSS

[0448]

		The previous BSSID of an 802.11
		MN orAP Requester Node
		from the Current AP
		element in an 802.11
		Reassociation Request. Msgs:
WTLV_OLD		Preregistration or Registration
AP_BSSID	0x000B	Request for an 802.11 station.
Field Name	Offset	Size	Field Description
BSSID	4	6	802.11 BSSID of the station's
			previous BSS

[0449]

		A container TLV that contains
		SSID TLVs and for each SSID
		TLV, a list of 0 or more
		MIPV4_AGENT TLVs or a
		SUBNET_ID TLV. The optional
		SUBNET_ID is included only
		if an HA is not known, but
		the subnet address is known.
WTLV_PMIP		Msgs: SCM or AP
SSID_LIST	0x000C	Registration Request.
Field Name	Offset	Size	Field Description
SSID TLV	4	N	SSID TLV which contains
			a PMIP SSID (repeated for
			each PMIP SSID)
MIPV4_AGENT	4 N	6	MIPv4 HA for the default
TLV			subnet bound to the SSID
			(repeated for each HA on
			the subnet).

[0450]

		An SCM uses a request
		PARENT_CM TLV to request
		a parent CM (LCM or CCM)
		from the CCM. If the
		SCM was previously bound
		to a parent CM, then the
		Node ID field must
		contain the old parent
		CM's Node ID; otherwise,
		the Node ID field must
		be 0. Msgs:
WTLV_PARENT_CM		Context Request sent by
(request)	0x008E	an SCM to the CCM.
Field Name	Offset	Size	Field Description
Node ID	4	8	Node ID of any old parent
			CM or 0.
IPv4	12	4	IPv4 address of any old
Address			parent CM or 0.

[0451]

		The CCM uses a PARENT_CM
		TLV to assign an SCM to
		a parent CM (LCM or CCM).
		Msgs: Context Reply sent
WTLV_PARENT_CM	0x000E	by the CCM to an SCM.
Field Name	Offset	Size	Field Description
Node ID	4	8	Node ID of the parent CM.
			A Node ID of 0
			is used to indicate
			no parent CM
			(i.e. standalone mode).
IPv4	12	4	IPv4 address of the
Address			parent CM.

[0452]

		A list of Node IDs of
		deleted nodes. A parent
		SCM or AP uses the
		DELETED_NODE_LIST
		TLV to notify a child
		AP that it must
WTLV_DELETED		reregister. Msgs: SCM
NODE_LIST	0x000F	Advertisement Reply
Field Name	Offset	Size	Field Description
Count	4	2	The number of deleted
			nodes.
Node	6	12	An 8-byte Node ID
Instance			followed by a 4-byte
			Path ID of a deleted
			node. The Node Instance
			field is repeated for
			each deleted node.

[0453]

		The IP address, subnet
		prefix length, and
		capabilities of a MIP
		HA. Msgs: Contained
		in a PMIP_SSID_LIST
		TLV in an SCM or
WTLV_MIPV4_AGENT	0x0010	AP Registration Request.
Field Name	Offset	Size	Field Description
IPv4 Address	4	4	MIP agent IPv4 address
Prefix	8	1	Number of bits in the
Length			agent's subnet mask.
Flags	9	1	Bit 0 - Statically
			Configured
			Bits 1-7 -
			(reserved - must be
			zero)
Capability	10	2	The capability bits are
Bits			the same as the last 16
			bits in a MIPv4 Agent
			Advertisement
			Extension:
			Bits 0-8 - R, B,
			H, F, M, G, H, r, T
			Bits 9-15 -
			(reserved - must be
			zero)
Age	12	2	Elapsed time in seconds
			since an advertisement
			was received from the
			agent.

[0454]

		The Node ID, IPv4
		address, and BSSID of
		the old AP for an 802.11
		Requester Node.
		Msgs: Preregistration
WTLV_OLD		or Registration Reply
AP_BINDINGS	0x0011	for an 802.11 station.
Field Name	Offset	Size	Field Description
Node ID	4	8	Node ID of the old AP
IP Address	12	4	IPv4 address of the old AP
BSSID	16	6	802.11 BSSID of the old BSS

[0455]

		The IP address, MIP HA,
		and subnet prefix
		length of a Proxy MIP
WTLV_HOME		MN. Msgs: Registration
SUBNET	0x0012	Request/Reply
Field Name	Offset	Size	Field Description
IPv4 Address	4	4	IPv4 address of the MN
Prefix	8	1	Number of bits in the
Length			MN's home subnet mask.
			The field can be 0
			if the mask is
			unknown.
Flags	9	1	Bit 0 - At Home Flag
			(set ON if the MN is
			at home)
			Bits 1-7 -
			(reserved - must be
			zero)
HA Address	10	4	IPv4 address of the MN's
			HA. It is the default
			HA for the MN's subnet
			in a Request.
			It is the assigned HA
			in a Reply.

[0456]

		The LOST_LINK TLV is
		used to report a
		lost infrastructure
		link. Msgs: A lost
		secondary link is
		reported in a
		Registration Request.
		A lost SCM primary
		link is reported to
WTLV_LOST		the CCM in a Context
LINK	0x0013	Request.
Field Name	Offset	Size	Field Description
Node ID	4	8	Parent Node ID if the
			Primary flag is set ON;
			otherwise, the child
			Node ID
Reason	12	1	Reason code. 0
			General Error, 1
			Retry Error, 2
			Keepalive Timeout, 3
			Administrative Dereg.,
			4 Beacon Timeout,
			5 Path Cost
Flags	13	1	Bit 0 - Primary (set ON
			for a primary link;
			set OFF for a secondary
			link)
			Bits 1-7 -
			(reserved - must be
			zero)

[0457]

		The hardware and software
		version of an AP or CM
WTLV_VERSION		Requester Node.
STRING	0x0014	Msgs: Registration Request
Field Name	Offset	Size	Field Description
HW Version	4	1	HW version string length
Length			in bytes. The length may
			include null
			padding bytes.
HW Version	5	M	HW Version String
SW Version	5 M	1	SW version string length
Length			in bytes. The length may
			include null
			padding bytes.
SW Version	6 M	N	SW Version String

[0458]

		The Network Access Identifier
		(NAI) or Domain Name of a MN,
		AP, or CM Requester
		Node. Msgs:
WTLV_NAME	0x0015	Registration Request
Field Name	Offset	Size	Field Description
Name Type	4	1	1 NAI, 2
			Domain Name
Name Length	5	1	Name length in bytes
Name	6	N	A string that contains
			the NAI or domain name.

[0459]

		System ID values. Msgs:
WTLV_SYSTEM_ID	0x0016	Registration Request
Field Name	Offset	Size	Field Description
Product ID	4	2	An integer that is used
			internally to identify
			the product type
			(e.g. Ivory AP).
Version String	NA	M	Optional VERSION_STRING
TLV (optional)			TLV - which can contain
			the HW and/or SW version.
System Name	NA	N	Optional NAME TLV -
TLV (optional)			which contains the
			system name.

[0460]

		A list of Node IDs,
		with an entry for
		each node on the path
		to the root CM. Msgs:
WTLV_NODE_ID_LIST	0x0018	Path-Init Request/Reply
Field Name	Offset	Size	Field Description
Count	4	2	The number of Node
			IDs in the list.
Node ID List	6	8 N	A list of Node IDs

[0461]

		An SCM sends a
		MIP_REG_REQ container
		TLV to trigger a
		parent AP to send a
		MIP registration
		request for the
		Requester Node.
		A MIP
		deregistration
		request is sent
		if the MN is at
		home. Msgs: MN
WTLV_MIP4_REG_REQ	0x0019	Registration Reply
Field Name	Offset	Size	Field Description
Flags	4	2	Bit 0 - At Home Flag
			(set ON if the MN is
			at home)
			Bits 1-15 - (reserved -
			must be zero)
Home subnet	6	N	HOME_SUBNET TLV (It
bindings			may be possible to
			just use a flag in
			the HOME_SUBNET TLV)

[0462]

		The authentication
		method(s) used for
		the Requester
		Node. The Fast
		Reauthentication
		Flag is set ON if
		the node used fast
		reauthentication.
		Msgs: Preregistration
WTLV_AUTH_METHOD	0x001A	and Registration Request
Field Name	Offset	Size	Field Description
Base Type	4	2	None 0, Open
			0x0001, Shared Key
			0x0002, LEAP
			0x0004, EAP 0x0008,
			MAC Address 0x0010,
			Alternate 0x0020,
			Client 0x0040,
			Unknown 0x8000
EAP Type	5	1
Fast	6	1	Bit 0 - Fast Reauthen.
Reauthentication			Flag
			Bits 1-7 - Fast
			Reauthen. Type.
			CCKM 1

[0463]

		The IPV4_HOP_ADDRESS
		TLV is used to
		advertise the IP
		address of an AP.
		Msgs: SCM
WTLV_IPV4		Advertisement Reply
HOP_ADDRESS	0x001B	generated by an AP.
Field Name	Offset	Size	Field Description
IP Address	4	4	AP IPv4 address

[0464]

			The EAP Identity
			string of the
			Requester
			Node. Msgs:
			Preregistration and
	WTLV_EAP_IDENTITY	0x001C	Registration Request
	Field Name	Offset	Size	Field Description
	EAP ID Length	4	1	Length of the EAP
				ID in bytes.
	EAP ID	5	N	A string that
				contains the EAP
				ID from the node's
				EAP Identity
				Response message.

[0465]

		The Node ID and IPv4
		address of the 802.1X
		MN authenticator.
		Msgs: IN Registration
		Reply and SCM
		Advertisement Reply.
		The TLV is included
		in SCM Advertisement
		messages to advertise
		a MN authenticator
WTLV_MN_1X_AUTHEN	0x001E	change.
Field Name	Offset	Size	Field Description
Node ID	4	8	Node ID of the 802.1X
			MN Authenticator.
IPv4 Address	12	4	IPv4 address of the
			802.1X MN
			Authenticator.

[0466]

		The Node ID and IPv4
		address of the WLCCP
		Root CM. Msgs: SCM
WTLV_ROOT_CM_INFO	0x001F	Advertisement Reply.
Field Name	Offset	Size	Field Description
Node ID	4	8	Node ID of the root
			CM.
IPv4 Address	12	4	IPv4 address of the
			root CM.

[0467]

		Opaque transaction
		state information.
		REPLY_STATE TLVs
		contained in Request
		messages must be
		copied, in order,
WTLV_REPLY_STATE	0x0020	to Reply messages.
Field Name	Offset	Size	Field Description
Node ID	4	8	Node ID of the node
			that entered the TLV.
State	12	N	Opaque transaction
			state information.

[0468]

		A MN_REG TLV contains any
		information necessary to register
		a MN. It is contained in a
		MN_REG_LIST TLV. Any
		fields that are not described are
		defined the same as the
		corresponding field in
WTLV_MN_REG	0x0021	the Registration header.
Field Name	Offset	Size	Field Description
Requestor	4	8	WLCCP Node ID of the MN.
Node ID
Path ID	12	4	Contains the Path ID assigned to
			the MN in a Reply message.
Registration	16	2
Flags
VLAN ID	18	2
Status	20	1
Age	21	1	Seconds since the MN was last
			active.
Optional	22	N	Optional TLVs (e.g. IPV4
TLVs			ADDRESS or SSID) can be
			included by setting the
			container flag ON.

[0469] Any parameters that are not contained in the WTLV_MN_REG TLV are taken from the Registration message or the encapsulating WTLV_MN_REG_LIST TLV.

WTLV_MN_REG_LIST	0x0022	A list of MN_REG TLVs and o
Field Name	Offset	Size	Field Description
MN_REG TLVs	4	N	Any TLVs, other that MN_REG
an other optional			TLVs, establish default parameter
TLVs.			values for succeeding
			MN_REG TLVs.

[0470] The table below shows the fields for an SCM Advertisement Reply Message.

Field Name	Offset	Size (bytes)	Description
WLCCP Header	0	28	Common Context Mgmt SAP Header
Hop Address	28	6	Source 802 Port Address
SCM Flags	34	2	Bit 15 - Active Flag. Set ON in
			advertisements from the active SCM.
			Bit 14 - Unscheduled Flag (set ON in
			unscheduled advertisement messages)
			Bit 13 - Unattached Flag* (set ON in
			advertisements from an unattached node)
			Bit 12 - Layer 2 Update Flag (set ON if
			WLCCP Layer 2 path updates are enabled.
			Set OFF by default)
			Bits 0-11 - (reserved - must be zero)
SCM Election	36	1	(reserved for future use - must be zero)
Group
Attach Count	37	1	Attach count of the hop source
SCM Priority	38	1	Bits 1-7 - SCM Priority value from 0
			(lowest) to 127 (highest).
			Bit 0 - Preferred Flag - Set OFF if the SCM
			is the preferred SCM.
Bridge Priority	39	1	Bits 1-7 - Bridge Priority value from 0
			(highest) to 127 (lowest).
			Bit 0 - Bridge Disable Flag. Set ON to
			indicate that secondary bridging is disabled.
			The Bridge Priority is used to negotiate the
			WLCCP designated bridge on a non-STP
			secondary Ethernet LAN.
Instance Age	40	4	The instance age of the SCM, in seconds
SCM Node ID	44	6	WLCCP Node ID of the SCM
Path Cost	50	2	Sum of port costs on the path to the SCM
Hop Count	52	1	Number of wireless hops on the path to the
			SCM
Advertisement	53	1	The average number of seconds between
Period			SCM advertisements.
(Optional TLVs)	54	N	(required TLVs are defined below)
*A parent node sends an SCM Advertisement Request with the Unattached Flag set ON to quickly notify child nodes that it has become unattached. If it is unattached because the active SCM was lost, then it must also set the SCM Node ID to 0. The Instance Age field contains the age of the instance of the node that transmits an SCM-Advertisement Reply message, in seconds. (See the section entitled Topology State
#Information for a description of an Instance Number.) An SCM Advertisement Reply message must include a WTLV_SUBNET_ID TLV, which contains the IP address and subnet mask of the SCM.
#An SCM Advertisement Reply message must include a WTLV_ROOT_CM_INFO TLV which contains the IPv4 address of the root CM (which is also the 802.1X IN Authenticator). An SCM Advertisement Reply message sent by an AP can include a WTLV_IPV4_HOP_ADDRESS TLV, which contains the AP's IP address.
define SCM_ADVERTISE_INTERVAL 5 /* The default SCM advertisement interval is 5 seconds. */
define SCM_INFINITE_PATH_COST 0xFFFF
define SCM_INFINITE_HOP_COUNT 0xFF

[0471] The below table shows the fields for an SCM-Advertisement Request Message.

Field Name	Offset	Size (bytes)	Description
WLCCP Header	0	28	Common Context Mgmt SAP
			Header*
Hop Address	28	6	Source 802 Port Address
(optional TLVs)	34	N

[0472] The below table gives the fields for a Registration Request/Reply Message

Field Name	Offset	Size (bytes)	Description
WLCCP Header	0	28	Common Context Mgmt SAP Header
Relay Node ID	28	8	Relay Node Type and Node Address
802 Hop Address	36	6	802 Source Port Interface Address.
Requester Node ID	42	8	WLCCP Node ID of the node that is
			requesting network registration. It is the
			802 address of a MN, in a proxy request.
Registration Sub	50	1	Bit 7 - Initial Registration Flag
Type Flags			Bit 6 - Proxy Registration Flag
			Bit 5 - List Registration Flag
			Bits 0-5 (reserved - must be zero)
Bridging Flags	51	1	Bit 7 - Secondary Bridge Flag
			Bit 6 - Unicast Flooding Flag
			Bit 5 - Multicast Flooding Flag
			Bit 4 - IP Multicast Flooding Flag
			Bits 0-3 - (reserved - must be zero)
Registration Flags	52	2	Bit 15 - Authenticated Flag
			Bit 14 - (reserved - must be zero)
			Bit 13 - Proxy MIP flag
			Bit 12 - L2 Path Update (0 disable,
			1 enable)
			Bits 0-11 - (reserved - must be zero)
Delay	54	2	Time since the node was last active, in
			hundredths of seconds, in a request message.
Path ID	56	4	Path ID establish by a CM. A value of 0 is
			used to indicate no Path ID.
Lifetime	62	1	Registration lifetime in minutes. A value of
			0 is used to indicate an infinite lifetime.
Status	63	1	Registration status in a reply message.
			0-126 - good status
			127 - (reserved)
			128-254 - error status
			255 - extended error status (an extended
			error status is contained in a TLV)
VLAN ID	64	2	Bit 3 - Assigned Flag. Set ON in a Reply if
			the VLAN ID was assigned by the
			infrastructure.
			Bits 4-15 - VLAN ID of the Requester node
			(may be 0).
(Optional TLVs)	66	N

[0473] The Status field contains the registration status in a Reply message. Values from 0 to 126 are used to indicate a good status. The high-order bit is set ON to indicate an error status. Values from 128 to 254 are used to return an error status. A value of 255 is used to indicate that an extended error status code is contained in a WTLV_STATUS TLV.

[0474] Registration Reply status codes:

[0475] 0General good status

[0476] 080General error status

[0477] 081Unauthenticated. The Requester node is not authenticated.

[0478] 082Path Error. A path error was detected. The error will occur, for example, if a parent or relay node is not registered.

[0479] 083Invalid Update. An update Registration Request did not match the current path instance or a path instance did not exist.

[0480] 084Out-of-order. The Registration Request was received out-of-order.

[0481] 085A MIC error occurred.

[0482] 086Admin. Disabled. The Requester node is administratively disabled.

[0483] 087Max. Nodes. The registration was rejected because the max. number of registered nodes was exceeded.

[0484] 088Memory. A registration error occurred due to a lack of internal resources.

[0485] The Authenticated Flag is set ON in a Request for a MN, to indicate that the MN has been authenticated by the parent AP. The flag is used to register authenticated MNs when an AP transitions from distributed to infrastructure mode. It is also set on for a MN where authentication is not required (i.e. open authentication).

[0486] The Proxy MIP Flag is set ON in a Registration message for a proxy MIP MN.

[0487] The L2 Path Update Flag is set ON if WLCCP layer 2 path updates are enabled.

[0488] The VLAN ID in an initial Registration Request for a MN is set to the default VLAN ID for the MN's SSID. The VLAN ID in an initial Reply message for a MN contains an assigned VLAN ID, if the Assigned VLAN ID Flag is set ON. The VLAN ID in a Request for a child AP is always 0. The VLAN ID in an initial Reply for a child AP is the AP native VLAN ID. (A child AP inherits its native VLAN ID from its parent AP.) The VLAN ID in an update Request or Reply can be 0 or the current VLAN ID for the Requester node.

[0489] A WTLV_IPV4_ADDRESS TLV always contains the IP address of the Requester Node. The IP address is included in a Request to register it with the WLCCP infrastructure. The IP address is included in a Reply for a MN to transfer it to the new parent AP.

[0490] An initial Registration Request for a MN must include a WTLV_AUTH_METHOD TLV that contains the MN authentication type.

[0491] An initial Registration Request for an 802.11 station (MN or child AP) must include a WTLV_SSID TLV, which contains the SSID from the station's 802.11 (Re)Association Request message.

[0492] An initial Registration Request for an 802.11 station (MN or child AP) must include a WTLV_PARENT_AP_BSSID TLV, which contains the BSSID of the stations parent AP.

[0493] An initial Registration Request for an 802.11 station, which has reassociated, must include a WTLV_OLD_AP_BSSID TLV, which contains the BSSID from the Old AP field in the respective 802.11 Reassociation Request message.

[0494] A Registration Request for an AP must include a WTLV_AP_PORT_LIST container TLV, which contains a list of one or more WTLV_AP_PORT_INFO TLVs.

[0495] A Registration Reply for an 802.11 station must include a WTLV_OLD_AP_BINDINGS TLV, if the station was previously associated with an old AP.

[0496] The table below shows the format of the Preregistration Request/Reply Message.

		Size
Field Name	Offset	(bytes)	Description
WLCCP	0	28	Common Context Mgmt SAP Header
Header
Relay Node ID	28	8	Relay Node Type and Node Address
Requester	36	8	WLCCP Node ID of the child 802.11
Node ID			station (MN or child AP).
Preregistration	42	2	Bits 0-15 - (reserved - must be
Flags			zero)
(reserved)	44	1	(must be zero)
Status	45	1	Preregistration status in a reply
			message. 0 - good status
VLAN ID	46	2	Bits 0-2 - (reserved - must be zero)
			Bit 3 - Assigned VLAN Flag Bits
			4-15 - VLAN ID of the Requester
			node (may be 0). Default VLAN ID
			in the Request message. Optional,
			assigned VLAN ID in the Reply
			Message.
(Optional	48	N
TLVs)

[0497] The VLAN ID in a Preregistration Request for a MN is set to the default VLAN ID for the MN's SSID. The VLAN ID in a Reply message for a MN contains an assigned VLAN ID, if the Assigned VLAN ID Flag is set ON. The VLAN ID in a Request for a child AP is always 0. The VLAN ID in a Reply for a child AP is the AP native VLAN ID. (A child AP inherits its native VLAN ID from its parent AP.)

[0498] A Preregistration Request for an 802.11 station (MN or child AP) must include a WTLV_SSID TLV, which contains the SSID from the station's 802.11 (Re)Association Request message.

[0499] A Preregistration Request for an 802.11 station, which has reassociated, must include a WTLV_OLD_AP_BSSID TLV, which contains the BSSID from the Old AP field in the respective 802.11 Reassociation Request message.

[0500] A Preregistration Reply for an 802.11 station must include a WTLV_OLD_AP_BINDINGS TLV, if the station was previously associated with an old is AP.

[0501] Referring to the table below, there is shown a Deregistration Request/Reply Message.

		Size
Field Name	Offset	(bytes)	Description
WLCCP	0	28	Common Context Mgmt SAP Header
Header
Relay Node ID	28	8	Relay Node Type and Node Address
Path ID	36	4	Path identifier established by a CM.
Status	40	1	A reason code in a request; a
			status value in a reply.
			The high-order bit of the reason
			code is set ON in administrative
			Dereg. Requests.
Deregistration	41	1	Bit 7 - L2 Path Update (0 disable,
Flags			1 enable)
			Bits 0-6 - (reserved - must be zero)
Registration	42	2	Message ID of the last Registration
Message ID			Request received for the node.
Target Node ID	44	8	WLCCP Node ID of the node whose
			path instance must be deleted.
Activity	52	2	Number of seconds since the target
Timestamp			node was last active, in a Reply
			message.
(Optional	54	N
TLVs)

[0502] The format of the Detach Request/Reply Message is shown below:

		Size
Field Name	Offset	(bytes)	Description
WLCCP	0	28	Common Context Mgmt SAP Header
Header
Relay Node ID	28	8	Relay Node Type and Node Address
Path ID	36	4	Path identifier established by a CM.
Status	40	1	A reason code in a request; a
			status value in a reply.
Detach Flags	41	1	Bit 7 - L2 Path Update (0 disable,
			1 enable)
			Bits 0-6 - (reserved - must be zero)
Requester	42	8	WLCCP Node ID of the node whose
Node ID			path instance must be deleted.
(optional	50	N
TLVs)

[0503] The format of the Path Check Request/Reply message is shown in the table below:

		Size
Field Name	Offset	(bytes)	Description
WLCCP	0	28	Common Context Mgmt SAP Header
Header
Relay Node ID	28	8	Relay Node Type and Node Address
Path ID	36	4	Path identifier established by a CM.
Status	40	1	A reason code in a request; a
			status value in a reply.
Query Flags	41	1	(reserved - must be 0)
Parent Node ID	42	8	Node ID of the parent AP that
			initiated the path check.
(optional	50	N
TLVs)

[0504] Path check usage is defined infra.

[0505] The Path Update Request/Reply Message is shown below:

		Size
Field Name	Offset	(bytes)	Description
WLCCP	0	28	Common Context Mgmt SAP Header
Header
Path ID	28	4	Path identifier established by a CM.
Update Flags	32	2	(reserved - must be 0)
Parent Node ID	34	8	Node ID of the new parent AP
(optional	42	N
TLVs)

[0506] It should be noted that Disassociation Notification messages may be used in lieu of Path Update messages, if it is not necessary to transfer context information directly from an old AP to a new AP.

[0507] The format of the Context Request/Reply Message is given in the table below:

		Size
Field Name	Offset	(bytes)	Description
WLCCP Header	0	28	Common WLCCP Context Mgmt
			SAP Header
(optional TLVs)	28 N	P

[0508] WLCCP AAA messages are used to encapsulate EAPOL and proprietary, e.g. Cisco, accounting messages, so that messages can be forwarded to/from the WLCCP Security SAP in the WLCCP MN or IN Authenticator. For instance, a repeater AP's or MN's EAPOL message will be WLCCP encapsulated by it's parent AP. Additionally, an AP may update the AS with session accounting reports and must thus send the appropriate Cisco proprietary messages.

[0509] The AAA messages need not be encrypted as they are typically either already protected by the original protocol (e.g. EAPOL or Cisco accounting) nor do they need to be authenticated. However, it is good security practice to authenticate (MIC) authentication messages. Optionally, only the MN's EAPOL messages should include a WTLV_MIC. If a WTLV_MIC TLV is included, the contained MIC authenticates the entire WLCCP message using the link's CTK. For instance, if the message is transmitted by an AP to the SCM, the shared CTK between the AP and SCM shall be used. Each hop in the inbound (or outbound) path must authenticate and recompute the MIC, if it is enabled.

[0510] Finally, AAA messages must also indicate whether the state machine has entered into a AAA message as well as when it has completed. To provision these states, the AAA message is further typed accordingly.

[0511] The general format for encapsulated EAPOL and proprietary, e.g. Cisco, accounting messages is as follows:

		Size
Field Name	Offset	(bytes)	Description
WLCCP Header	0	28	Common Context Mgmt SAP Header
Requester Node ID	28	8	WLCCP Node ID of the node that is
			requesting network authentication.
AAA Type	36	1	AAA protocol message type:
			0 - Start
			1 - Finish
			2 - EAPOL
			3 - Cisco Accounting
Authentication	37	1	If AAA Type EAPOL authentication, then it
Type			could be one of the following types:
			0 - EAP only
			1 - MAC only
			2 - do MAC first, if it fails then do EAP
			3 - do MAC and EAP
			4 - LEAP only
			5 - do MAC first, if it fails then do LEAP
			6 - do MAC then do LEAP
Key Management	38	1	Type of (or no) key management negotiated.
Type			Valid values are:
			0 - none
			1 - CCKM
			2 - Legacy 802.1X
			3 - SSN/TGi
Status	39	1	Status field
Message	40	N	AAA message

[0512] The WLCCP AAA messages serve several purposes:

[0513] 1. Distinguish entry and exit of the AAA state

[0514] 2. Encapsulate Cisco accounting messages sent from an AP to the AS to report accounting information.

[0515] 3. Encapsulate EAPOL authentication messages. The first WLCCP (request) message must define the Key Management Type to trigger session key action by the MN authenticator. If CCKM is defined, then the MN authenticator will trigger a EAPOL Key message after receipt of a Radius Access Accept with a securely delivered NSK. Otherwise, the MN authenticator will temporarily hold the NSK to forward to the AP (but will remove the MN's entry upon a pre-registration request).

[0516] 4. Encapsulate EAPOL Key message from the MN authenticator to the MN to initiate CCKM's initial 4-message handshake between the MN Authenticator and MN to establish the KRK and BTK.

[0517] If the AAA message is of type Start, then the message format is only a request message (no reply is expected). The Start message not only initiates the start of the AAA message exchange but it also provides SSID information as well as the AAA authentication or accounting messages to follow. The subsequent AAA messages must match in both AAA Authentication and Key Mangement type defined in the Start request. It's format is as follows:

		Size
Field Name	Offset	(bytes)	Description
WLCCP Header	0	28	Common Context Mgmt SAP Header
Requester Node ID	28	8	WLCCP Node ID of the node that is
			requesting to initiate AAA message exchanges
AAA Type	36	1	0 - for Start
Authentication	37	1	If AAA Type EAPOL authentication, then it
Type			could be one of the following types:
			0 - EAP only
			1 - MAC only
			2 - do MAC first, if it fails then do EAP
			3 - do MAC and EAP
			4 - LEAP only
			5 - do MAC first, if it fails then do LEAP
			6 - do MAC then do LEAP
Key Management	38	1	Type of (or no) key management negotiated.
Type			Valid values are:
			0 - none
			1 - CCKM
			2 - Legacy 802.1X
			3 - SSN/TGi
Status	39	1	Field value is ignored
TLV	40	N	SSID TLV

[0518] When the AAA authentication or accounting exchange is complete, a AAA Finish (reply) message must be issued to terminate the AAA state. The AAA Finish is also used to indicate an AAA success (e.g. EAP or accounting success). If AAA Finish is successful and CCKM is defined as the Key Management, then the Finish message also includes a nonce. The AAA Finish message format is as follows:

		Size
Field Name	Offset	(bytes)	Description
WLCCP Header	0	28	Common Context Mgmt SAP Header
Requester Node ID	28	8	WLCCP Node ID of the node that is
			requesting to initiate AAA message exchanges
AAA Type	36	1	1 - for Finish
Authentication	37	1	Type must match that defined at AAA Start
Type
Key Management	38	1	Type must match that defined at AAA Start
Type
Status	39	1	0 - success
Nonce length	40	2	Should always be set to 16 bytes
Nonce	42	16	16 byte pseudorandom value

[0519] The below table shows the format of the Path-Init Request/Reply/Confirm/ACK Message:

		Size
Field Name	Offset	(bytes)	Description
WLCCP Header	0	28	Common Context Mgmt SAP Header
Relay Node	28	8	Node ID of any intermediate relay AP
Requester Node ID	36	8	WLCCP Node ID of the requesting node to
			establish a CTK to share with the IN
			Authenticator.
Reserved	44	1	Reserved for byte alignment
Status	45	1	Status field
TLV(s)	46	N	Includes either Secure Context or Init Session
			TLVs to establish CTKs.

[0520] The Requester Node must include a Secure Context TLV within the Init Session TLV to ensure that a CTK is mutually derived between the Requester Node and its IA. In the Secure Context TLV, the Requester Node must provide it's nonce and CTK Sequence counter to allow the IA to derive a CTK and be assured the request is not a reply. In initial releases, the rekeys can be discarded if a replay has been detected; the sequence counter is sufficiently large that rekeys should never be exhausted. However, in the case where the value is about to wrap, the IN must re-authenticate. For further details on establishing CTKs refer to the sections on Secure Context TLVs.

[0521] The following 802.11 elements are used to support the operation of WLCCP.

[0522] A WLCCP inter-AP SSID is contained in a standard 802.11 SSID element.

[0523] The general operation of the architecture will now be disclosed.

[0524] A Request message is always forwarded from the Originator to the Responder. A Reply message is always forwarded from the Responder to the Originator. The Inbound and Outbound flags determine how a message is forwarded. If both the Inbound and Outbound flags are set OFF, then a message is forwarded via IP routing and/or transparent bridging to the target destination (i.e. to the Responder in a Request message).

[0525] The Inbound Flag or Outbound Flag is set ON in a message to indicate that the message is being forwarded inbound or outbound, respectively, on a branch of the Topology Tree. It is an error if a node receives an inbound message from a node that is not a descendant. It is also an error if a node receives an outbound message from a node that is not an ancestor.

[0526] The Hopwise-Routing Flag is set ON in an inbound or outbound message to force intermediate APs to process the message, where an intermediate AP is any AP on the topology tree branch between the Originator and the Responder of the message. A hopwise-routed inbound message is forwarded to the hop address of the parent node; an outbound message is forwarded to the Next Hop on the path to the target node. A hopwise-routed message is processed by each node on the inbound or outbound path. It is an error if a node receives a hopwise-routed message from a Hop Source that is not a neighbor.

[0527] The Hopwise-Routing Flag can be used in a registration message, for example, to update Layer 2 path information in each AP on the path to a MN. The Responder is always the SCM in a Proxy Registration message generated by an AP. FIG. 23 illustrates how hopwise routing is used. If Layer 2 path updating is enabled (as in the W2 implementation), then Registration messages are forwarded with Hopwise-Routing set ON. If Layer 2 path updating is not enabled (as in the W1 implementation) then Registration messages are forwarded with the Hopwise-Routing Flag set OFF.

[0528] If the Relay Flag is set ON, in a WLCCP message, then the general WLCCP header is immediately followed by a Relay Node ID field. If the Relay Node ID field is non-zero, then it contains the Node ID of any intermediate node that relayed the respective message. The Relay Node ID is initialized to all zeroes by both the Originator and Responder. As shown in FIG. 23, AP 2304 is the relay node for a hopwise-routed message sent from AP 2306 to the SCM 2302; therefore, AP 2304 must set the Relay Flag ON and enter its Node ID in the Relay Node ID field before forwarding the message inbound to the SCM.

[0529] If the Root CM Flag is set ON in an inbound request message, then the message is always forwarded inbound to the CM at the root of the entire Topology Treethe root CM. In a campus network, for example, the message is forwarded to the CCM. For example, an AP can use the Root CM Flag to forward a MN's IP address to the CCM. The AP can simply send a request message to its parent SCM that contains the MN's IP address and has the Root CM Flag set ON.

[0530] In many cases the original Responder of a request message must forward the message on the path to the final destination. For example, an SCM must forward an inbound Registration Request to its parent LCM if the SCM is not the nearest common ancestor or if the Root CM Flag is set ON. Likewise, an LCM must forward an outbound Deregistration Request to the parent SCM of the Target Node. An original or intermediate relay Responder forwards such a message as follows: a) The Responder field is updated with the Node ID of the next-hop CM, b) The relay Responder enters its Node ID in the Relay Node ID field, c) The Originator and Message ID fields are unchanged. The relay Responder does not update the Responder field in any corresponding Reply message; therefore, the Responder field in the Reply message will contain the Node ID of the final Responder when it is received by the Originator.

[0531] The Originator of a Request message sets the Response-Req Flag ON to solicit a corresponding Reply message. The Originator is always responsible for error recovery if an expected Reply message is not received. An Originator must start a retry timer for each outstanding Request message that requires a Reply. A Request message is retransmitted, with the Retry Flag set ON and the original Message ID, if an expected Reply message is not received before the respective timer expires. A retry timer is not needed in an intermediate relay Responder, which forwards a Request message on the path to the final Responder.

[0532] An Originator or relay node can include a Reply_State TLV in a Request message, to reduce the amount of state information that must be kept in memory. A Reply_State TLV contains information that is necessary to process (e.g. forward) a Reply message.

[0533] AP message forwarding logic is generally independent of the network infrastructure. The parent SCM is the Responder in messages generated by an AP, with one exception. If Layer 2 path updating is enabled, then the Responder in an initial Registration Request generated by a non-root AP is the parent AP. In a local or campus infrastructure, the SCM forwards AP messages to the root CM as required. Likewise, SCM message forwarding logic is the same in a standalone local infrastructure or a campus infrastructure. The parent LCM is always the Responder in messages generated by the SCM. In a campus network, the LCM forwards SCM messages to the CCM, as required.

[0534] A WLCCP node only accepts valid WLCCP messages transmitted on its native VLAN. All other messages are discarded. A message is invalid if it fails a Message Integrity Check or if the message type is unknown.

[0535] The SCM Election and Advertisement Protocol is used to elect a single active SCM for each subnet and to advertise network availability and network parameters. A registered, active SCM sends periodic SCM Advertisement Reply messages, with the SCM Active flag set ON, to a WLCCP all nodes 802 group address. An AP selects its primary port and registers with the active SCM whenever the SCM instance changes.

[0536] The general operational steps for SCM election and advertisement are as follows:

[0537] 1) One or more SCM candidates are configured with a non-zero SCM priority value, on each subnet.

[0538] 2) As an option, each SCM candidate can authenticate with the root CM to establish a shared WLCCP multicast key. The multicast key is used to optionally authenticate multicast SCM Advertisement messages. If SCM Advertisement messages are not authenticated, then authentication is deferred until an active SCM is elected.

[0539] 3) Each SCM candidate sends a Context Mgmt Request message to the CCM. The CCM assigns the SCM candidate to a parent LCM or directs it to operate in stand-alone mode in the Context Reply message.

[0540] 4) In campus infrastructure mode, each SCM candidate initiates Path Authentication with its assigned LCM and the CCM.

[0541] 5) In each subnet, SCM candidates participate in the SCM election protocol to determine the active SCM for the subnet.

[0542] 6) In campus infrastructure mode, the elected active SCM registers with its assigned LCM and the CCM.

[0543] 7) Steps 3-5 are repeated if an active SCM becomes unattached.

[0544] 8) In infrastructure mode, the active SCM begins generating active SCM Advertisements (i.e. advertisements with the Active flag set ON) only after it has successfully registered with the root CM.

[0545] 9) Root APs must register with the active SCM and propagate active SCM Advertisements.

[0546] 10) Other APs must register with the active SCM and propagate active SCM Advertisements. A registered parent AP must send a unicast unscheduled SCM advertisement to a child AP, immediately after the child AP is authenticated.

[0547] The SCM election protocol is described in detail in the section entitled Active SCM Election.

[0548] SCM Advertisement messages contain an IPv4_SUBNET_ID TLV, which uniquely identifies the local subnet, and Path Cost and Hop Count fields. The Path Cost is used to convey the path cost to the primary LAN for the respective subnet. The Hop Count field is used for backward-compatibility with existing APs and radio firmware and contains the number of wireless hops to the primary LAN. An active SCM sends SCM Advertisement Reply messages with the Path Cost and Hop Count fields set to 0.

[0549] SCM advertisement messages must contain a Root CM IP Address TLV, which is used to advertise the IP address of the root CM in the SWAN Topology Tree. The SCM is the Root CM if the SCM is operating in stand-alone mode. If the SCM is operating in infrastructure mode, then the IP address of the LCM or CCM that is at the root of the entire Topology Tree. The Root CM is the default 802.1X authenticator for infrastructure nodes.

[0550] SCM advertisment messages contain a Root CM field, which contains the Node ID of the Root CM. An AP can determine if the Root CM changes by monitoring the Root CM field in SCM advertisements.

[0551] An AP or SCM candidate can send a multicast SCM-Advertisement Request to solicit an unscheduled SCM-Advertisement Reply message. The active SCM must send a unicast unscheduled Reply if it receives a Request on its Ethernet port. An Attached AP must send a unicast unscheduled Reply if it receives a Request on a secondary port from a child AP. The unicast MAC destination address in the unscheduled Reply is taken from the Hop Address in the corresponding Request and is the same as the MAC source address in the Request.

[0552] An AP must NOT forward an SCM-Advertisement Request. The SCM and each Attached AP must maintain the state information that is necessary to generate an unscheduled SCM-Advertisement Reply (i.e. the information used to generate the last scheduled advertisement message).

[0553] An SCM Candidate or AP can set the Responder Node ID to 0 in an SCM-Advertisement Request (i.e. if it does not know the Node ID of the active SCM or parent AP). The actual responder (i.e. the active SCM or a parent AP) must enter its Node ID in the Responder field in the Reply message.

[0554] A non-root AP should set the Responder Node ID, in an SCM-Advertisement Request, to the Node ID of its parent AP, if it is known.

[0555] Initial Authentication is used to fully authenticate a node when it first enters the network. A MN initially authenticates with the MN 802.1X Authenticator; an infrastructure node (AP or CM) initially authenticates with the IN 802.1X Authenticator in the root CM. Initial Authentication messages are encapsulated in 802.1X EAPOL messages on an 802.11 link between a child and parent 802.11 station. Initial Authentication messages are encapsulated in WLCCP AAA messages on all other links.

[0556] An AP or child CM uses Path Authentication messages to mutually authenticate and establish a CTK with each of its ancestors. An AP or child CM initiates Path Authentication after it initially authenticates and whenever it path changes.

[0557] Fast Reauthentication is used to quickly reauthenticate an 802.11 station (MN or child AP) when it roams to a new parent AP. A parent AP uses Preregistration messages to fetch the necessary security context for Fast Reauthentication when an 802.11 station reassociates. Preregistration messages do NOT update the forwarding path.

[0558] Initial Authentication, Preregistration, Fast Re-authentication, and Path Authentication is discussed in detail in the section entitled WLCCP Security Support.

[0559] The WLCCP Registration and Handoff Protocol is used to establish, maintain, and delete branches and path instances in the SWAN Topology Tree. Registration (and deregistration) messages are also use to transfer context information when a node roams. Each authenticated child CM, AP, and MN in a SWAN network is registered with the root of the SWAN Topology Treethe root CM. In general, each CM, AP, and MN in a sub tree is reliably registered with the CM at the root of the sub tree. Example registration and handoff message sequences are shown in following sections.

[0560] The Registration and Handoff Protocol is implemented with three message typesRegistration, Deregistration, and Detach.

[0561] Each MN, AP, and child CM must successfully authenticate (or reauthenticate) before it is registered with the SWAN infrastructure.

[0562] An inbound initial Registration Request is generated to initially register a node with the root CM after it has successfully (re)authenticated. A Registration Request is acknowledged by a Registration Reply that contains a matching Message ID. An outbound initial Registration Reply establishes a Path Instance, which is (optionally) identified by a Path ID. An update Registration Request is used to refresh the registration state of an Attached station. An update Registration Request is also used to update the context information cached in ancestor nodes.

[0563] Proxy Registration Request/Reply messages are used to register WLCCP-unaware MNs. A registered parent AP generates a proxy initial Registration Request for an associated MN after it successfully authenticates.

[0564] A Registration message contains an Initial Flag, which is set ON in an initial Registration message and OFF in an update Registration message. A Registration message has a Proxy Flag, which is set on in a proxy Registration message generated in proxy by a parent AP for a non-WLCCP MN. An initial, proxy Registration message, for example, has both the Initial Flag and the Proxy Flag set ON.

[0565] In general, a Registration Request for a node, which has roamed, is forwarded inbound until it reaches the nearest common ancestor CM. The nearest common ancestor CM is the CM that is at the root of the smallest sub tree that includes the CM and both the old and new parent nodes. For example, the SCM is the nearest common ancestor when a MN roams within a single subnet. An LCM is the nearest common ancestor when a MN roams between subnets in the same Local Control Domain. The nearest common ancestor CM is referred to as the common CM.

[0566] The common CM returns a Registration Reply outbound to acknowledge the Registration Request and to establish a new path instance for the Requester Node. The common CM (optionally) deregisters any old path instance, when it establishes the new path instance for the node.

[0567] A non-parent CM or AP must forward an initial or proxy Registration Reply to the parent of the Requester Node, identified by the Requester Node ID field. Therefore, the parent node is the Originator of any initial or proxy Registration Request that it forwards inbound for a child Requestor Node.

[0568] The Root CM Flag is set ON in a Registration Request to force a full path update. A Registration Request is always forwarded to the root CM if the Root CM Flag is set ON.

[0569] The Path ID field in an initial Registration Request is always set to 0. The parent CM (optionally) establishes the path ID, for a path instance, by entering a path ID value into the Path ID field of an initial Registration Reply. The Path ID field in an update Registration Request is set to the path ID for the path instance.

[0570] A Registration Request is always transmitted with the Response-Req Flag set ON, to solicit a Reply. A Registration Request message is retransmitted if an expected matching Reply is not received, until a REGISTRATION_RETRY_MAX limit is exceeded. The same Message ID is used for the original Registration Request and all retransmissions.

[0571] In general, received Registration Requests are ordered by time-of-arrival. The Registration Delay field is, optionally, used to order received Proxy Registration Requests that are generated by a parent AP for a child node. The Delay field contains the elapsed time, in to hundredths of seconds, since the respective child node last transmitted an uplink frame. A Registration Record in a CM must contain a timestamp field that contains the time-of-arrival of the last Registration Request. The time-of-arrival is calculated by subtracting the Delay value from the current time.

[0572] A parent AP or SCM forwards a Registration Reply to a child AP by sending it to the port MAC address contained in the Hop Source field in the original Registration Request. A parent CCM or LCM forwards a message to a child CM by sending it to the hop IP address of the child CM.

[0573] If WLCCP is used to establish forwarding paths, then an old path instance must be deleted when a node roams. Inbound Deregistration Reply and Detach Request messages are optionally used to delete old path instances. A Deregistration Request is generated by a common CM to delete any old path instance when a new path instance is established. Also, an administrative Deregistration Request can be generated by the Root CM to administratively disconnect a node.

[0574] A parent AP generates a Detach Request, when a child node is disassociated. If the child node is an AP, then the sub tree rooted at the AP is deleted. Deregistration and Detach logic is described in more detail below.

[0575] Each AP in a subnet, and any MNs associated with the AP, are registered with the active SCM for the subnet. An AP discovers the active SCM via the SCM advertisement protocol, as described above. Each MN is registered with the SCM for its parent AP, even if the MN belongs to a different subnet.

[0576] Intra-subnet registration logic is implementation-specific. In the simple W1 implementation, WLCCP registration is used to establish and distribute context information between the SCM and child APs. It is NOT used to establish the Layer 2 forwarding path. The L2-Path-Update Flag is set OFF and the Hopwise-Routing Flag is set OFF in Registration messages in the W1 implementation. Detach and Deregistration messages are not used in the W1 implementation.

[0577] If Layer 2 path updating is enabled, then WLCCP registration reliably establishes the wireless forwarding path between the primary LAN and wireless stations, so that it is never necessary to flood unicast frames to 802.11 stations. Registration, Deregistration, and Detach messages must be forwarded with Hopwise Routing so that each AP on the path instance can process the message. A Registration Reply, for example, is forwarded outbound, with hopwise routing, by sending it to the MAC or IP destination address of the next hop on the path to the target node. A Deregistration Reply or Detach Request is forwarded inbound, with 1s hopwise routing, by sending it to the MAC or IP destination address of the parent node identified in the Parent Node Record.

[0578] Non-WLCCP bridges and switches transparently forward registration messages.

[0579] Referring to FIG. 24 there is shown a block diagram illustrating a mobile node 2412 roaming from a first access point 2408 to a second access point 2410 on a campus network 2400. The network 2400 comprises a CCM 2402 which is an IN 802.1X Authenticator, an LCM 2404 which is a MN 802.1X authenticator, an SCM 2406, a first access point 2408, second access point 2410, and the mobile node 2412.

[0580] The message sequences for registering and deregistring mobile node 2412 are shown in FIGS. 25a and 25b. FIG. 25a shows the message sequences for the mobile node 2412 as it first associates and authenticates with access point 2408, and FIG. 25b shows the message sequences as the mobile node 2412 roams to the second access point 2410. The arrows indicate the direction of the message (sourcedestination or bi-directional) and the vertical bars indicate the network component.

[0581] Referring first to FIG. 25a, the mobile node 2412 associates with the first access point 2408. The steps comprise sending the assocation request 2502 from the mobile node 2412 to the first access point 2408 and the first access point 2408 sending an association response 2504. The mobile node 2412 then authenticates with LCM 2404 (the MN 802.1X authenticator) and the first access point 2408. The mobile node 2412 performs an initial authentication 2506 with the first access point 2408, an EAP authentication 2508 is then performed between the first access point 2408 and the SCM 2406, and a AAA request 2510 is performed between SCM 2406 and LCM 2404.

[0582] For CCKM mobile nodes, preregistration is required. The preregistration starts by the firs access point 2408 sending an initial proxy registration request 2512 to SCM 2406. SCM 2406 then forwards the initial registration request 2514 to LCM 2404 The CCKM preregistration reply 2418 is sent from LCM 2404 to SCM 2406, then as shown by 2516 from SCM 2406 to the first access point 2408, and the first access point 2408 sends the CCKM keying 2530 to the mobile node 2412. The mobile node 2412 can communicate after initial authentication and keying is complete.

[0583] The first access point then sends an initial proxy registration request 2520 to the SCM 2406, the SCM 2406 then forwards the initial proxy registration request request 2522 to the LCM 2404 with the LCM 2404 as the responder, then LCM 2404 forwards the initial registration request 2532 to the CCM 2402 with the CCM as the responder. The CCM 2402 then sends an initial registration reply 2528 to LCM 2404. LCM 2404 then forwards the initial registration reply as shown by 2526 to the SCM 2406. The SCM 2406 then forwards the initial registration reply to the first access point 2408 as shown by 2524.

[0584] Referring now to FIG. 25b, there is illustrated the messaging sequence when the mobile node roams from the first access point 2408 to the second access point 2410. Mobile node 2412 reassociates with the second access point 2410 by sending a reassociton request 2552. access point 2410. The second access point 2410 then sends a preregistratio erquest 2554 to SCM 2406 to obtain the dynamic credentials for the mobile node 2410. SCM 2406 then sends a preregistration reply 2558 to the second access point 2410. The second access point 2412 then sends a reassociation response 2556 to the mobile node 2412. The mobile node 2412 then re-authenticates with the second access point 2410 using its dynamic credentials by fast reauthentication 2560. The mobile node can communicate after reauthentication is complete. The second access point 2410 then sends an initial proxy registration request 2562 to SCM 2406 for the mobile node 2412. SCM 2406 then sends a deregistration request 2564 to the first access point 2408. SCM 2406 then sends a initial registration reply 2566 to the second access point 2410. The first access point 2408 sends a deregistration reply 2568 to SCM 2406. The second access point 2410 sends a path update request 2570 to the first access point 2408.

[0585] Referring to FIG. 27 there is shown a block diagram illustrating a repeater access point 2712 roaming from a first access point 2708 to a second access point 2710 on a campus network 2700. The network 2700 comprises a CCM 2702 which is an IN 802.1X Authenticator, an LCM 2704, an SCM 2706, a first access point 2708, second access point 2710, and the repeater access point 2712.

[0586] The message sequences for registering and deregistring repeater access point 2712 are shown in FIGS. 28a and 28b. FIG. 28a shows the message sequences for the repeater access point 2712 as it first associates and authenticates with access point 2708, and FIG. 25b shows the message sequences as the repeater access point 2712 roams to the second access point 2710. The arrows indicate the direction of the message (sourcedestination) and the vertical bars indicate the network component.

[0587] Referring to FIG. 28a, the repeater AP 2712 (AP 2712) associates with the first access point 2708 (AP 2708). This process comprises AP 2712 sending an association request 2802 to AP 2708 and AP 2708 responding with an association response 2804. AP 2712 then authenticates with CCM 2702, the IN 802.1X Authenticator, and AP 2708 via initial authentication 2806 and AAA 2808.

[0588] AP 2712 then sends a Path-Init request to AP 2708 with AP 2708 as the responder. AP 2708 then sends the Path-Init Request to SCM 2706 as shown by 2812 with SCM 2706 as the responder. SCM 2706 forwards the Path-Init Request to LCM 2704 as shown by 2814 with LCM 2704 as the ersponder. LCM then forwards the Path-Init request to CCM 2702 as shown by 2816 with CCM as the responder. As shown by 2834, CCM 2702 then sends a Path-Init Reply to the LCM 2704 with AP 2708 as the originator. The LCM 2704 sends th Path-Init reply to SCM 2706 with AP 2708 as the originator as shown by 2822. SCM 2706 sends the Path-Init reply to AP 2708 as shown by 2820. AP 2708 sends the Path-Init reply to AP 2712 as shown by 2818.

[0589] AP 2712 then sends an Initial Registration Request 2826 to AP 2708 with AP 2712 as the Responder. AP 2708 sends the Initial Registration Request to SCM 2706 for AP 2712 with SCM 2706 as the Responder at 2828. At 2830, SCM 2706 forwards the Initial Registration Request to LCM 2704 with LCM 2704 as the Responder. Then at 2832, LCM 2704 forwards the Initial Registration request to CCM 2702 with CCM 2702 as the lo Responder. At 2840 CCM 2702 sends an Initial Registration Request Reply to LCM 2704. At 2838 LCM 2704 then forwards the Initial Registration Request Reply to SCM 2706. Then at 2836 SCM 2706 forwards the Initial Registration Request Reply to AP 2708, which then at 2834 forwards the Initial Registration Request Reply to AP 2712.

[0590] Referring now to FIG. 28b there is shown the sequence of messages that occurs when the repeater AP (AP 2712) roams from the first access point 2708 (AP 2708) to a second access point 2710 (AP 2710). The process begins at 2850 when AP 2712 sends a reassocation request to AP 2760 and indicates a fast reauthentication capability. At 2852 AP 2710 then sends a Preregistration Request to SCM 2706 to obtain the dynamic credentials for AP 2712. SCM 2706 sends a Preregistration reply to AP 2710 at 2856. AP 2720 then sends a reassociation response to AP 2712 at 2854. At 2858 AP 2712 reauthenticates with AP 2710 using its dynamic credentials.

[0591] AP 2712 then sends a Path-Init Request to AP 2710 at 2860 with AP 2710 as the Responder. At 2862 AP 2710 sends a Path-Init reuest to SCM 2706 for AP 2712 with SCM 2706 as the Responder. SCM 2706 sends a Path-Init Reply to AP 2710 at 2866 with AP 2710 as the Originator. At 2864 AP 2710 sends a Path-Init Reply to AP 2712.

[0592] At 2872 AP 2712 sends an Initial Registration Request to AP 2710 with AP 2710 as the Responder. At 2874 AP 2710 sends an Initial Registration Request to SCM 2706 for AP 2712 with SCM 2706 as the Responder. At 2876 SCM 2706 sends a Deregistration Request to AP 2708. At 2880 SCM 2706 sends an Initial Registration Reply to AP 2710. At 2878 AP 2710 sends an Initial Registration Reply to AP 2712. At 2882 AP 2708 sends a Deregistration reply to SCM 2706. AP 2710 sends a Path-Update Request to AP 2708.

[0593] A single active SCM is elected for each subnet, as described infra. By default, APs on a subnet operate in distributed mode if no SCM candidates are configured for the subnet

[0594] The active SCM either operates in 1) Stand-alone Mode or 2) SWAN Infrastructure Mode. An SCM operates in Stand-alone mode whenever it cannot communicate with a parent LCM. In Infrastructure Mode, an SCM is registered with a parent LCM and forwards WLCCP messages to its parent CM. SCM operation in infrastructure mode is specified in the section entitled W2SCM Operation.

[0595] The LCM co-located with the CCM is the default backup LCM for all SCMs.

[0596] If an active SCM transitions from Stand-alone mode to Infrastructure mode then any existing sub tree rooted at the SCM must be deleted, to force all nodes in the sub tree to reregister. An SCM resets its Instance Age to 0 to delete its sub tree. Sub Tree Deletion is described in a separate section.

[0597] The sub tree rooted at an SCM does NOT need to be rebuilt when an SCM transitions from Infrastructure Mode to Stand-alone mode. The SCM must function as the IEEE 802.1X authenticator for its subnet, in stand-alone mode.

[0598] The general SCM Data Structures and State Variables will now be described.

[0599] SCM_Advertisement_TimerAn SCM-Advertisement Reply messages is generated by an SCM Candidate or active SCM when the timer expires. The period of the timer is DEF_SCM_ADVERTISE_PERIOD seconds (e.g. 5 seconds).

[0600] SCM_Instance_AgeThe SCM_Instance_Age is initialized to 0 and is reset to 0 whenever an SCM relinquishes the active SCM status. The active SCM increments the SCM_Instance_Age value each time the SCM_Advertisement_Timer expires.

[0601] Authenticated Node TableThe SCM is the 802.1X IN and MN Authenticator IN if the SCM is operating in standalone mode. In standalone mode, the SCM must maintain an Authenticated Node Table, which is a list of Authenticated Node Entries. Each Authenticated Node Entry contains authentication state information for APs and MNs in the sub tree rooted at the SCM. The authentication state in a node entry is initialized to unauthenticated. The state information contained in the table is defined in the section entitled WLCCP Security Support.

[0602] Registration TablesThe active SCM must maintain a Registration Table, which contains state information for each AP and MN in its sub tree. An AP Registration Table contains an AP Registration Record for each AP in its subnet. A MN Registration Table contains a MN Registration Record for each MN that is associated with an AP in the subnet. A Registration Record is created or updated when a Registration Request is received for an AP or MN. A Registration Record contains a cross reference to an Authenticated Node Entry. A MN Registration Record contains a cross reference to the AP Registration Record for the MN's parent AP. A Registration Record is aged and discarded if a successful Registration Request is not received for the respective node with the registration Lifetime.

[0603] SCM Candidate Path Authentication. Each SCM candidate in a campus control domain is automatically assigned to a parent LCM by the CCM using Context Request/Reply messages. An SCM candidate must send a Path-Init Request to its assigned parent LCM, after it has successfully authenticated with the root CM, to initiate Path Authentication. The LCM always forwards the Path-Init Request to the CCM, in campus infrastructure mode. The CCM functions as a KDC to mutually authenticate the SCM Candidate and the LCM and establish a shared CTK. An (optional) WLCCP multicast CTK is forwarded to the SCM during the Path Authentication process. The SCM candidate (optionally) uses the WLCCP multicast CTK to sign SCM Advertisement Reply messages. The CTK shared by an SCM Candidate and the LCM is not used, if the SCM Candidate is not elected as the active SCM.

[0604] Active SCM Election.

[0605] An SCM election protocol is used to elect a single active SCM for each subnet, from a set of one or more SCM Candidates. By definition, the Primary LAN is the wired Ethernet LAN attached to the SCM; therefore, SCM election automatically establishes the Primary LAN for each Subnet. The election protocol is facilitated by SCM Advertisement messages.

[0606] Each SCM candidate is configured with a non-zero SCM priority value from 1 to 255. A WLCCP node is not an SCM candidate if it is configured with an SCM priority value of 0. The high-order bit of the SCM priority value is used as a Preferred SCM flag and is set ON in a preferred SCM. The Preferred SCM flag is set OFF in a backup SCM. Therefore, priority values from 128 to 255 are used for preferred SCM candidates. Normally, there should only be one preferred SCM candidate. Priority values from 1 to 127 are used for backup SCM candidates. The SCM priority value is concatenated with the SCM Node ID for form an SCM Priority ID. The effective relative SCM priority is discussed in detail below.

[0607] The state transition table below defines the operation of the SCM election protocol.

			Next
State	Event	Action	State
Initial	SCM priority is non- zero	Start SCM listen timer with	SCM_CAND
		an average expiration time of
		DEF_SCM_LISTEN_TIME
		seconds; start periodic SCM
		advertisement timer; send
		SCM Advertisement Request
SCM_CAND	Receive higher-priority	Restart SCM listen timer	SCM_BACKUP
	SCM Advertisement	with an expiration time of
		MAX_SCM_AGE seconds
SCM_CAND	Receive SCM	Send an SCM Advertisement	SCM_CAND
	Advertisement request or	with the active flag set OFF
	lower-priority SCM
	Advertisement reply
SCM_CAND	SCM advertisement timer	Send an SCM Advertisement	SCM_CAND
	expires	with the active flag set OFF
SCM_CAND	SCM listen timer expires	Reset SCM Instance Age to	SCM_ACTIVE
		0; send SCM Advertisement
		with the active flag set ON;
		restart SCM advertisement
		timer
SCM_BACKUP	Receive higher-priority	Restart the SCM listen timer	SCM_BACKUP
	SCM Advertisement	with an expiration time of
		MAX_SCM_AGE seconds
SCM_BACKUP	SCM listen timer expires	Restart the SCM listen time	SCM_CAND
		with an expiration of
		DEF_SCM_LISTEN_TIME
		seconds; restart periodic
		SCM advertisement timer;
		send SCM Advertisement
		with the active flag set OFF
SCM_ACTIVE	Receive higher-priority	Start SCM listen timer with	SCM_BACKUP
	SCM Advertisement. (The	an expiration time of
	effective priority of the	MAX_SCM_AGE seconds
	received Adver. is higher
	if a) the priority value is
	higher, or b) the active flag
	is ON and the Priority ID is
	higher.)
SCM_ACTIVE	Receive an SCM	Send unicast unscheduled	SCM_ACTIVE
	Advertisement request or a	SCM Advertisement with the
	lower-priority SCM	active flag set ON
	Advertisement Reply
SCM_ACTIVE	SCM advertisement timer	Send scheduled SCM	SCM_ACTIVE
	expires	Advertisement with the
		active flag set ON; restart the
		SCM advertisement timer

[0608] The SCM election/advertisement protocol operates on a single native VLAN that is shared by SCM candidates and APs. SCM Advertisement messages that are received on any other VLAN are ignored.

[0609] An SCM Candidate is configured with a non-zero SCM priority value. Each SCM candidate has an SCM Priority ID which consists of the concatenated SCM priority value and the SCM Node Address. The rules for the effective relative SCM priority are as follows:

[0610] 1) An SCM candidate or active SCM has a relatively higher priority if it is configured with a higher priority value.

[0611] 2) A first SCM candidate has a relatively higher priority than a second SCM Candidate if it has an SCM Priority ID that is lexicographically higher.

[0612] 3) A first active SCM has a relatively higher priority than a second active SCM if it has an SCM Priority ID that is lexicographically higher.

[0613] 4) An SCM candidate has a relatively higher priority than an active SCM if it is configured with a higher priority value. If an SCM Candidate is configured with the same or a lower priority value than an active SCM, then it has a relatively lower priority than the active SCM.

[0614] The effective priority is structured so that an SCM Candidate will not replace an active SCM with the same priority value, even if it has a higher Node ID. However, the user can explicitly select the active SCM by configuring a higher priority value.

[0615] An SCM candidate initially enters an SCM_CANDIDATE state to listen for SCM advertisements on its Ethernet port. The SCM candidate remains in the SCM_CANDIDATE state for a listen period which exceeds 3 SCM advertisement intervals or until it discovers a higher-priority SCM. An SCM candidate enters the SCM_ACTIVE state if it does NOT receive a higher-priority SCM advertisement message within the listen period. In infrastructure mode, the elected active SCM must immediately register with its parent LCM and the CCM. The active SCM sets the SCM Active flag ON in its SCM Advertisement Reply messages after it has successfully registered or enters stand-alone mode.

[0616] An SCM candidate or active SCM enters an SCM_BACKUP state if it discovers a higher priority SCM.

[0617] An AP or SCM candidate must send an SCM Advertisement Request message, to the WLCCP all INs group address, on each port when the port is first enabled. A node in the SCM_ACTIVE or SCM_CANDIDATE state responds by sending an SCM Advertisement Reply. A node in the SCM_CANDIDATE state sets the SCM Active flag OFF in the reply and sets the Path Cost and Hop Count fields to infinite values.

[0618] As an option, multiple active SCMs can be elected for a single subnet. An SCM Advertisement Request message contains an SCM Group Election field for that purpose. The field contains the number of SCM election groups and the group ID assigned to the respective SCM candidate (i.e. identified by the SCM Node ID). The group ID must be less than the number of election groups. An SCM candidate only considers SCM Advertisements from other candidates in the same group, so that an active SCM is elected for each group. Registrations are distributed across multiple active SCMs. The algorithm for determining the active SCM for a node is described in the section entitled WLCCP Registration Protocol.

[0619] The elected active SCM transmits SCM Advertisement Reply messages, with the Active Flag set ON, once per Advertisement Period. The fields in SCM_Advertisement Reply messages sent by the active SCM are set as follows:

[0620] WLCCP header fields:

[0621] Type041 (SCM-Advertisement Reply)

[0622] Originator0.

[0623] ResponderSCM Node ID.

[0624] Outbound Flag1.

[0625] TLV FLag1 (the Request must include an IPV4_SUBNET TLV and an ROOT_CM_INFO TLV).

[0626] SCM_Advertisement Reply fields:

[0627] Hop_AddressThe SCM Ethernet port address.

[0628] SCM Flags:

[0629] Active Flag1

[0630] SCM PriorityUser-configured SCM Priority.

[0631] SCM Node IDSCM Node Type and Ethernet port address

[0632] Instance AgeSCM_Instance_Age value.

[0633] Path Cost0

[0634] Hop Count0

[0635] Advertisement PeriodDEF_SCM_ADVERTISE_PERIOD seconds.

[0636] WTLV_IPV4_SUBNET_ID TLVIPv4 address and prefix length of the SCM

[0637] WTLV_ROOT_CM_INFO TLVContains the IPv4 address of the root CM (which is also the 802.1X IN Authenticator).

[0638] SCM Registration.

[0639] An SCM must register with the root CM immediately after it is elected as the active SCM for its subnet. Note that it has already completed Path Authentication. The elected active SCM sends an initial Registration Request its assigned parent LCM. The LCM always forwards the initial Registration Request inbound to the CCM, in campus infrastructure mode. The CCM returns an initial Registration Reply message to the parent LCM, which forwards the Registration Reply message to the SCM. The Reply message contains the Node ID and IP address of the root CM in a Root CM TLV.

[0640] The SCM must generate periodic update Registration Request messages to refresh its registration bindings in the parent LCM and CCM. The update Registration Request messages are always forwarded to the root CM. The root CM returns an update Registration Reply message, to acknowledge the Registration Request. The parent LCM resets the age of the DPR, for the SCM, to 0 when it receives a matching Registration Request with a good status. A parent LCM must delete the sub tree rooted at the SCM if it does not receive an update Registration Reply message for the SCM with the registration Lifetime.

[0641] An SCM must repeat the path authentication and initial registration processes whenever it is assigned to a different parent LCM instance.

[0642] Genearal AP operations will now be discussed.

[0643] A WLCCP AP either operates in 1) Distributed Mode or 2) SWAN Infrastructure Mode.

[0644] The AP operational mode depends on the presence of an SCM and on an AP Operational Mode parameter, which can be set to one of the following values:

[0645] a) Infrastructure-only

[0646] b) Automatic-fallback (default)

[0647] A WLCCP AP always operates in infrastructure mode if it discovers a SWAN SCM. An AP operates in distributed mode if it cannot register with the active SWAN SCM and Operational Mode is set to Automatic-fallback. The CISCO Datagram Delivery Protocol (DDP) is used as the inter-AP protocol, in distributed mode. It should be noted that a WLCCP Context or Path-Update messages can be used, in distributed mode, to directly transfer context from an old AP to a new AP, when a station roams. The old AP MAC address can be obtained from an 802.11 Reassociation message. Each AP must function as the 802.1X authenticator, in distributed mode. APs should operate in distributed mode if the network contains non-WLCCP APs.

[0648] An AP can NOT operate in distributed mode if Operational Mode is set to Infrastructure-only.

[0649] AP operation in infrastructure mode is generally the same in a standalone subnet infrastructure, a standalone local infrastructure, or a campus infrastructure.

[0650] An AP that is operating in infrastructure mode is considered Attached if it is registered with the active SCM; otherwise, it is considered Unattached. An AP that is operating in distributed mode is considered Attached if it has a good Ethernet link, which is configured in parent or parent/child mode (see below), or if it is associated with a parent AP; otherwise, it is considered Unattached. An Unattached AP must prohibit 802.11 station associations, to prevent stations from associating with an AP that cannot provide access to the Primary LAN. A management station can use a special Management SSID to associate with an Unattached AP, when other station associations are prohibited.

[0651] A child 802.11 bridge or repeater AP cannot operate in infrastructure mode unless it is associated with a parent AP that is operating in infrastructure mode. A parent AP that is operating in infrastructure mode transmits periodic SCM Advertisement Reply messages to child APs and bridges.

[0652] Below is a list of general AP state variables.

[0653] Infrastructure_ModeTRUE if there is an active SCM; otherwise, FALSE.

[0654] AP_Top_Level_StateContains the current top-level AP state. Top-level AP states and top-level state transitions are described in the section entitled AP Operational Modes.

[0655] Parent_SCM_Recordcontains the following information about the active parent SCM:

[0656] SCM_Node_IDThe Node ID of the active SCM copied from the SARpM.

[0657] SCM_AgeIncremented once per SCM Advertisement Period. Reset to 0 when an active SARpM is received. Infrastructure_Mode is reset to False when the SCM_Age equals MAX_SCM_AGE.

[0658] SCM Instance_AgeThe Instance Age of the SCM copied from the SARpM.

[0659] SCM_Subnet_AddressIPv4 Address and (optional) Subnet Mask of the SCM copied from a WTLV_IPV4_SUBNET_ID TLV in the SARpM.

[0660] SCM_PriorityThe priority of the active SCM copied from the SCM Priority field in the SARpM.

[0661] SCM_Advertisement_PeriodThe number of seconds between scheduled SCM advertisements copied from the Advertisement Period field in the SARpM.

[0662] SCM_Path_CostThe Path Cost value from the SARpM, plus the cost assigned to the AP's primary port.

[0663] SCM_Hop_CountThe Hop Count value from the SARpM, plus 1 for the primary port.

[0664] SCM_Advertisment_Timer (optional)A timer that expires once per SCM Advertisement Period when WLCCP is enabled. The duration of the timer is SCM Advertisement_Period seconds (see above).

[0665] IN1X_AuthenticatorNode ID and IPv4 Address of the WLCCP Infrastrucutre 802.1X Authenticator, which is always the SCM in the simple WLCCP implementation.

[0666] An AP must monitor SCM Advertisement Reply messages received on its primary port on the native VLAN to determine if there is an active SCM for the native VLAN. An AP operates in infrastructure mode and executes the WLCCP protocol if there is an active SCM for the AP's native VLAN.

[0667] An AP must update its Parent SCM Record each time it receives an SCM Advertisement Reply message. Infrastructure mode is enabled when an AP first receives an SCM Advertisement with the Active_Flag set ON. An AP must generate SCM Advertisement Reply messages on each of its secondary ports,using one of the following methods: 1) An AP can simply generate SCM Advertisements on each of its secondary ports when it receives an SCM Advertisement on its primary port, or 2) an AP can start a periodic SCM_Advertisement_Timer and generate SCM Advertisements on its secondary ports each time the timer expires. The period of the timer is the non-zero Advertisement Period value in advertisements received on the primary port. The first method must be used if the Advertisement Period value is zero in advertisements received on the primary port.

[0668] A repeater AP must send a multicast SCM Advertisement Request on its primary port when it first associates with a parent AP, to solicit a unicast unscheduled SCM Advertisement Reply message.

[0669] The AP top-level state transition table below specifies SCM_Advertisement Reply message (SARpM) processing logic. An active SARpM has the Active Flag set ON.

[0670] The IN 802.1X Authenticator is in the root CM when the AP is in the I,R state; otherwise, the IN 802.1X Authenticator is in the AP. Preregistration and Registration of MNs is only enabled in the I,R state.

[0671] AP top-level states are described below:

[0672] D,*Any state in Distributed mode. Infrastructure_Mode is False, because the AP has not discovered an active SCM.

[0673] D,LThe AP is in a power-up SCM discovery period.

[0674] D,AThe AP is actively operating in Distributed mode and is accepting station associations.

[0675] D,SCThe AP discovered an SCM Candidate during the power-up SCM discovery period.

[0676] I, UInfrastructure_Mode is True and the AP has not authenticated with the root CM.

[0677] I, AInfrastructure_Mode is True and the AP has successfully authenticated with the root CM.

[0678] I, PThe AP has successfully completed Path Authentication.

[0679] I, RThe AP has successfully Registered with the root CM; MN (pre)registration is enabled.

[0680] I,*Any state where Infrastructure_Mode is True.

[0681] Top-level AP State Transition Table

State	Event	Action	Next State
Initial	System reset; good Ethernet link;	Start an SCM Listen timer	D, L
	Auto-fallback is enabled	with a 10-second expiration
		time; send SCM Advertisement
		Request
D,*	Receive active SARpM	Set Infrastructure_Mode to	I, U
		TRUE; Update the Parent SCM
		Record and the
		IN_1X_Authenticator; Initiate
		authentication with the SCM
D, L	Receive inactive SARpM	restart SCM Listen timer with a	D, SC
		MAX_SCM_ELECT_TIME
		expiration time; Save SCM
		Candidate Priority ID
D, SC	Receive higher-priority inactive	restart SCM Listen timer with a	D, SC
	SCM Advertisement	MAX_SCM_ELECT_TIME
		expiration time; Save SCM
		Candidate Priority ID
D, L	SCM Listen timer expires	Start active operation in	D, A
		distributed mode.
D, SC	SCM Listen timer expires (i.e.	Start active operation in	D, A
	because the active SCM election	distributed mode.
	did not complete)
D, A	Receive inactive SARpM	(none)	D, U
I, U	Authentication with the root CM	Initiate Path Authentication.	I, A
	completes successfully.
I, A	Path Authentication completes	Initiate AP Registration	P
	successfully
I, P	Registration completes	Enable MN Preregistration and	I, R
	successfully	Registration; Register
		authenticated MNs; transfer the
		MN 802.1X Authenticator
		function to the SCM; start the
		SCM_Advertisement_Timer
I, *	Receive an active SARpM from	Reset the SCM_Age to 0;	I, *
	the active SCM instance.	Update the Parent_SCM_Record
I, *	Receive inactive SARpM or an	Set Infrastructure_Mode to False	D, U
	active SARpM, with a lower
	Instance Age, from the active SCM
I, *	Receive a higher priority active	Update the SCM state	I, U
	SARpM from a different priority	information; Initiate
	SCM	authentication with the new
		active SCM
I, *	Receive an inactive SARpM or a	(none)	I, *
	lower priority active SARpM from
	a different SCM (Candidate)
I, R	SCM_Advertisement_Timer	Restart the timer with the current	I, R
	expires; the SCM_Age is less than	Advertisement Period; Increment
	MAX_SCM_AGE	SCM Age; Generate SARpMs
		on each secondary port
I, R	SCM_Advertisement_Timer	Set Infrastructure_Mode to False	D, U
	expires; the SCM_Age is equal to
	MAX_SCM_AGE

[0682] SCM Advertisement Reply messages are NOT transparently forwarded by WLCCP APs. Instead, a registered AP generates secondary SCM Advertisement Reply messages, on each of its active secondary ports, with the same period as the SCM. The advertisement period is contained in SCM Advertisement Reply messages. SCM Advertisement Reply messages are NOT transmitted on the AP primary port or on AP ports that are blocked by the underlying STP.

[0683] SCM advertisements, which are transmitted on AP secondary ports, contain updated path cost and hop count values. Each AP port is assigned a user-configurable path cost. Default path cost values are defined for each AP port type (e.g. Ethernet, 802.11a, 802.11b). The updated path cost is calculated by adding the path cost assigned to the AP's primary port to the parent AP's path cost (i.e. the path cost in SCM advertisements received on the primary port); the hop count is incremented by 1, if the AP's primary port is a wireless port. A subnet address and updated path cost and hop count information is also advertised in 802.11 Beacon and Probe Response messages, sent on AP 802.11 secondary ports, so that unassociated wireless APs and MNs can quickly discover the least-cost path to the primary LAN (i.e. without iteratively associating and authenticating with each potential parent AP).

[0684] An AP may register with a logical SCM that is contained in the same hardware box. In that case, the cost assigned to the internal primary port should be consistent with Ethernet port cost (i.e. to prevent stations from migrating to an AP that is co-located in the same box as an SCM).

[0685] A non-SWAN AP may transparently forward SCM Advertisement Reply messages generated by a different SWAN node. A child AP must discard any SCM Advertisement Reply messages that are not generated by its parent. A child AP can use the SCM Advertisement Hop Source field to determine if its parent AP generated an SCM Advertisement message. The Hop Source address must be the same as the parent AP's Hop Address.

[0686] Root APs are always bound to the active SCM on the native VLAN. A Root AP only receives SCM Advertisement Reply messages on its native VLAN on the primary port. A non-root AP must belong to the same subnet as its parent AP; therefore, a non-root AP is always bound to the same SCM as the parent (or ancestor) root AP.

[0687] SWAN APs are configured with a single WLCCP SSID. A campus-wide WLCCP SSID is sufficient if a campus network only contains root APs or if non-root APs can dynamically bind to any subnet. Subnet-specific WLCCP SSIDs can be used to bind non-root APs to a specific subnet (i.e. the subnet with root APs with a matching WLCCP SSID). A child AP can use DHCP to dynamically bind to a subnet; however, the native VLAN and the set of enabled VLANs in a parent and child AP must match.

[0688] A child 802.11 port (i.e. in a repeater AP or child 802.11 bridge) uses the WLCCP SSID to associate with a parent AP. A child AP sends Probe Requests that contains the WLCCP SSID and potential parent APs reply with a Probe Response that also contains the WLCCP SSID. A child AP can only attach to a parent AP with a matching WLCCP SSID.

[0689] An AP or child CM must authenticate its path to the root CM, after it has successfully authenticated with the 802.1X IN Authenticator, to mutually authenticate and establish a secret Context Transfer Key (CTK) with each ancestor node on its branch of the SWAN Topology Tree. An AP must also initiate path authentication whenever it detects a new SCM instance. A non-root AP must also initiate path authentication whenever it roams to a new parent AP. As an option, a non-root AP does not need to fully authenticate when it roams, if fast reauthentication is supported for child APs.. Path authentication includes a Path-Init Request/Reply exchange and initial Registration Request/Reply exchange. Path Authentication and CTK updates are described in more detail in the section entitled Infrastructure Path Authentication.

[0690] An Unattached AP must send a Path-Init Request to its selected parent node, on its selected primary port, to initiate path authentication. The Originator is the Unattached AP; the Requester is also the Unattached AP; and the Responder is the selected parent node (i.e. parent AP or SCM), in the Path-Init Request and the corresponding Reply.

[0691] Non-security fields in a Path-Init Request, sent by an Unattached AP, are set as described below. (Unspecified fields are set to 0.) The Hopwise-Routing Flag is set to 1 so that each ancestor AP on the path to the SCM processes the Request and the corresponding Reply. Security TLVs included in Path-Init messages (and initial Registration messages).

[0692] WLCCP header fields:

[0693] Type12

[0694] OriginatorNode ID of the Unattached AP.

[0695] ResponderNode ID of the SCM.

[0696] Response-Req Flag1 to solicit a Reply.

[0697] Inbound Flag1.

[0698] Hopwise-Routing Flag1 if Layer 2 Path Updates are enabled; otherwise 0.

[0699] Root CM Flag1

[0700] TLV FLag1 (The Request must include an EAP_IDENTITY_TLV.)

[0701] Path-Init fields:

[0702] RequesterNode ID of the AP.

[0703] Relay Node ID0.

[0704] Proxy Flag0.

[0705] The parent node must forward a Path-Init Request from an Unattached AP or CM inbound until it reaches the root CM. The parent node enters its Node ID in the Originator field and the Node ID of its parent CM in the Responder field, before forwarding the request inbound. An intermediate LCM must update the Responder field with the CCM Node ID before it forwards the request inbound to the CCM. The CCM returns a Path-Init Reply to the parent node (i.e. the Originator). The parent node updates the Responder field with the Requester Node ID before forwarding the Reply to the Unattached AP or CM.

[0706] An AP must authenticate with the root CM before it can register with the SWAN infrastructure. An AP discovers the root CM via a WTLV_ROOT_CM TLV contained in SCM advertisement messages. The root CM may be the local SCM, an LCM, or the CCM.

[0707] An Unattached AP scans for a potential parent SCM or AP on each of its ports that are configured in child or parent/child mode. Note that an Attached AP becomes Unattached if it discovers a new instance of its parent AP or SCM. An Unattached AP or CM must send an initial Registration Request to its selected parent node, on its selected primary port, to request attachment to the network. The Originator is the Unattached AP; the Requester is also the Unattached AP; and the Responder is the selected parent node (i.e. parent AP or SCM), in the initial Registration Request and the corresponding Reply.

[0708] The fields in an initial Registration Request sent by an Unattached AP are set as described below. (Unspecified fields are set to 0.)

[0709] WLCCP header fields:

[0710] Type3

[0711] OriginatorNode ID of the Unattached AP.

[0712] ResponderNode ID of the selected parent node (parent AP or parent SCM).

[0713] Response-Req Flag1 to solicit a Reply.

[0714] Inbound Flag1.

[0715] Hopwise-Routing Flag1.

[0716] TLV FLag1 (the Request must include a WTLV_AP_PORT_ADDRESS TLV for each AP port).

[0717] Registration fields:

[0718] RequesterNode ID of the Unattached AP.

[0719] Hop Address802 address of the Unattached AP's selected Primary Port.

[0720] Relay Node ID0 in a registration message generated by the Originator or Responder. Otherwise, the Node ID of an intermediate relay node that forwarded the message.

[0721] Initial Flag1.

[0722] VLAN IDThe native VLAN ID of both the Unattached AP and the parent node. The VLAN ID value may be 0. It is an error if the VLAN ID value is different than the parent node's native VLAN ID.

[0723] The parent node must forward an initial Registration Request from an Unattached AP inbound until it reaches the root CM. The parent node enters its Node ID in the Originator field and the Node ID of its parent CM in the Responder field, before forwarding the request inbound. An intermediate LCM must update the Responder field with the CCM Node ID before it forwards the request inbound to the CCM. The CCM returns a Registration Reply to the parent node (i.e. the Originator). The parent node updates the Responder field with the Requester Node ID before forwarding the Reply to the Unattached AP or CM.

[0724] An AP periodically sends an update Registration Request message to the SCM to refresh its mobility bindings in each node on the path to the SCM. An update Registration Request has the Initial Flag set OFF and it contains a valid Path ID. An Attached AP or CM can send an update Registration Request directly to its parent CM, with itself as both the Originator and the Requester Node and the parent CM as the Responder. The parent CM must update the Responder field, with the Node ID of its parent CM, before forwarding the request inbound.

[0725] An AP (re)transmits a Registration Request either until it receives a Registration Reply with a matching message ID, or until the maximum retries are exceeded. An AP is registered when it receives a matching Registration Reply with a good RegStatus. The Registration Reply contains a Path ID, set by the SCM, which identifies the path instance from the AP to the SCM.

[0726] A Registration Request from an AP must include a WTLV_AP_PORT_LIST TLV, which contains a list of WTLV_AP_PORT_INFO TLVs. Each PORT_INFO TLV includes the port type, port mode (parent, child, or parent/child), and 802 port address of a physical communications interface.

[0727] A Registration Request from an AP must include an IP Address TLV to bind its IP address to its Node ID. An AP must generate an update Registration Request immediately whenever its IP address changes.

[0728] A Registration Request from an AP, which is configured with a Proxy MIP SSID, must include a WTLV_PMIP_SSID_LIST TLV, which contains a list of Proxy MIP SSIDs and MIP HA bindings.

[0729] Preregistration messages are used to obtain context information that is required prior to registration. A new parent AP, optionally, sends a Preregistration Request message, to its parent SCM, to obtain dynamic credentials and old AP bindings for an 802.11 station (MN or child AP) when it reassociates. A Preregistration Request is NOT generated when an 802.11 station initially associates. The parent AP generates a Preregistration Request when it receives 1) an 802.11 Reassociation Request or 2) an 802.1X EAP Identity Response message from the 802.11 station. The Preregistration Request contains the child station's Node ID and its security Identifier.

[0730] A Preregistration Request is forwarded inbound to the nearest common ancestor CM of the old AP and new AP (with some restrictions noted below). If the common CM has the mobility bindings and security context for the child station, then the old AP bindings and dynamic credentials are returned in a Preregistration Reply message. Otherwise, a Preregistration Reply is returned with a not found status and the station must fully authenticate.

[0731] A Preregistration Request for a MN is never forwarded beyond the nearest common LCM, since the LCM is the MN Authenticator. An AP cannot roam across subnet boundaries; therefore, the nearest common ancestor CM for a child AP should always be the local SCM.

[0732] A Preregistration Reply does NOT establish a bound Path Instance. An 802.11 Reassociation Response message is, optionally, generated when the parent AP receives the Reply.

[0733] A new parent AP does not need to send a Preregistration Request to obtain an 802.11 station's's dynamic credentials if fast reauthentication with a Network Session Key is not supported or if the station's dynamic credentials are predictively forwarded to the new parent AP. In that case, the station's old AP bindings are returned in a Registration Reply message. Specific Preregistration handshaking is dependent on the 802.11 (re)authentication method.

[0734] The fields in a Proxy Preregistration Request message, generated by a parent AP for a child 802.11 MN, are set as follows:

[0735] WLCCP header fields:

[0736] Type9

[0737] OriginatorNode ID of the Parent AP.

[0738] ResponderNode ID of the SCM.

[0739] Response-Req Flag1 to solicit a Reply.

[0740] Inbound Flag1.

[0741] Root CM Flag1 for an AP; 0 for a MN.

[0742] Hopwise-Routing Flag0.

[0743] TLV FLag1 (The Request must include an EAP_IDENTITY_TLV and an SSID_TLV).

[0744] Preregistration fields:

[0745] RequesterNode ID of the MN.

[0746] Relay Node ID0.

[0747] Proxy Flag1.

[0748] EAP_IDENTITY TLVThe Preregistration Request for a MN or child AP must contain a WTLV_EAP_IDENTITY TLV that contains the node's identifier from an optional 802.11 Reassociation element or from the EAP Identity Response message.

[0749] SSID_TLVThe SSID of the MN taken from the MN's (Re)Association Request message.

[0750] A child AP can, optionally, include a Node_ID element in its (Re)Asssociation Request messages, to communicate its WLCCP Node ID to its parent AP. If a parent AP does not know the Node ID of a child AP, when it generates a Preregistration Message for the child AP, it must set the Requester Node Address to 0. A Preregistration Request should include a WTLV_PORT_ADDRESS_TLV, which contains the MAC port address of the child AP.

[0751] A parent AP generates proxy Registration Request messages for associated MNs. The Originator, Responder, and Requester fields are always set as follows:

[0752] OriginatorNode ID of the Parent AP.

[0753] ResponderNode ID of the SCM.

[0754] Requester802 address of the MN.

[0755] A parent AP must generate a Proxy Registration Request for a MN after it successfully authenticates or reauthenticates (as described below).

[0756] Proxy MN Registration logic is specific to the implementation and is described in more detail below in the sections entitled W1 Proxy MN Registration and W2 Proxy MN Registration.

[0757] SWAN Authentication and Privacy is achieved by enforcing SWAN infrastructure nodes to mutually authenticate with both the root CM (CCM) as well as the IN nodes it will communicate with. Protection of WLCCP messages is achieved by the CCM generating and distributing CTKs upon successful pre-registration of INs.

[0758] Initial authentication is based on the IEEE 802.1X protocol. Each secure MN, AP, and CM must initially mutually authenticate with an 802.1X authenticator, via an external authentication server (e.g. a RADIUS server). Infrastructure nodes (APs, SCMs, and LCMs) mutually authenticate with an IN Authenticator. Secure MNs mutually authenticate with a MN Authenticator. While MNs can select from any supported 802.1X EAP authentication types, for initial releases, IN nodes shall authenticate using LEAP.

[0759] In a campus network, the SWAN CCM contains the IN Authenticator and LCMs contain a MN Authenticator. In a stand-alone local domain, both the IN Authenticator and the MN Authenticator are contained in the LCM. In a stand-alone subnet domain, both the IN Authenticator and the MN Authenticator are contained in the SCM.

[0760] All nodes must authenticate into the SWAN topology prior to registration. The node authenticator will cache the credentials upon successful 802.1X EAP authentication. The IN Authenticator will cache:

Field	Length (bytes)	Description
Reserved	1	Used for byte alignment
State	1	Indicates whether this node is
		Active or not.
Node-ID	8	WLCCP Node Identifier: AP's MAC
		Address (e.g. BSSID)
NSK	16	The key resulting from a successful
		LEAP authentication.
Session	4	Session expiration time provided by the
Timeout		Radius Access Accept
CTK	32	The current context transfer key used to
		protect communications between the
		SCM Authenticator and the Node-ID
Key Sequence	4	A sequence counter used to track
Counter		how many CTK key refreshes have
		occurred
MIC Sequence	8	A sequence counter used to track
Counter		how many messages were authenticated

[0761]

Field	Length(bytes)	Description
Reserved	1	Used for byte alignment
State	1	Indicates whether this node is Active or not
STA Addr	8	WLCCP Node identifier: MN's MAC address
Authentication Type	1	EAP Type used to authenticate
Key Management Type	1	Type of (or no) key management negotiated.
		Valid values are:
		0 - none (NSK is not forwarded)
		1 - CCKM
		2 - 802.1X Legacy systems (doing an effective
		re-authentication) forwards the NSK.
		3 - SSN
Session Timeout	4	Session expiration time provided by the Radius
		Access Accept
KRK	16	Key Request Key used to authenticate MNs
		request for context transfers
BTK	32	Base Transient Key used to derive PTKs
RN	8	Rekey number used to track how many PTKs
		have been derived from BTK
SSID	L	MN's associated SSID TLV
EAP-ID	P	EAP Identity TLV
VLAN ID	2	MN's associated VLAN assignment
BSSID	6	Defines the current associated AP
Cipher	2	Negotiated cipher, values are:
		0x0000 - none
		0x0001 - WEP
		0x0002 - TKIP
		0x0003 - AES-OCB
		0x0004 - AES-CCMP
		0x0005 - CKIP
		0xff<value> - Vendor specific
NSK Length	2	NSK length in bytes
NSK	N	The key resulting from a successful 802.1X
		EAP authentication. This is the MS-MPPE Rx
		Key sent by the AS
Tx Key Length	2	Tx Key Length
Tx Key	M	The key resulting from a successful 802.1X
		EAP authentication. This is the MS-MPPE Tx
		Key sent by the AS