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]