idnits 2.17.1 draft-gage-opinions-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 491 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (14 July 2000) is 8659 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Internet' is mentioned on line 104, but not defined Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Common Radio Access Protocol Set BOF Bill Gage 2 Internet Draft Gary Kenward 3 Document: draft-gage-opinions-00.txt 4 Category: Informational 14 July 2000 6 OPINIONS 7 Open IP Network Infrastructure for Nomadic Services 9 Status of this Memo 11 This document is an Internet Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet 17 Drafts. Internet Drafts are draft documents valid for a maximum of 18 six months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Abstract 29 This document outlines the issues facing nomadic communications in 30 an IP-based environment. While cellular systems epitomise current 31 concepts of mobility, there is an industry need to support similar 32 functions in non-cellular environments as well. Unfortunately, 33 solutions defined to-date by the cellular industry tend to be 34 closely tied to the technology employed over the radio link (e.g. 35 GSM, cdma2000, UMTS, EDGE). 37 To facilitate discussion, this document begins with a high-level 38 description of functional entities comprising an Open IP Network 39 Infrastructure. It then defines an abstract model of the access link 40 used to connect a mobile host to the network. Using these entities 41 and model, we then go on to discuss the issues facing nomadic 42 computing that could be usefully addressed by an IETF working group 43 like CRAPS. 45 for Nomadic Services 47 1. Introduction 49 This document establishes a framework for addressing issues related 50 to nomadic communications -- the ability to send and receive 51 information from wherever you are currently located -- in an IP- 52 based environment. While public cellular systems epitomise current 53 concepts of mobility, there is an industry need to support similar 54 functions in non-cellular, non-voice environments as well. 56 The power of the Internet Protocol suite is its independence from 57 underlying link technologies. Solutions defined using protocols at 58 and above the IP layer can operate over and across any link 59 technology -- assuming that inherent characteristics of a link 60 technology have not been consciously or unconsciously incorporated 61 into the "IP" solution. Unfortunately, solutions defined to-date by 62 the cellular industry tend to be closely tied to the technology 63 employed over the radio link (e.g. GSM, cdma2000, UMTS, EDGE); even 64 when the radio link technology is similar (e.g. CDMA as the basis 65 for cdma2000 and UMTS), different standards bodies have chosen 66 different solutions that attempt to exploit the uniqueness of their 67 radio link solution. 69 The goal of OPINIONS is to define a set of protocols that can 70 achieve similar levels of mobility using IP-based protocols inside 71 the access network that are independent of the underlying link 72 technology. Furthermore, OPINIONS should be based, wherever 73 possible, on existing protocols and frameworks that have significant 74 support of, and penetration into, the Internet community in order to 75 speed introduction of mobility support. We recognise, however, that 76 many IETF protocols have not been developed with mobility in mind. 77 This document therefore contains an initial list of problem areas 78 that could be addressed by a (new) IETF working group. 80 2. Acronyms and Terminology 82 AAA Authentication, Authorisation, Accounting 83 AN Access Network 84 AP Access Port 85 EU End User 86 MABG Mobile Access Border Gateway 87 MH Mobile Host 88 MNAS Mobile Network Access Server 89 PMS Policy Management System 91 Downlink Direction from network to MH 92 Uplink Direction from MH to network 93 Flow Sequence of packets identified by {sourceIP, destIP} and 94 optionally qualified by {sourcePort, destPort, protocol} 95 for Nomadic Services 97 3. Functional Model for IP-based Access Network 99 To facilitate later discussion of issues, we introduce a functional 100 model of an IP-based access network. In this document, "access 101 network" is the autonomous system providing the link that connects 102 the mobile host (MH) to the rest of the network (Figure 1). 104 MH <--> [Access Network] <--> [Internet] <--> [Service Provider] 105 <--> [Content Provider] 107 Figure 1 109 In this model, the Service Provider is an entity that "owns" the 110 subscriber and is generally responsible for subscriber accounts and 111 customer care. The Service Provider is also responsible (for 112 providing data) for authenticating the subscriber and for 113 authorising use of services and resources according to the 114 conditions of the subscription. An End User (EU) may subscribe to 115 more than one Service Provider. The Content Provider supplies 116 information and/or applications for use by the EU; a Service 117 Provider may also be a Content Provider. 119 The Access Network (Figure 2) includes a (set of) access link(s) 120 which connects the MH at one end to an access port (AP) at the other 121 end. Any Layer 1 and 2 technology can be used over this (set of) 122 link(s) -- dial-up, DSL, cable, point-to-point radio, Ethernet, 123 cellular radio, etc. The AP may be a simple pass-through device 124 (e.g. an Ethernet hub) or a complex subnet in its own right (e.g. a 125 cable headend with a hybrid fibre-coax distribution network, a 126 cellular base station controller with a number of subtending base 127 stations). 129 MH <-link-> AP <-> MNAS <->[routed cloud]<-> MABG <->[Internet] 131 |--------- access provider domain -----------| 133 Figure 2 135 The Access Port is connected to one Mobile Network Access Server 136 (MNAS). As defined in [NAS], in the uplink direction the MNAS: 138 - is the point at which users are authenticated, access policy is 139 enforced, network services are authorised, network usage is 140 audited, and resource consumption is tracked. 142 - is the first place in a network where security measures and 143 policy may be implemented. 145 for Nomadic Services 147 - is the first place to apply Quality of Service (QoS) policies 148 to the packets. 150 Each MNAS can communicate with one or more Mobile Access Border 151 Gateways (MABG). The MABG: 153 - advertises to the rest of the Internet reachability for (a 154 subset of) IP network addresses assigned to the access network. 155 In a wide area deployment, several MABGs may advertise 156 reachability to the same (subset of) network addresses. 158 - filters (discards) packets passing between the access network 159 and the rest of the Internet according to access policies. 161 - directs packets in the downlink direction towards the serving 162 or anchor MNAS, according to interior (mobility) routing 163 protocols. 165 In the uplink direction (Figure 3), packets are routed from a MNAS 166 to a MABG according to routing policies in effect at the MNAS. For 167 example, using standard routing protocols, each packet will exit the 168 Access Network via the MABG advertising the shortest/best route to 169 the packet's destination IP address. 171 +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ 172 |AP| |AP|..|AP| |AP| |AP|..|AP| |AP| |AP|..|AP| 173 +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ 174 | | | | | | | | | 175 +----------------+ +----------------+ +----------------+ 176 | Mobile Network | | Mobile Network | ... | Mobile Network | 177 | Access Server | | Access Server | | Access Server | 178 +----------------+ +----------------+ +----------------+ 179 : \ | / : 180 : ------------------------------------ : 181 +-----+ / \ +-----+ 182 | PMS | | Routed Network | | AAA | 183 +-----+ \ / +-----+ 184 : ------------------------------------ : 185 : / \ : 186 +---------------------------+ +---------------------------+ 187 | Mobile Access | ... | Mobile Access | 188 | Border Gateway | | Border Gateway | 189 +---------------------------+ +---------------------------+ 190 \ / 191 ------------------------------------ 192 / \ 193 | Internet | 194 \ / 195 ------------------------------------ 197 Figure 3 199 for Nomadic Services 201 In the downlink direction, packets enter the Access Network via the 202 MABG advertising the shortest/best route to the destination MH 203 address, from the perspective of the source node. The packets must 204 then be routed from the ingress MABG to the MNAS that is currently 205 serving (or anchoring) the MH. 207 Note that a single network element may operate both as a MABG and as 208 a MNAS. 210 Following initial access authentication and authorisation, a MH may 211 freely move from one access link to another, regardless of the MNAS 212 serving that link. As the MH roams, the redirection of packets to 213 and from the MH, the enforcement of policies, the execution of 214 security measures and the maintenance of QoS guarantees is handled 215 through interaction between the various networks elements (MH, MNAS, 216 MABG, PMS, etc.) in a manner that is transparent to the EU. In other 217 words, it should not be necessary for the EU to take explicit action 218 (such as re-starting a session) to realise seamless mobility across 219 various access links. 221 The act of switching between access links often requires support 222 from Layer 1 and Layer 2 of the access link in order to be seamless. 223 These actions occur in real-time, as the MH is moving. In a cellular 224 context, this is often referred to as handover (or handoff). Due to 225 the close coupling with access link technologies, handover 226 algorithms and techniques are outside the scope of OPINIONS. 228 Before, during or after handover -- depending on the access link 229 technology and on the degree of packet loss or delay that can be 230 tolerated -- the flow of packets to and from the MH may have to be 231 adjusted to take into account the change in access link(s) used by 232 the MH. We refer to this as relocating the MH and redirecting flows. 233 In general, the real-time requirements of relocation are not as 234 stringent as those of handover. 236 Note: 237 The MNAS may be decomposed even further into a Mobile Network 238 Control Point (MNCP) and a Mobile Network Anchor Point (MNAP). 239 At the edge of the access network, the MNCP terminates 240 signalling to/from the MH while the MNAP terminates bearer 241 traffic to/from the MH. This separation into distinct 242 functional entities allows decisions involving transfer of 243 control (i.e. between MNCPs) to be divorced from decisions 244 involving transfer of connectivity (i.e. between MNAPs). The 245 need for separation into MNCP and MNAP is for further study. 247 for Nomadic Services 249 4. Abstract Model of the Access Link and Port 251 The Access Port supports one or more access links on the set of 252 interfaces facing the MH and one or more links on another set of 253 interfaces facing the MNAS (Figure 4). 255 IP datagrams are carried over the access link(s) between the MH and 256 the AP; the underlying link technology is beyond the scope of 257 OPINIONS. IP datagrams are also carried between the MNAS and the AP 258 over network links where, once again, the underlying link technology 259 is beyond the scope of OPINIONS. Barring undetected errors 260 introduced by these links, the IP datagram transmitted by a MH is 261 the same IP datagram that is received by the MNAS, and vice versa. 262 In other words, the link technology used to convey the packets over 263 the access link is transparent to the MNAS, just as the link 264 technology used over the network link is transparent to the MH. 266 Mobile Hosts 267 v v v v v v v v v 268 | | | Access| | | 269 | | | Links | | | 270 | | | | | | | | | | | | | | | | | | | | | | | 271 +-+---------------+ +-------------+ +-------------+ 272 | | Link-specific | ... | Access Port | ... | Access Port | 273 |A| Interface | +-------------+ +-------------+ 274 |P|---------------| | | 275 | | Local IP | | | 276 | | Interface | | | 277 +-+---------------+ Network | Links | 278 | | | 279 +----------------+ ... | ... +----------------+ 280 | | | | | | | 281 +-+----------------------------+ 282 |M| Local IP Interface | 283 |N| | 284 |A|----------Routing ----------+ 285 |S| | 286 | | Network IP Interface | 287 +-+----------------------------+ 289 Figure 4 291 Note that a single network element may incorporate both MNAS and AP 292 functions. 294 for Nomadic Services 296 5. Relocation scenarios 298 If a MH switches from using one (set of) access link(s) connected to 299 an AP to using a different (set of) access link(s) connected to the 300 same AP, this switch is transparent to the MNAS. For example, a MH 301 may transparently move from one Ethernet link to another link 302 connected to the same Ethernet hub. Similarly, a MH may be handed 303 over from one (sector of a) cellular base station to another (sector 304 of a) cellular base station connected to the same base station 305 controller. 307 However, if a MH switches between access links connected to 308 different APs, then the MNAS must be involved to co-ordinate the 309 redirection of IP flows from one AP to another. Similarly, if the MH 310 switches between access links connected to different APs that are 311 connected to different MNASes, then the MNASes (and, perhaps, the 312 MABGs) must be involved to co-ordinate the redirection of IP flows. 314 Therefore, the three major relocation scenarios are: 316 a) MH to access link connected to same AP. 318 b) MH to access link connected to different AP connected to same 319 MNAS. 321 c) MH to access link connected to different AP connected to 322 different MNASes. 324 Scenario (a) is handled entirely within the domain of the access 325 links and does not affect OPINIONS. Scenario (b) requires 326 interaction between the MNAS and the affected APs and, possibly, a 327 transfer of link-specific information between APs (via the MNAS). 328 Scenario (c) requires interaction between the affected MNAS and 329 between the MNAS and the MABG. 331 for Nomadic Services 333 6. Issues in IP-Based Nomadic Computing 335 In general, an MNAS must conform to the same framework as that 336 defined for a non-mobile aware NAS [NAS]. Additional issues 337 introduced by the nomadic nature of the MHs include: 339 6.1 Flow Redirection 341 In an Access Network of 'N' MNAS and 'M' MABG, a MH communicating 342 through one MNAS may have simultaneous flows that transit more than 343 one MABG. When the MH moves to the domain of a different MNAS, 344 downlink packets must be redirected from all MABG (with active flows 345 for the MH) to the new serving MNAS. In addition, the new serving 346 MNAS may have routing policies that cause it to forward uplink 347 packets to a different (set of) MABG than the previous MNAS. 349 - What is the (mobile-specific) interior routing protocol used to 350 effect the redirection of downlink flows? 351 - Are there any special considerations or restrictions for 352 redirecting uplink flows (e.g. ingress filtering)? 353 - Is there an anchor point for all flows? If so, where is it? 354 - How are flows between MHs in the same Access Network routed 355 (e.g. directly between MNAS or via a MABG)? 357 6.2 MH Relocation Signalling 359 As a MH moves from the domain of one AP to the domain of another, an 360 IP-based message must be used to trigger a reaction inside the 361 Access Network. 363 - Who generates this message (e.g. the MH or the AP)? 364 - Who is this message sent to (e.g. serving MNAS, target MNAS, 365 anchor signalling control point)? 367 6.3 Downlink Macro Diversity 369 Downlink macro diversity refers to the delivery of a given packet to 370 several APs simultaneously. Such capability can be beneficial even 371 if macro diversity is not explicitly supported over the access 372 links. 374 - How are legs of the downlink diversity tree added and deleted? 375 - How is delivery of packets to multiple APs synchronised? 376 - How is the ordering and sequencing of packets to multiple APs 377 controlled in a lossy network? 379 6.4 Uplink Macro Diversity 381 Uplink macro diversity refers to the reception of a given packet 382 from several APs simultaneously. 384 for Nomadic Services 386 - How are legs of the uplink diversity tree added and deleted? 387 - How are replicated packets identified? 388 - How are duplicated packets filtered (discarded)? 390 6.5 Relocating Quality of Service 392 A MH may generate traffic requiring something other than best effort 393 service. Such flows are usually subject to admission control and may 394 require the reservation of network resources. As the MH moves 395 between access links: 397 - How are resource requirements communicated between network 398 elements? 399 - How is admission control performed on relocation? 400 - How is QoS maintained during and after relocation? 401 - What happens if the required QoS cannot be maintained? 403 6.6 Accounting 405 In a fixed network, the NAS is responsible for generating accounting 406 records at the start and at the end of a "session" and, optionally, 407 at periodic intervals throughout the "session". 409 - What is a "session" in the connectionless environment of 410 OPINIONS? 411 - What marks the start and end of a "session"? 412 - Which entity (or entities) generates accounting records and 413 when? 415 7. Security Considerations 417 7.1 (Initial) Authentication and Authorisation 419 When a MH initially enters or powers on inside an Access Network, 420 the EU (and maybe the MH device itself) must be authenticated and 421 authorised for services within the Access Network. 423 - How are AA packets exchanged if the MH is relocated in the 424 middle of the AA process (i.e. before a routable IP address is 425 assigned)? 426 - How are the results of authentication and authorisation 427 communicated to other network elements? 429 7.2 Ongoing Authentication and Authorisation 431 As the MH roams through the Access Network, security measures are 432 required to ensure that the entity using an IP address is, in fact, 433 the same EU (and MH device) that was originally authenticated. In 434 addition, services authorised for use in one area of an Access 435 for Nomadic Services 437 Network may not be authorised, or may have different operating 438 parameters, in other areas of the Access Network. 440 - How is the EU/MH authenticated on an ongoing basis to prevent 441 hijacking of IP addresses? 442 - How is use of network resources validated on an ongoing basis 443 to ensure conformance to policies and to prevent accounting 444 repudiation? 445 - What is the architecture and protocols of the (COPS) Policy 446 Management System to support services in a mobile environment? 447 - What is the architecture and protocols of the (SIP) Session 448 Management System to support services in a mobile environment? 450 7.3 Virtual Private Networks 452 Virtual Private Networking requires enforcement of routing policies, 453 service profiles and/or IP address allocation that are dictated by 454 an entity outside the domain of the Access Network. 456 - How are the VPN requirements reflected in the architecture and 457 protocols of the Access Network? 458 for Nomadic Services 460 8. References 462 [NAS] D. Mitton, M.Beadles "Network Access Server Requirements - 463 Next Generation (NASREQNG) NAS Model", draft-ietf-nasreq- 464 nasmodel-02.txt, May 2000. 466 9. Acknowledgements 468 This document is the result of many discussions both inside Nortel 469 and on the CRAPS/OBAST mailing list. 471 10. Authors' Addresses 473 Bill Gage 474 Nortel Networks 475 3500 Carling Avenue 476 Nepean ON 477 Canada K2H 8E9 478 Phone: 613-763-4400 479 Email: gageb@nortelnetworks.com 481 Gary Kenward 482 Nortel Networks 483 3500 Carling Avenue 484 Nepean ON 485 Canada K2H 8E9 486 Phone: 613-765-1437 487 Email: gkenward@nortelnetworks.com 489 11. Full Copyright Statement 491 Copyright (C) The Internet Society (July 2000). All Rights Reserved. 492 This document and translations of it may be copied and furnished to 493 others, and derivative works that comment on or otherwise explain it 494 or assist in its implementation may be prepared, copied, published 495 and distributed, in whole or in part, without restriction of any 496 kind, provided that the above copyright notice and this paragraph 497 are included on all such copies and derivative works. However, this 498 document itself may not be modified in any way, such as by removing 499 the copyright notice or references to the Internet Society or other 500 Internet organisations, except as needed for the purpose of 501 developing Internet standards in which case the procedures for 502 copyrights defined in the Internet Standards process must be 503 followed, or as required to translate it into.