Common Radio Access Protocol Set BOF Bill Gage
Internet Draft Gary Kenward
Document: draft-gage-opinions-00.txt
Category: Informational 14 July 2000
OPINIONS
Open IP Network Infrastructure for Nomadic Services
Status of this Memo
This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet
Drafts. Internet Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document outlines the issues facing nomadic communications in
an IP-based environment. While cellular systems epitomise current
concepts of mobility, there is an industry need to support similar
functions in non-cellular environments as well. Unfortunately,
solutions defined to-date by the cellular industry tend to be
closely tied to the technology employed over the radio link (e.g.
GSM, cdma2000, UMTS, EDGE).
To facilitate discussion, this document begins with a high-level
description of functional entities comprising an Open IP Network
Infrastructure. It then defines an abstract model of the access link
used to connect a mobile host to the network. Using these entities
and model, we then go on to discuss the issues facing nomadic
computing that could be usefully addressed by an IETF working group
like CRAPS.
Gage, Kenward Expires January 2001 [Page 1]
Internet Draft Open IP Network Infrastructure July 2000
for Nomadic Services
1. Introduction
This document establishes a framework for addressing issues related
to nomadic communications -- the ability to send and receive
information from wherever you are currently located -- in an IP-
based environment. While public cellular systems epitomise current
concepts of mobility, there is an industry need to support similar
functions in non-cellular, non-voice environments as well.
The power of the Internet Protocol suite is its independence from
underlying link technologies. Solutions defined using protocols at
and above the IP layer can operate over and across any link
technology -- assuming that inherent characteristics of a link
technology have not been consciously or unconsciously incorporated
into the "IP" solution. Unfortunately, solutions defined to-date by
the cellular industry tend to be closely tied to the technology
employed over the radio link (e.g. GSM, cdma2000, UMTS, EDGE); even
when the radio link technology is similar (e.g. CDMA as the basis
for cdma2000 and UMTS), different standards bodies have chosen
different solutions that attempt to exploit the uniqueness of their
radio link solution.
The goal of OPINIONS is to define a set of protocols that can
achieve similar levels of mobility using IP-based protocols inside
the access network that are independent of the underlying link
technology. Furthermore, OPINIONS should be based, wherever
possible, on existing protocols and frameworks that have significant
support of, and penetration into, the Internet community in order to
speed introduction of mobility support. We recognise, however, that
many IETF protocols have not been developed with mobility in mind.
This document therefore contains an initial list of problem areas
that could be addressed by a (new) IETF working group.
2. Acronyms and Terminology
AAA Authentication, Authorisation, Accounting
AN Access Network
AP Access Port
EU End User
MABG Mobile Access Border Gateway
MH Mobile Host
MNAS Mobile Network Access Server
PMS Policy Management System
Downlink Direction from network to MH
Uplink Direction from MH to network
Flow Sequence of packets identified by {sourceIP, destIP} and
optionally qualified by {sourcePort, destPort, protocol}
Gage, Kenward Expires January 2001 [Page 2]
Internet Draft Open IP Network Infrastructure July 2000
for Nomadic Services
3. Functional Model for IP-based Access Network
To facilitate later discussion of issues, we introduce a functional
model of an IP-based access network. In this document, "access
network" is the autonomous system providing the link that connects
the mobile host (MH) to the rest of the network (Figure 1).
MH <--> [Access Network] <--> [Internet] <--> [Service Provider]
<--> [Content Provider]
Figure 1
In this model, the Service Provider is an entity that "owns" the
subscriber and is generally responsible for subscriber accounts and
customer care. The Service Provider is also responsible (for
providing data) for authenticating the subscriber and for
authorising use of services and resources according to the
conditions of the subscription. An End User (EU) may subscribe to
more than one Service Provider. The Content Provider supplies
information and/or applications for use by the EU; a Service
Provider may also be a Content Provider.
The Access Network (Figure 2) includes a (set of) access link(s)
which connects the MH at one end to an access port (AP) at the other
end. Any Layer 1 and 2 technology can be used over this (set of)
link(s) -- dial-up, DSL, cable, point-to-point radio, Ethernet,
cellular radio, etc. The AP may be a simple pass-through device
(e.g. an Ethernet hub) or a complex subnet in its own right (e.g. a
cable headend with a hybrid fibre-coax distribution network, a
cellular base station controller with a number of subtending base
stations).
MH <-link-> AP <-> MNAS <->[routed cloud]<-> MABG <->[Internet]
|--------- access provider domain -----------|
Figure 2
The Access Port is connected to one Mobile Network Access Server
(MNAS). As defined in [NAS], in the uplink direction the MNAS:
- is the point at which users are authenticated, access policy is
enforced, network services are authorised, network usage is
audited, and resource consumption is tracked.
- is the first place in a network where security measures and
policy may be implemented.
Gage, Kenward Expires January 2001 [Page 3]
Internet Draft Open IP Network Infrastructure July 2000
for Nomadic Services
- is the first place to apply Quality of Service (QoS) policies
to the packets.
Each MNAS can communicate with one or more Mobile Access Border
Gateways (MABG). The MABG:
- advertises to the rest of the Internet reachability for (a
subset of) IP network addresses assigned to the access network.
In a wide area deployment, several MABGs may advertise
reachability to the same (subset of) network addresses.
- filters (discards) packets passing between the access network
and the rest of the Internet according to access policies.
- directs packets in the downlink direction towards the serving
or anchor MNAS, according to interior (mobility) routing
protocols.
In the uplink direction (Figure 3), packets are routed from a MNAS
to a MABG according to routing policies in effect at the MNAS. For
example, using standard routing protocols, each packet will exit the
Access Network via the MABG advertising the shortest/best route to
the packet's destination IP address.
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
|AP| |AP|..|AP| |AP| |AP|..|AP| |AP| |AP|..|AP|
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
| | | | | | | | |
+----------------+ +----------------+ +----------------+
| Mobile Network | | Mobile Network | ... | Mobile Network |
| Access Server | | Access Server | | Access Server |
+----------------+ +----------------+ +----------------+
: \ | / :
: ------------------------------------ :
+-----+ / \ +-----+
| PMS | | Routed Network | | AAA |
+-----+ \ / +-----+
: ------------------------------------ :
: / \ :
+---------------------------+ +---------------------------+
| Mobile Access | ... | Mobile Access |
| Border Gateway | | Border Gateway |
+---------------------------+ +---------------------------+
\ /
------------------------------------
/ \
| Internet |
\ /
------------------------------------
Figure 3
Gage, Kenward Expires January 2001 [Page 4]
Internet Draft Open IP Network Infrastructure July 2000
for Nomadic Services
In the downlink direction, packets enter the Access Network via the
MABG advertising the shortest/best route to the destination MH
address, from the perspective of the source node. The packets must
then be routed from the ingress MABG to the MNAS that is currently
serving (or anchoring) the MH.
Note that a single network element may operate both as a MABG and as
a MNAS.
Following initial access authentication and authorisation, a MH may
freely move from one access link to another, regardless of the MNAS
serving that link. As the MH roams, the redirection of packets to
and from the MH, the enforcement of policies, the execution of
security measures and the maintenance of QoS guarantees is handled
through interaction between the various networks elements (MH, MNAS,
MABG, PMS, etc.) in a manner that is transparent to the EU. In other
words, it should not be necessary for the EU to take explicit action
(such as re-starting a session) to realise seamless mobility across
various access links.
The act of switching between access links often requires support
from Layer 1 and Layer 2 of the access link in order to be seamless.
These actions occur in real-time, as the MH is moving. In a cellular
context, this is often referred to as handover (or handoff). Due to
the close coupling with access link technologies, handover
algorithms and techniques are outside the scope of OPINIONS.
Before, during or after handover -- depending on the access link
technology and on the degree of packet loss or delay that can be
tolerated -- the flow of packets to and from the MH may have to be
adjusted to take into account the change in access link(s) used by
the MH. We refer to this as relocating the MH and redirecting flows.
In general, the real-time requirements of relocation are not as
stringent as those of handover.
Note:
The MNAS may be decomposed even further into a Mobile Network
Control Point (MNCP) and a Mobile Network Anchor Point (MNAP).
At the edge of the access network, the MNCP terminates
signalling to/from the MH while the MNAP terminates bearer
traffic to/from the MH. This separation into distinct
functional entities allows decisions involving transfer of
control (i.e. between MNCPs) to be divorced from decisions
involving transfer of connectivity (i.e. between MNAPs). The
need for separation into MNCP and MNAP is for further study.
Gage, Kenward Expires January 2001 [Page 5]
Internet Draft Open IP Network Infrastructure July 2000
for Nomadic Services
4. Abstract Model of the Access Link and Port
The Access Port supports one or more access links on the set of
interfaces facing the MH and one or more links on another set of
interfaces facing the MNAS (Figure 4).
IP datagrams are carried over the access link(s) between the MH and
the AP; the underlying link technology is beyond the scope of
OPINIONS. IP datagrams are also carried between the MNAS and the AP
over network links where, once again, the underlying link technology
is beyond the scope of OPINIONS. Barring undetected errors
introduced by these links, the IP datagram transmitted by a MH is
the same IP datagram that is received by the MNAS, and vice versa.
In other words, the link technology used to convey the packets over
the access link is transparent to the MNAS, just as the link
technology used over the network link is transparent to the MH.
Mobile Hosts
v v v v v v v v v
| | | Access| | |
| | | Links | | |
| | | | | | | | | | | | | | | | | | | | | | |
+-+---------------+ +-------------+ +-------------+
| | Link-specific | ... | Access Port | ... | Access Port |
|A| Interface | +-------------+ +-------------+
|P|---------------| | |
| | Local IP | | |
| | Interface | | |
+-+---------------+ Network | Links |
| | |
+----------------+ ... | ... +----------------+
| | | | | | |
+-+----------------------------+
|M| Local IP Interface |
|N| |
|A|----------Routing ----------+
|S| |
| | Network IP Interface |
+-+----------------------------+
Figure 4
Note that a single network element may incorporate both MNAS and AP
functions.
Gage, Kenward Expires January 2001 [Page 6]
Internet Draft Open IP Network Infrastructure July 2000
for Nomadic Services
5. Relocation scenarios
If a MH switches from using one (set of) access link(s) connected to
an AP to using a different (set of) access link(s) connected to the
same AP, this switch is transparent to the MNAS. For example, a MH
may transparently move from one Ethernet link to another link
connected to the same Ethernet hub. Similarly, a MH may be handed
over from one (sector of a) cellular base station to another (sector
of a) cellular base station connected to the same base station
controller.
However, if a MH switches between access links connected to
different APs, then the MNAS must be involved to co-ordinate the
redirection of IP flows from one AP to another. Similarly, if the MH
switches between access links connected to different APs that are
connected to different MNASes, then the MNASes (and, perhaps, the
MABGs) must be involved to co-ordinate the redirection of IP flows.
Therefore, the three major relocation scenarios are:
a) MH to access link connected to same AP.
b) MH to access link connected to different AP connected to same
MNAS.
c) MH to access link connected to different AP connected to
different MNASes.
Scenario (a) is handled entirely within the domain of the access
links and does not affect OPINIONS. Scenario (b) requires
interaction between the MNAS and the affected APs and, possibly, a
transfer of link-specific information between APs (via the MNAS).
Scenario (c) requires interaction between the affected MNAS and
between the MNAS and the MABG.
Gage, Kenward Expires January 2001 [Page 7]
Internet Draft Open IP Network Infrastructure July 2000
for Nomadic Services
6. Issues in IP-Based Nomadic Computing
In general, an MNAS must conform to the same framework as that
defined for a non-mobile aware NAS [NAS]. Additional issues
introduced by the nomadic nature of the MHs include:
6.1 Flow Redirection
In an Access Network of 'N' MNAS and 'M' MABG, a MH communicating
through one MNAS may have simultaneous flows that transit more than
one MABG. When the MH moves to the domain of a different MNAS,
downlink packets must be redirected from all MABG (with active flows
for the MH) to the new serving MNAS. In addition, the new serving
MNAS may have routing policies that cause it to forward uplink
packets to a different (set of) MABG than the previous MNAS.
- What is the (mobile-specific) interior routing protocol used to
effect the redirection of downlink flows?
- Are there any special considerations or restrictions for
redirecting uplink flows (e.g. ingress filtering)?
- Is there an anchor point for all flows? If so, where is it?
- How are flows between MHs in the same Access Network routed
(e.g. directly between MNAS or via a MABG)?
6.2 MH Relocation Signalling
As a MH moves from the domain of one AP to the domain of another, an
IP-based message must be used to trigger a reaction inside the
Access Network.
- Who generates this message (e.g. the MH or the AP)?
- Who is this message sent to (e.g. serving MNAS, target MNAS,
anchor signalling control point)?
6.3 Downlink Macro Diversity
Downlink macro diversity refers to the delivery of a given packet to
several APs simultaneously. Such capability can be beneficial even
if macro diversity is not explicitly supported over the access
links.
- How are legs of the downlink diversity tree added and deleted?
- How is delivery of packets to multiple APs synchronised?
- How is the ordering and sequencing of packets to multiple APs
controlled in a lossy network?
6.4 Uplink Macro Diversity
Uplink macro diversity refers to the reception of a given packet
from several APs simultaneously.
Gage, Kenward Expires January 2001 [Page 8]
Internet Draft Open IP Network Infrastructure July 2000
for Nomadic Services
- How are legs of the uplink diversity tree added and deleted?
- How are replicated packets identified?
- How are duplicated packets filtered (discarded)?
6.5 Relocating Quality of Service
A MH may generate traffic requiring something other than best effort
service. Such flows are usually subject to admission control and may
require the reservation of network resources. As the MH moves
between access links:
- How are resource requirements communicated between network
elements?
- How is admission control performed on relocation?
- How is QoS maintained during and after relocation?
- What happens if the required QoS cannot be maintained?
6.6 Accounting
In a fixed network, the NAS is responsible for generating accounting
records at the start and at the end of a "session" and, optionally,
at periodic intervals throughout the "session".
- What is a "session" in the connectionless environment of
OPINIONS?
- What marks the start and end of a "session"?
- Which entity (or entities) generates accounting records and
when?
7. Security Considerations
7.1 (Initial) Authentication and Authorisation
When a MH initially enters or powers on inside an Access Network,
the EU (and maybe the MH device itself) must be authenticated and
authorised for services within the Access Network.
- How are AA packets exchanged if the MH is relocated in the
middle of the AA process (i.e. before a routable IP address is
assigned)?
- How are the results of authentication and authorisation
communicated to other network elements?
7.2 Ongoing Authentication and Authorisation
As the MH roams through the Access Network, security measures are
required to ensure that the entity using an IP address is, in fact,
the same EU (and MH device) that was originally authenticated. In
addition, services authorised for use in one area of an Access
Gage, Kenward Expires January 2001 [Page 9]
Internet Draft Open IP Network Infrastructure July 2000
for Nomadic Services
Network may not be authorised, or may have different operating
parameters, in other areas of the Access Network.
- How is the EU/MH authenticated on an ongoing basis to prevent
hijacking of IP addresses?
- How is use of network resources validated on an ongoing basis
to ensure conformance to policies and to prevent accounting
repudiation?
- What is the architecture and protocols of the (COPS) Policy
Management System to support services in a mobile environment?
- What is the architecture and protocols of the (SIP) Session
Management System to support services in a mobile environment?
7.3 Virtual Private Networks
Virtual Private Networking requires enforcement of routing policies,
service profiles and/or IP address allocation that are dictated by
an entity outside the domain of the Access Network.
- How are the VPN requirements reflected in the architecture and
protocols of the Access Network?
Gage, Kenward Expires January 2001 [Page 10]
Internet Draft Open IP Network Infrastructure July 2000
for Nomadic Services
8. References
[NAS] D. Mitton, M.Beadles "Network Access Server Requirements -
Next Generation (NASREQNG) NAS Model", draft-ietf-nasreq-
nasmodel-02.txt, May 2000.
9. Acknowledgements
This document is the result of many discussions both inside Nortel
and on the CRAPS/OBAST mailing list.
10. Authors' Addresses
Bill Gage
Nortel Networks
3500 Carling Avenue
Nepean ON
Canada K2H 8E9
Phone: 613-763-4400
Email: gageb@nortelnetworks.com
Gary Kenward
Nortel Networks
3500 Carling Avenue
Nepean ON
Canada K2H 8E9
Phone: 613-765-1437
Email: gkenward@nortelnetworks.com
11. Full Copyright Statement
Copyright (C) The Internet Society (July 2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organisations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into.
Gage, Kenward Expires January 2001 [Page 11]