The
switch delivers more
services at access layer other than merely providing increased speeds and
feeds. Wireless services is now integrated with the switch, which ensures that
the access layer switch terminates the wireless users data plane, thereby
delivering on the promise of Cisco's unified architecture. Unification implies
that mobility services are provided to both wireless and wired stations.
The
switch provides
seamless roaming, which requires transparency of the network configuration and
deployment options to the client.
From the end user's
perspective, any mobility event must not change its IP address, its default
router or DHCP server. This means that as stations roam, they must be able to
Send an ARP to
their default router, or
Transmit a DHCP
request to the server that had previously assigned their address.
From the
infrastructure's perspective, as mobility events occur, the station's traffic
must follow its current point of attachment, which can either be a mobility
agent (MA) or mobility controller (MC). This must be true regardless of whether
the station has moved to a network that is configured for a different subnet.
The period from which the station is not receiving traffic following its
mobility event must be as short as possible, even below 40 ms whenever
possible, which includes any authentication procedures that are required.
From the
infrastructure's perspective, the mobility management solution must have four
main components, and all of these functions must be performed within the
constraints of roaming:
Initial
Association—This function is used to identify the user's new point of
attachment in the network.
Context
Transfer—This function is used to transfer state information associated with
the station. This ensures that the station's static and real-time policies,
including security and application ACLs, and services, remain the same across
handoffs.
Handoff—This
function is used to signal that the station's point of attachment has changed,
and control of the station should be relinquished by the previous access
switch.
Data Plane—This
function is typically tied to the handoff process, and ensures that the
station's traffic continues to be delivered and received from the station
without any noticeable performance degradation.
Wired and Wireless Mobility
One of the key features of the Converged access solution (applicable to both the Cisco Catalyst 3850 Switch and Cisco WLC 5700 Series Controller) is its ability to provide a device with an IP
address and maintain its session persistence, across mobility
events from ethernet connections to wireless and vice-versa. This
feature allows users to remain on an ethernet network when
possible, and make use of the freedom of mobility associated with
wireless when necessary.
This feature leverages support from both the
client and the infrastructure and uses the two factor
authentication-device and user. The device authentication
credentials is cached in the mobility controller (MC). When a device
transitions across link layers, the device credentials is
validated, and if a match is found, the MC ensures
that the same IP address is assigned to the new
interface.
Features of
Mobility
Mobility
Controller (MC)—The controller provides mobility management services for
inter-peer group roaming events. The MC provides a central point of contact for
management and policy based control protocols, such as RADIUS. This eliminates
the need for the infrastructure servers to maintain a user's location as it
transitions throughout the network. The MC sends the configuration to all the
mobility agents under its sub-domain of their mobility configuration, peer
group membership and list of members. A sub-domain is synonymous to the MC that
forms it. Each sub-domain consists of an MC and zero or more access switches
that have AP's associated to them.
Mobility Agents
(MA)— A mobility agent is either an access switch that has a wireless module
running on it or an MC with an internal MA running on it. A mobility agent is
the wireless component that maintains client mobility state machine for a
mobile client that is connected via an AP to the device that the MA is running
on.
Mobility Sub
Domain— It is an autonomous portion of the mobility domain network. A mobility
sub-domain comprises of a single mobility controller and its associated
mobility agents (MAs).
Note
Even when
more than one mobility controller is present, only one MC can be active at any
given time.
A mobility sub-domain is the set of devices managed by the
active mobility controller. A mobility sub-domain comprises of a set of
mobility agents and associated access points.
Mobility Group— A
collection of mobility controllers (MCs) across which fast roaming is
supported. The concept of mobility group is the same as a collection of
buildings in a campus across which frequent roaming is expected.
Mobility Domain— A
collection of mobility sub-domains across which mobility is supported. The term
mobility domain may be the same as a campus network.
Mobility Oracle
(MO)—The mobility oracle acts as the point of contact for mobility events that
occur across mobility sub-domains. It also maintains a local database of each
station in the entire mobility domain, their home and current sub-domain. A
mobility domain includes one or more mobility oracle, though only one would be
active at any given time.
Mobility Tunnel
Endpoint (MTE)— The mobility tunnel endpoint (MTE) provides data plane services
for mobile devices through the use of tunneling. This minimizes the impact of
roaming events on the network by keeping the user's point of presence on the
network a constant.
Point of
Attachment— A station's point of attachment is where its data path is initially
processed upon entry in the network. This could either be the access switch
that is currently providing it service, or the wireless LAN controller.
Point of Presence—
A station's point of presence is the place in the network where the station is
being advertised. For instance, if an access switch is advertising reachability
to the station via a routing protocol, the interface on which the route is
being advertised is considered the station's point of presence.
Switch Peer Group
(SPG)— A peer group is a statically created list of neighboring access switches
between which fast mobility services is provided. A peer group limits the scope
of interactions between switches during handoffs to only those that are
geographically proximate.
Station—A user's
device that connects to and requests service from the network. The device may
have a wired, wireless or both interfaces.
Switch in the same
SPG—A peer switch that is part of the peer group of the local switch.
Switch outside
the SPG—A peer access switch that is not part of the local switch's peer group.
Foreign Mobility
Controller— The mobility controller providing mobility management service for
the station in a foreign mobility sub-domain. The foreign mobility controller
acts as a liaison between access switches in the foreign sub-domain and the
mobility controller in the home domain.
Foreign Mobility
Sub-Domain— The mobility sub-domain, controlled by a mobility controller,
supporting a station which is anchored in another mobility sub-domain
Foreign Switch—
The access switch in the foreign mobility sub-domain currently providing
service to the station.
Anchor Mobility
Controller— The mobility controller providing a single point of control and
mobility management service for stations in their home mobility sub-domain.
Anchor Mobility
Sub-Domain— The mobility sub-domain, controlled by a mobility controller, for a
station where its IP address was assigned.
Anchor Switch—
The switch in the home mobility sub-domain that last provided service to a
station.
Sticky Anchoring for Low Latency Roaming
Sticky Anchoring ensures low roaming latency from the client's point of presence is maintained at the switch where the client initially joins the network. It is expensive to apply client policies at a switch for a roaming client. There can be considerable delay as it involves contacting the AAA server for downloadable ACLs which is not acceptable for restoring time sensitive client traffic.
To manage this delay, when the client roams between APs connected to different switches , irrespective of whether it is an intra sub-domain roam or inter sub-domain roam, the client traffic is always tunneled to the switch where the client first associates. The client is anchored at its first point of attachment for its lifetime in the network.
This behavior is enabled by default. You can also disable this behavior to allow the client anchoring only for inter-subnet roams. This configuration is per WLAN config and is available under the WLAN config mode. The customer can configure different SSIDs for time sensitive and non time sensitive applications.
Bridge Domain ID and L2/L3 Roaming
Bridge domain ID provides the mobility nodes with information to decide on specific roam type, either as L2 or L3 roam. It also allows the network administrators to reuse the VLAN IDs across network distribution. When the VLAN IDs do not have the associated subnet configurations, they may require additional parameter to use in conjunction with VLAN ID. The network administrator ensures that the given VLAN under the same bridge domain ID are associated with the unique subnet. The mobility nodes will first check for the bridge domain ID for the given node and the VLAN ID associated with the client to identify the roam type. The bridge domain ID and the VLAN ID must be same to treat a roam as L2 roam.
The bridge domain ID is configured for each SPG when creating a SPG and later on the MC. The bridge domain ID could be same for more than one SPG and all the MAs under the SPG will share the same bridge domain ID. This information is pushed to the MAs as part of the configuration download when MA comes up initially. If the bridge domain ID is modified when the system is up, it will be pushed to all the MAs in the modified SPG and will take immediate effect for the future roams.
Note
The MC can also have a bridge domain ID for it self, as the MC can also be part of a SPG.
Link Down
Behavior
This section provides
information about data synchronization between MA-MC and MC-MO when MC or MO
faces downtime in absence of redundancy manager. When Keepalive is configured
between MA-MC or MC-MO the clients database is synchronized between the MO and
the MCs and the MC and its MAs respectively.
Platform Specific
Scale Requirement for the Mobility Controller
The Mobility
Controller (MC) role is supported on a number of different platforms like, the
Cisco WLC 5700 Series, CUWN and Catalyst 3850 Switches. The scale requirements
on these three platforms are summarized in the table below: