idnits 2.17.00 (12 Aug 2021) /tmp/idnits20729/draft-cordeiro-nsis-mih-nslp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 967. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 978. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 985. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 991. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-cordeiro-nsis-mih-nslp', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-cordeiro-nsis-mih-nslp', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-cordeiro-nsis-mih-nslp', but the file name used is 'draft-cordeiro-nsis-mih-nslp-00' == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (February 18, 2008) is 5205 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-mipshop-mstp-solution has been published as RFC 5677 ** Downref: Normative reference to an Informational RFC: RFC 4080 (ref. '3') == Outdated reference: draft-ietf-nsis-ntlp has been published as RFC 5971 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. '4') == Outdated reference: draft-ietf-nsis-qos-nslp has been published as RFC 5974 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-qos-nslp (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Downref: Normative reference to an Informational RFC: RFC 4081 (ref. '7') Summary: 7 errors (**), 1 flaw (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS Working Group L. Cordeiro 3 Internet-Draft M. Curado 4 Expires: August 21, 2008 Univ. Coimbra 5 P. Neves 6 PTIn 7 S. Sargento 8 Univ. Aveiro 9 G. Landi 10 CPR 11 X. Fu 12 Univ. Goettingen 13 February 18, 2008 15 Media Independent Handover Network Signalling Layer Protocol (MIH NSLP) 16 draft-cordeiro-nsis-mih-nslp 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on August 21, 2008. 43 Copyright Notice 45 Copyright (C) The IETF Trust (2008). 47 Abstract 49 This memo defines the Media Independent Handover Network Signalling 50 Layer Protocol (MIH NSLP) for the transport of messages from the IEEE 51 802.21 standard using the Next Steps in Signalling (NSIS) framework. 52 The MIH NSLP is responsible for the transport of MIH messages to 53 remote entities reporting on link layer information, in order to 54 support seamless mobility in heterogeneous environments. A usage 55 example of the MIH NSLP is also provided. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 61 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Media Independent Handover NSLP Specification . . . . . . . . 7 63 4.1. MIH NSLP Architecture . . . . . . . . . . . . . . . . . . 8 64 4.2. MIH Message Transport . . . . . . . . . . . . . . . . . . 9 65 4.3. Mapping between MIHF ID and Network Addresses . . . . . . 11 66 5. Mobility Scenario Example . . . . . . . . . . . . . . . . . . 14 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 68 7. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 19 69 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 70 9. Normative References . . . . . . . . . . . . . . . . . . . . . 20 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 72 Intellectual Property and Copyright Statements . . . . . . . . . . 23 74 1. Introduction 76 In order to improve the handover between heterogeneous access 77 networks, the IEEE 802.21 standard is being defined to provide Media 78 Independent Handover services (MIH). IEEE 802.21/MIH makes available 79 link layer information to the upper network layers, both locally and 80 remotely. Although the standard defines the guidelines to transport 81 the MIH protocol messages to remote entities, namely the need to be 82 reliable and to guarantee security of the messages exchanged, it does 83 not specify a transport mechanism. [1] describes a possible design 84 for the MIH transport mechanism; however it requires a multitude of 85 new protocol elements and is also limited in several technical 86 constraints such as message size and protocol discovery. 88 The IETF NSIS WG is finalizing the base protocols to offer flexible 89 and extensible signalling services for a variety of application, 90 including the General Internet Signaling Transport (GIST) for support 91 secure, reliable, congestion-controlled data transport, as well as 92 other features desired for signalling. Given the potential of NSIS 93 to perform Quality of Service (QoS) signalling for real-time 94 applications in wired and wireless scenarios, which is also often 95 desired by the applications using MIH, we propose to use GIST to 96 transport MIH messages. Therefore, this document defines a Media 97 Independent Handover NSIS Signalling Layer Protocol (MIH NSLP) to 98 support seamless mobility in heterogeneous network environments 99 through the integration of MIH and NSIS. 101 This document is structured as follows. Section 3 presents the 102 motivation for the development of a MIH NSLP. Section 4 details the 103 MIH NSLP and Section 5 shows an example of the use of the MIH NSLP in 104 a mobility scenario. 106 2. Terminology and Abbreviations 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [2]. 112 The following additional terms are used: 114 o E2E: End-to-End 116 o QoS: Quality of Service 118 o MIH: Media Independent Handover 119 o MIH NSLP: Media Independent Handover NSIS Signaling Layer 120 Protocol, uses NSIS as the transport protocol for MIH messages. 122 o NSIS: Next Steps in Signaling 124 o GIST: General Internet Signaling Transport 126 o WLAN: Wireless Local Area Networks 128 o WiMAX: Worldwide Interoperability for Microwave Access 130 o UMTS: Universal Mobile Telephone Service 132 o MBMS: Multicast and Broadcast Multimedia Services 134 o DVB: Digital Video Broadcast 136 o SAP: Service Access Point 138 o MICS: Media Independent Command Services 140 o MIES: Media Independent Event Services 142 o MIIS: Media Independent Information Services 144 o MIHF: Media Independent Handover Function 146 o MIHU: Media Independent Handover User 148 o ASN: WiMAX Access Service Network 150 o AN: Access Network 152 o CSN: WiMAX Connectivity Service Network 154 o CN: Core Network 156 o MS: Mobile Station 158 o TCP: Transmission Control Protocol 160 o UDP: User Datagram Protocol 162 o BS: WiMAX Base Station 164 o SS: WiMAX Subscriber Station 165 o AP: WiFi Access Point 167 o SF: WiMAX Service Flow 169 o HA: MIP Home Agent 171 o CoA: MIP Care of Address 173 o AAA: Authentication, Authorization and Accounting 175 o ASN-GW: WiMAX Access Service Network Gateway 177 o MIH Registration Server: responsible to handle the MIHF ID into 178 network address mapping. 180 3. Problem Statement 182 With the current evolution of network technologies we envision that, 183 in a near future, there will be a heterogeneous landscape of 184 different technologies such as WLAN, WiMAX, UMTS/MBMS and DVB, 185 providing ubiquitous network access to users. The wide availability 186 of co-located technologies and the growing trend of users' mobility, 187 require the seamless support of mobility and service continuity. 188 Nevertheless, due to the large number of new access technologies, it 189 is very difficult to provide seamless mobility across these 190 technologies. 192 In order to optimize the handover process, the IEEE is currently 193 defining the 802.21 standard, focused on Media Independent Handover 194 services (MIH). The main goal of the IEEE 802.21 standard is to 195 provide link layer information to the upper layers, optimizing the 196 handover process between heterogeneous access networks. The Media 197 Independent Handover Function (MIHF) is the core component of the 198 802.21 standard. It provides a set of well defined and standardized 199 Service Access Points (SAP) with both the link layer (MIH_LINK_SAP) 200 and the upper layers (MIH_SAP) that will use this information (MIH 201 users). A set of services is provided through these interfaces in 202 order to facilitate the communication process: 204 o Media Independent Command Service (MICS): allows higher layers to 205 configure, control and get information from the lower layer. 207 o Media Independent Event Service (MIES): allows higher layers to 208 receive indications from link layers. 210 o Media Independent Information Service (MIIS): provides a framework 211 and corresponding mechanisms by which a MIHF entity obtains static 212 network information. 214 Events and commands can be local and/or remote. Local events are 215 generated from the link layer and propagated towards the MIH users 216 within the local device. Remote events are propagated towards a MIH 217 user connected to a peer MIHF. 219 Several network elements might be interested to receive notifications 220 from the lower layers, and therefore the MIH protocol has been 221 defined to propagate the MIH services towards the peer MIHFs. 223 Figure 1 illustrates the distribution of the MIHF entities across the 224 network components. 226 <-------- Domain X ---------> <--------- Domain Y --------> 227 +------+ +------+ +------+ +------+ 228 | MS |<-->| AN1 |\ /| AN1 |<-->| MS | 229 | MIHF | | MIHF | \ / | MIHF | | MIHF | 230 +------+ +------+ \ / +------+ +------+ 231 . +------+ +-----+| . 232 . | CN |<---->| CN | . 233 . | MIHF | | MIHF | . 234 . +------+ +------+ . 235 +------+ +------+ / \ +------+ +------+ 236 | MS |<-->| ANn | / \ | ANn |<-->| MS | 237 | MIHF | | MIHF |/ \| MIHF | | MIHF | 238 +------+ +------+ +------+ +------+ 240 Figure 1: MIHF Communication Model 242 The MIHFs might be spread in several network elements inside the same 243 domain, or even across different domains. In Figure 1 we illustrate 244 two different domains (domain X and domain Y). Each domain is 245 composed by the Core Network (CN), responsible for the overall 246 management and control of the network, connected to several Access 247 Networks (AN). Each AN provides connectivity to the Mobile Stations 248 (MS), using wired/wireless access technologies (e.g. WiMAX, DVB, 249 WiFi, UMTS). As depicted in Figure 1, each one of these entities - 250 CN, AN and MS - is a potential candidate to host the MIHF entity. 251 Therefore, MIH messages SHALL be able to reach all the MIHFs in the 252 network, independently of their location. 254 However, no specific transport mechanism is defined to carry the MIH 255 protocol messages between remote MIHFs. Only the guidelines to 256 transmit the MIH messages across the network are defined in the MIH 257 standard. The transport protocol used MUST be reliable, guaranteeing 258 the correct delivery of the messages to the peer MIHF, and provide 259 security over the exchanged messages. 261 The Transmission Control Protocol (TCP) is able to satisfy the 262 reliability requirement posed by the MIH protocol. It provides error 263 control and flow control, guaranteeing the in-order delivery of the 264 packets. However, although TCP offers reliability, it does not 265 guarantee fast-packet delivery due to its retransmission mechanism. 266 In what concerns the User Datagram Protocol (UDP), it assures fast- 267 packet delivery, but it does not guarantee the correct packet 268 delivery, and therefore is unreliable. 270 As a result, a reliable, secure and fast-delivery solution to 271 transport MIH protocol messages between peer MIHFs is required. 272 Although a new fast-delivery solution can be designed, other existent 273 solutions can be envisioned. 275 To address seamless mobility support, media independent handovers 276 together with fast/local mobility approaches are not sufficient. 277 When users move while accessing real-time services, resources need to 278 be reserved in advance in the new network to guarantee that the 279 services maintain their quality. Next Steps in Signalling (NSIS) [3] 280 QoS signalling protocol is an emergent QoS signalling and reservation 281 protocol with capabilities to be used in mobile environments. NSIS 282 decomposes the overall signalling protocol suite into a generic 283 (lower) layer and specific upper layers for each specific signalling 284 application. In the lower layer, General Internet Signalling 285 Transport (GIST) [4] offers transport services to higher layer 286 signalling applications for two purposes: sending and receiving 287 signalling messages between neighbour hops (NSIS entities), and 288 exchanging control and feedback information. Above this layer, there 289 is the NSIS Signalling Layer Protocol (NSLP) layer [5], which 290 generically stands for any protocol within the signalling application 291 layer. 293 NSIS is very well suited for heterogeneous wired and wireless 294 networks and is able to interact with mobility protocols for seamless 295 handovers. Therefore, to enable the support of seamless mobility, 296 MIH can be integrated with NSIS and cooperate in the handover 297 process. To provide a clean cooperation with low overhead (both in 298 messages exchanged and time), and since MIH protocol messages require 299 a transport protocol, we propose and define a MIH NSLP to use NSIS as 300 a transport protocol for MIH messages. 302 4. Media Independent Handover NSLP Specification 304 In order to use the NSIS framework to transport MIH messages, a 305 specific NSLP, the Media Independent Handover NSLP, is developed in 306 this document. The MIH NSLP allows the distribution of MIH messages 307 across different networks. The following describes the procedure to 308 transport MIH messages within the MIH NSLP, followed by the 309 specification of the MIH NSLP architecture. 311 4.1. MIH NSLP Architecture 313 The MIH NSLP is responsible for the transport of MIH Messages using 314 the GIST protocol. Figure 2 details the architecture of NSIS usage 315 as the MIHF transport protocol. 317 +----------+ 318 | MIHF | 319 +----------+ 320 | ^ 321 +----------|--|----------+ 322 |NSIS | | | 323 | v | | 324 | +------------------+ | 325 | | MIH NSLP | | 326 | +------------------+ | 327 | | ^ | 328 | v | | 329 | +------------------+ | 330 <--|--| GIST |--|--> 331 | +------------------+ | 332 +------------------------+ 334 Figure 2: MIH NSLP architecture 336 This figure shows the interaction between the MIH NSLP, the MIHF and 337 the GIST protocol. 339 The MIH NSLP interface with MIHF handles the MIHF MIH Message 340 exchange. This interface is compliant with the MIH_NET_SAP defined 341 in [6]. 343 The MIH NSLP interface with GIST handles message transport. This 344 interface is specified in [4]. 346 The MIH NSLP is split in six different functionalities as follows: 348 o Interface with MIHF 349 o Interface with GIST 351 o Message transport (and retransmission if acknowledge is required) 353 o Message reception 355 o Message interception 357 o MIH Registration Server (only active through an election process - 358 out of scope) 360 * Registration 362 * DeRegistration 364 * Request 366 * Messages retransmission 368 These functionalities are described in the next sections. 370 4.2. MIH Message Transport 372 As specified in [6], MIHF entities need to propagate MIH messages 373 towards peer MIHF entities. The MIH standard does not include the 374 specification of a transport protocol, at layer 3, and only the 375 requirements for this protocol are defined. These requirements can 376 be summed up to reliability and security over the MIH exchanged 377 messages, requirements that are met by the GIST protocol. 379 Figure 3 shows an example of the NSIS usage to transport MIH 380 Messages. 382 +--------------+ +--------------+ +--------------+ 383 | MIHF | | MIHF | | MIHF | 384 | Source | | Middle | | Destination | 385 +--------------+ +--------------+ +--------------+ 386 | ^ | ^ 387 V | v | 388 +--------------+ +--------------+ +--------------+ 389 | NSIS |=====>| NSIS |=====>| NSIS | 390 +--------------+ +--------------+ +--------------+ 392 --> MIHF interface messages 393 ==> NSIS messages 395 Figure 3: NSIS usage to transport MIH Messages 397 This figure presents the interaction between the MIHF and the NSIS 398 framework and the transport of MIH Messages between a Source and a 399 Destination MIHF. In this scenario, the Middle MIHF also intervenes 400 by receiving the message exchanged due to the intercept NSIS feature. 401 The processing of these intercepted messages is out of the scope of 402 this document. 404 To be able to transport the MIH Messages, NSIS requires the 405 destination network address of the MIHF Destination. However, MIH 406 entities only handle MIHF Identifiers (ID) to identify the remote 407 MIHF. Therefore, there is the need to perform the mapping between 408 the MIHF ID and the correspondent network addresses, which is under 409 NSIS responsibility. 411 The main functionality of the MIH NSLP is to handle the mapping 412 between MIHF ID and network addresses, since GIST is able to provide 413 all the required functionalities required by the MIH specification 414 for MIH Message transport. The mapping procedure is described in the 415 next sub-section. 417 Figure 4 shows the procedure to send MIH Messages to the remote MIHF 418 when the remote MIHF IP Address is available, either through the 419 cache mechanisms or resorting to the mapping procedure. 421 Source Middle Destination 422 MIH NSLP MIH NSLP MIH NSLP 423 | | | 424 | DATA(MIHF Msg) | | 425 |-------------------->| DATA(MIHF Msg) | 426 | |-------------------->| 427 | | | 428 | | DATA ACK()[opt] | 429 | DATA ACK()[opt] |<--------------------| 430 |<--------------------| 431 | | 433 Figure 4: Message transport between two MIH NSLP 435 In this figure the MIHF Message needs to be sent from the Source MIH 436 NSLP to the Destination MIH NSLP. To send the MIHF Message, the MIH 437 NSLP creates a MIH NSLP DATA message with the MIHF Message as one of 438 its components. 440 During the message exchange, the DATA message is intercepted in the 441 Middle MIHF. According to the MIH NSLP architecture, this feature 442 could be useful for several scenarios. However, this feature is out 443 of scope of this document. If no specific action is defined in the 444 Middle MIHF entity, the MIH NSLP MUST forward the DATA message to the 445 Destination MIH NSLP. 447 When a DATA message reaches the destination, the MIHF Message is 448 forwarded to the local MIHF for processing. The MIH Message 449 information is transparent to the MIH NSLP. The MIHF processing is 450 defined in [6]. 452 Optionally, a DATA ACK message can be sent to the Source MIH NSLP 453 when the DATA message arrives to the Destination MIH NSLP. This 454 feature can be requested by the Source MIH NSLP and SHOULD depend on 455 the transfer attributes requested to GIST (reliable and/or secure). 457 A MIHF response to the received MIH Message is treated as a new 458 request by the MIH NSLP. The MIH NSLP does not handle states for the 459 MIH Messages. 461 4.3. Mapping between MIHF ID and Network Addresses 463 In order to map all MIHF ID into network addresses a MIH Registration 464 Server is required. This MIH Registration Server is responsible for 465 handling the mapping between MIHF ID and network addresses of MIHF 466 entities. For this purpose one entity MUST be elected as a MIH 467 Registration Server. The election of this entity is out of scope of 468 this document because it depends on specific deployment scenarios 469 characteristics. In the example described in Section 5 an 470 appropriate choice would be the CN entity. The knowledge of the MIH 471 Registration Server MUST be known to all MIHF entities involved. 473 With the usage of the MIH Registration Server, when a MIH NSLP needs 474 to send a MIH Message to a remote MIHF, it queries the MIH 475 Registration Server in order to receive the appropriate network 476 address. Figure 5 and Figure 6 highlight the MIH NSLP message 477 exchange to perform a MIHF ID mapping to a network address. 479 Figure 5 describes the procedure that a MIH NSLP performs when it is 480 ready to transport MIH Messages. 482 MIH MIH Registration 483 NSLP Server 484 | | 485 | IP REGISTER | 486 | (MIHF ID, IP) | 487 |-------------------->| 488 | | +-----------------+ 489 | | | Register IP | 490 | IP REGISTER ACK() | +-----------------+ 491 |<--------------------| 492 | | 493 . . 494 . . 495 . IP DEREGISTER . 496 | (MIHF ID) | 497 |-------------------->| 498 | | +-----------------+ 499 | | | DeRegister IP | 500 | IP DEREGISTER ACK() | +-----------------+ 501 |<--------------------| 502 | | 504 Figure 5: MIH NSLP registration/deregistration in a MIH Registration 505 Server 507 This registration procedure is composed by four MIH NSLP messages, 508 the IP REGISTER, the IP REGISTER ACK, IP DEREGISTER and the IP 509 DEREGISTER ACK. The IP REGISTER message is sent by the MIH NSLP to 510 the MIH Registration Server to register its MIHF ID and IP Address in 511 the MIH Registration Server. To confirm the registration of the MIH 512 NSLP, the MIH Registration Server sends an IP REGISTER ACK to the MIH 513 NSLP with the result of the registration. The registration result 514 can be: 516 o Successful: the registration process was successful; 518 o Warning due to duplicate MIHF ID: the received MIHF ID already 519 exists with a different IP Address; 521 o Warning due to duplicate IP Address: the received IP Address 522 already exist with a different MIHF ID; 524 o Internal failure: an error occurred not related to the request 525 received. 527 After a successful/warning registration procedure the MIH 528 Registration Server is able to map this MIHF ID to the appropriate IP 529 Address and the MIH NSLP is ready to transport MIH Messages. The MIH 530 NSLP actions to a warning and failure registration are implementation 531 dependent. 533 The IP DEREGISTER message is sent to the MIH Registration Server when 534 the MIH NSLP intends to stop functions. This message includes the 535 MIHF ID that is to be removed from the registry. After the registry 536 deregistration the MIH Registration Server send an IP DEREGISTRATION 537 ACK to the MIH NSLP notifying it of the registration result. The 538 deregistration result can be: 540 o Successful: the deregistration process was successful; 542 o Warning due to unknown MIHF ID: the received MIHF ID does not 543 exists; 545 o Internal failure: an error occurred not related to the request 546 received. 548 Figure 6 describes the procedure that a MIH NSLP performs to map a 549 MIHF ID to an IP Address. 551 MIH MIH Registration 552 NSLP Server 553 | | 554 | IP REQUEST(MIHF ID) | 555 |-------------------->| 556 | | +-----------------+ 557 | | | Mapping MIHF ID | 558 | | | to IP Address | 559 | IP RESPONSE(IP) | +-----------------+ 560 |<--------------------| 561 | | 562 | IP ERROR() |(When an error in 563 |<--------------------| mapping occurs) 564 | | 566 Figure 6: MIH NSLP mapping procedure 568 In this figure there are two MIH NSLP messages, the IP REQUEST and 569 the IP RESPONSE. The IP REQUEST message is sent from the MIH NSLP 570 that requires the mapping to the MIH Registration Server with the 571 MIHF ID that needs to be mapped to an IP address. After the MIH 572 Registration Server mapping, an IP RESPONSE message is sent from the 573 MIH Registration Server to the requesting MIH NSLP. This message 574 includes the IP address that resulted from the mapping of the request 575 MIHF ID. 577 In the MIHF ID mapping process some errors MAY occur. When an error 578 happens the MIH Registration Server entity MUST send an IP ERROR 579 message to the requesting MIH NSLP stating the error. The possible 580 errors are: 582 o Unknown MIHF ID: there is no reference to the requested MIHF ID; 584 o Unknown IP Address: there is no IP Address associated to the 585 requested MIHF ID; 587 o Internal Error: an error occurred not related to the MIHF ID or 588 the IP Address. 590 When IP REGISTER, IP DEREGISTER and IP REQUEST messages are sent, a 591 timer MUST be set to prevent the case of starvation due to a failure 592 in receiving the respective responses. These cases can occur when: 594 o The MIH Registration Server cannot be reached; 596 o The MIH Registration Server fails to respond. 598 If a timer expires, the IP REGISTER, IP DEREGISTER or IP REQUEST 599 message MUST be retransmitted until a maximum of three times. Each 600 time the timer expires the timer period SHOULD be doubled. 602 For the IP REGISTER ACK, IP DEREGISTER ACK, IP RESPONSE and IP ERROR 603 messages there is no need for timers. In the case these messages 604 fail to arrive to the MIH NSLP, the retransmission procedure will 605 force the resend of the appropriate response message. 607 5. Mobility Scenario Example 609 This section will present an example (including a picture) of the use 610 the Mobility NSLP to transport MIH messages in the mobility context - 611 controlled by the CSN. 613 This section presents a sample mobility scenario, where the exchange 614 of MIHF messages among different network nodes allows the efficient 615 management of control plane functionalities, such as data plane 616 configuration and resource reservation for the traffic flows involved 617 in the handover. 619 The example scenario is shown in Figure 7. It consists of a Mobile 620 Node (MN) with two network interfaces (ETH and WiFi) which is 621 connected to a Wi-Fi Access-Point attached to a WiMAX fixed 622 Subscriber Station (serving SS). The MN moves and, since the radio 623 signal becomes lower, the user decides for the ETH connection and 624 plugs in the cable. The ETH network is connected to another WiMAX 625 fixed Subscriber Station (target SS), located in the same Access 626 Service Network of the serving SS. Both the stations are connected 627 to Base Stations (BS) controlled by the same ASN gateway (ASN-GW). 629 ______ 630 | | ______ _______ _______ 631 | MN | | IEEE | | IEEE | | IEEE | 632 |______|****** |802.11|=====|802.16d|-.-.-.-.-|802.16d| 633 || | AP | | SS | | BS | ________ 634 || |______| |_______| |_______|=====| | 635 || | | 636 || | | 637 || | ASN-GW | 638 \/ | | 639 ______ | | 640 | | _______ _______ | | 641 | MN | | IEEE | | IEEE |=====|________| 642 |______|====================|802.16d|-.-.-.-.-|802.16d| 643 | SS | | BS | 644 |_______| |_______| 646 ******** Wi-Fi Link 647 -.-.-.-. Wi-MAX Link 649 Figure 7: Example of Mobility Scenario with heterogeneous networks 651 This type of scenario includes a double mobility. The host is 652 initially connected via Wi-Fi and afterwards uses the wired ETH 653 connection (mobility between heterogeneous networks). At the same 654 time the handovers involves two Subscriber Stations of the same WiMAX 655 technology (IEEE 802.16d), following the intra-ASN WiMAX mobility 656 model. 658 The considered MN hosts some active applications that require 659 specific levels of guaranteed QoS. Therefore the related sessions 660 are initially associated to a particular set of Service Flows (SFs) 661 allocated on the WiMAX channel between the serving SS and its BS. 662 Each SF is characterized by a specific scheduling class and some 663 parameters, like bandwidth and jitter that specify the QoS level for 664 the data traffic. 666 Following a network-initiated approach, the SF configuration and 667 activation is handled at the ASN-GW level by specific procedures that 668 intercept different kinds of high level signalling (i.e. QoS NSLP, 669 SIP) in order to extract the QoS parameters required by the 670 application, map them in a set of SFs and finally configure the BSs 671 to allocate the resources on the wireless link. 673 The MN handover requires the WiMAX channel re-configuration, with the 674 creation and the activation of suitable SFs between the target SS and 675 the related BS. On the other hand, the existing SFs between the 676 serving SS and the related BS MUST be removed. This procedure SHOULD 677 be transparent to the high level signalling and, at the same time, 678 requires the direct action of the ASN-GW for the session management 679 and the explicit resource allocation in the WiMAX link. 681 This objective can be easily reached with the exchange of MIH 682 messages between the MN and the ASN-GW using the MIH NSLP. When 683 specific MIH Events are received by the gateway, the ASN-GW module 684 that handles the sessions and the WiMAX resource allocation (i.e. the 685 MIH User - MIHU) is informed of probable imminent handovers, 686 configures the resources on the new path and updates its internal 687 status with the up-to-date information about the involved sessions. 689 Similarly, if the mobility management system is based on a 690 centralized approach where handovers are controlled entirely at the 691 ASN-GW level, this MIHU can be able to send specific MIH Commands in 692 order to coordinate all the procedures at the lower layers. In such 693 situation, the handover management and the related decisions can be 694 more efficient if the ASN-GW is able to receive and process the 695 information provided by the Media Independent Information Service. 696 In this case the exchange of MIHF messages with other network 697 entities allows the MIHU to receive both lower layers and upper 698 layers information that can have an impact on the selection of the 699 target network during the handovers. 701 In the considered scenario, the MIH NSLP message exchange can be used 702 in order to achieve handovers based on the Make Before Break model 703 where the needed resources are configured before the actual 704 disconnection from the serving Point of Attachment (PoA) and 705 afterwards the resources on the old link are released. This approach 706 allows the applications to receive coherent QoS guarantees in case of 707 handovers between different networks. 709 As shown in Figure 8, the imminent disconnection of the MN from the 710 current Wi-Fi Access Point is notified to the ASN-GW through a Remote 711 MIH Link Going Down message, leading to the automatic resource re- 712 configuration on the WiMAX link. The deletion of the existing SFs 713 between the serving SS and BS is triggered by the following Remote 714 MIH Link Down message that signals the occurred disconnection from 715 the Wi-Fi network. 717 MN MN Serving Target ASN-GW ASN-GW 718 Lower MIHF WiMAX WiMAX MIHF MIHU 719 Layers BS BS 720 | | | | | | 721 | Link | | | | | 722 |-Going-->| | | | | 723 | Down | MIH Link | | | 724 | |-------Going Down------------->| MIH Link| 725 | | | | |-Going-->| 726 | | | | | Down | 727 | | | | | | 728 | | | | | | 729 | | | |<-----Resource------| 730 | | | |------Allocation--->| 731 | | | | | | 732 |-Link--->| | | | | 733 | Down | MIH Link | | | 734 | |-------Down------------------->| | 735 | | | | | MIH | 736 | | | | |-Link--->| 737 | | | | | Down | 738 | | | | | | 739 | | |<----------Resource------------| 740 | | |-----------Release------------>| 741 | | | | | | 742 | | | | | | 744 Figure 8: MIHF Signalling and resource control 746 As a further example (Figure 9), we can consider a mobility scenario 747 in a single WiMAX network, where a Mobile Station IEEE 802.16e (MS) 748 moves from the serving BS to the target BS. Following the intra-ASN 749 scenario, both the BSs are located in the same access service network 750 and are controlled by the same ASN-GW. We can assume that the 751 management of the high level sessions and the associated QoS is 752 handled at the ASN-GW level, as in the previous scenario. 754 _______ _______ 755 | IEEE | | IEEE | 756 |802.16e|-.-.-.-.-|802.16e| 757 | MS | | BS | ________ 758 |_______| |_______|=====| | 759 | | 760 | | 761 | ASN-GW | 762 | | 763 | | 764 _______ _______ | | 765 | IEEE | | IEEE |=====|________| 766 |802.16e|-.-.-.-.-|802.16e| 767 | MS | | BS | 768 |_______| |_______| 770 -.-.-.-. Wi-MAX Link 772 Figure 9: Example of Mobility Scenario in a WiMAX network - ASN- 773 anchored 775 In this case, the handover management can be coordinated directly 776 among the MS and the involved BSs, through the creation and the 777 activation of suitable SFs on the target path and the deletion of the 778 previous ones. Nevertheless the ASN-GW can obtain some notifications 779 about the handovers and the occurred changes in lower layers through 780 the MIH Event Service messages received through the MIH NSLP. These 781 notifications allow the ASN-GW to correctly update the mobility 782 "context" (SS and BS MAC address, SFs and classifiers, WiMAX security 783 information, HA IP address, CoA, DHCP server, AAA server) for each 784 existing session, so that it is able to manage possible resource re- 785 configuration if required by the associated high level signalling. 787 In IEEE 802.16e networks, the MS can move between BSs under control 788 of different ASNs and managed by different ASN-GWs (CSN-anchored 789 mobility). In this case, the functionalities for the handover 790 management SHOULD be split among different entities located not only 791 in the ASN but also in the Connectivity Service Network and in the 792 core network. The MIH NSLP protocol can be used in order to 793 propagate the MIH Event and Command messages along the full path 794 between the serving and the target BS, towards all the MIH peers 795 located in ASNs and CSNs of different domains (Figure 10). 797 _______ 798 | IEEE | _________ _______ 799 |802.16e| | IEEE | | | 800 |__MS___|-.---.-.-.-.| 802.16e |=========| ASN | 801 || | BS | | GW 1 | _______ 802 || |(serving)| |_______|=======| | 803 || |_________| | CSN 1 | 804 || |_______| 805 || | 806 \/ ___|___ 807 _______ | | 808 | IEEE | _________ _______ | CSN 2 | 809 |802.16e| | IEEE | | |=======|_______| 810 |__MS___|-.-.-.-.-.-.| 802.16e |=========| ASN | 811 | BS | | GW 2 | 812 |(target) | |_______| 813 |_________| 815 -.-.-.-. Wi-MAX Link 817 Figure 10: Example of Mobility Scenario in a WiMAX network - CSN- 818 anchored 820 6. Security Considerations 822 The exchange of MIH NSLP messages MUST be secured against security 823 threats, which have been identified in [7]. GIST is responsible for 824 some of the security aspects of signalling [3]. Additionally, NSLPs 825 MUST be in charge of threats concerning authorization, message 826 protection, rate limitation, and prevention of denial of service 827 attacks, as described in [4]. The use of these mechanisms in MIH 828 NSLP is under study. 830 7. Open issues 832 This document specifies the MIH NSLP protocol, but leaves some issues 833 unaddressed: 835 o The usage of MIH NSLP and GIST as the MIHF transport protocol adds 836 additional security threats that are not addressed in the GIST and 837 MIHF specifications. Some of these security issues are: 839 * The interception of MIH Messages by middle MIHF entities; 840 * The registration and deregistration process; 842 * Unauthorized requests or unauthorized MIH Messages. 844 o The MIH NSLP registration procedure needs to include a refresh 845 feature to maintain the MIH Registry Server updated. The MIH 846 Registry Server should use soft states to store the mapping 847 information; 849 o A default timer value SHOULD be proposed for the MIH NSLP message 850 retransmit timer. 852 o The MIH NSLP messages MUST be specified. A MIH NSLP Message 853 SHOULD consist of: 855 * A common message header; 857 * A group of type-length-value (TLV) objects. 859 o Several optimizations SHOULD be done to the MIH NSLP protocol. 860 These optimizations SHOULD minimize the number of signalling 861 messages and improve the MIH NSLP performance. An example of an 862 optimization is the usage of a cache feature for the MIHF ID and 863 IP Address mapping in the source and middle MIH NSLP. 865 These open issues will be addressed in future versions of this 866 document. 868 8. Acknowledgments 870 The authors would like to thank all the partners of the IST FP6 871 Integrated Project WEIRD which were involved in the development of 872 the mobility architecture of the project, especially, Eugen Borcoci, 873 Massimiliano Taglieri and Bruno Sousa. 875 9. Normative References 877 [1] Melia, T., Bajko, G., Das, S., Golmie, N., Xia, Z., and J. 878 Zuniga, "Mobility Services Framework Design", 879 draft-ietf-mipshop-mstp-solution-01 (work in progress), 880 February 2008. 882 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 883 Levels", BCP 14, RFC 2119, March 1997. 885 [3] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 886 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, 887 June 2005. 889 [4] Schulzrinne, H. and R. Hancock, "GIST: General Internet 890 Signalling Transport", draft-ietf-nsis-ntlp-15 (work in 891 progress), February 2008. 893 [5] Manner, J., Karagiannis, G., and A. McDonald, "NSLP for Quality- 894 of-Service Signaling", draft-ietf-nsis-qos-nslp-16 (work in 895 progress), February 2008. 897 [6] "IEEE Draft Standard for Local and Metropolitan Area Networks: 898 Media Independent Handover Services", IEEE 802.21 Working Group, 899 February 2007. 901 [7] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next 902 Steps in Signaling (NSIS)", RFC 4081, June 2005. 904 Authors' Addresses 906 Luis Cordeiro 907 University of Coimbra 908 Polo II - Pinhal de Marrocos 909 Coimbra 3030-290 910 Portugal 912 Email: cordeiro@dei.uc.pt 914 Marilia Curado 915 University of Coimbra 916 Polo II - Pinhal de Marrocos 917 Coimbra 3030-290 918 Portugal 920 Email: marilia@dei.uc.pt 922 Pedro Neves 923 Portugal Telecom Inovacao, S.A. 924 Rua Eng. Jose Ferreira Pinto Basto 925 Aveiro 3810-106 926 Portugal 928 Email: est-p-neves@ptinovacao.pt 929 Susana Sargento 930 University of Aveiro 931 Campus Universitario de Santiago 932 Aveiro 3810-193 933 Portugal 935 Email: ssargento@det.ua.pt 937 Giada Landi 938 Consorzio Pisa Ricerche 939 Via Turati, 43-45 940 Pisa 56125 941 Italy 943 Email: g.landi@cpr.it 945 Xiaoming Fu 946 University of Goettingen 947 Lotzestrasse 16-18 948 Goettingen 37083 949 Germany 951 Email: fu@cs.uni-goettingen.de 953 Full Copyright Statement 955 Copyright (C) The IETF Trust (2008). 957 This document is subject to the rights, licenses and restrictions 958 contained in BCP 78, and except as set forth therein, the authors 959 retain all their rights. 961 This document and the information contained herein are provided on an 962 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 963 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 964 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 965 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 966 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 967 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 969 Intellectual Property 971 The IETF takes no position regarding the validity or scope of any 972 Intellectual Property Rights or other rights that might be claimed to 973 pertain to the implementation or use of the technology described in 974 this document or the extent to which any license under such rights 975 might or might not be available; nor does it represent that it has 976 made any independent effort to identify any such rights. Information 977 on the procedures with respect to rights in RFC documents can be 978 found in BCP 78 and BCP 79. 980 Copies of IPR disclosures made to the IETF Secretariat and any 981 assurances of licenses to be made available, or the result of an 982 attempt made to obtain a general license or permission for the use of 983 such proprietary rights by implementers or users of this 984 specification can be obtained from the IETF on-line IPR repository at 985 http://www.ietf.org/ipr. 987 The IETF invites any interested party to bring to its attention any 988 copyrights, patents or patent applications, or other proprietary 989 rights that may cover technology that may be required to implement 990 this standard. Please address the information to the IETF at 991 ietf-ipr@ietf.org. 993 Acknowledgment 995 Funding for the RFC Editor function is provided by the IETF 996 Administrative Support Activity (IASA).