Internet Draft H.Y. Lach Document: draft-lach-nac-01.txt M. Catalina Expires: April 2004 Motorola Labs October 2003 Network Access Co-ordination to Complement IP Mobility Protocols 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 draft addresses the need to complement the IP mobility protocols with respect to the co-ordination of a mobile node's network access. The concept of Network Access Agent (NAA) is introduced as a functional entity in the network to assist the mobile node's IP handoff strategy. The Network Access Co-ordination Protocol (NACP) is proposed as an interaction mechanism between the NAA and the mobile node, so that the NAA can provide valuable information and recommendations to the mobile node to consider in IP handoff. The NACP is conceived so that it is completely independent of the Mobile IP protocols. Table of Contents 1. Introduction 2 2. Terminology 3 2.1. General Terms . . . . . . . . . . . . . . . . . . . . 3 2.2. Specific Terms . . . . . . . . . . . . . . . . . . . 4 3. Network access co-ordination 4 4. Overview of the Network Access Co-ordination Protocol (NACP) . . . . . . . . . . . . . . . . . . . . . . . . 6 Lach, Catalina Expires April 2004 [Page 1] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols 4.1. Service Contract Information Requests And Replies . . 6 4.2. Service Requests and Replies . . . . . . . . . . . . 7 4.3. Quality Report Requests and Replies . . . . . . . . . 10 4.4. Handover Required Notification . . . . . . . . . . . 11 4.5. Candidate network selection . . . . . . . . . . . . . 12 5. Network Access Co-ordination Protocol (NACP) specification 13 5.1. General protocol considerations . . . . . . . . . . . 14 5.1.1. Authentication . . . . . . . . . . . . . . . 14 5.1.2. Timestamps . . . . . . . . . . . . . . . . . 15 5.1.3. Acknowledgements . . . . . . . . . . . . . . 15 5.1.4. Retransmission . . . . . . . . . . . . . . . 15 5.1.5. Message order . . . . . . . . . . . . . . . . 16 5.2. Generic header and extension format . . . . . . . . . 16 5.2.1. Header format . . . . . . . . . . . . . . . . 16 5.2.2. Extension format . . . . . . . . . . . . . . 18 5.3. NACP messages . . . . . . . . . . . . . . . . . . . . 19 5.3.1. Service Contract Information Request message . . . . . . . . . . . . . . . . . 19 5.3.2. Service Contract Information Reply message . 19 5.3.3. Service Request message . . . . . . . . . . . 20 5.3.4. Service Reply message . . . . . . . . . . . . 21 5.3.5. Quality Report Request message . . . . . . . 23 5.3.6. Quality Report Reply message . . . . . . . . 23 5.3.7. Handover Required Notification message . . . 24 5.3.8. Invalid ID message . . . . . . . . . . . . . 25 5.4. NACP Extensions . . . . . . . . . . . . . . . . . . . 26 5.4.1. Authentication extension . . . . . . . . . . 26 5.4.2. Service Definition extension . . . . . . . . 27 5.4.3. Network Availability extensions . . . . . . . 28 5.4.3.1. GPRS Availability extension . . . . 28 5.4.3.2. WLAN Availability extension . . . . 29 5.4.3.3. DVB-T Availability extension . . . 29 5.4.4. Service List extension . . . . . . . . . . . 30 5.4.5. Preferred Network List extension . . . . . . 31 5.4.6. IP Parameters Report extension . . . . . . . 32 5.4.7. Network Parameters Report extensions . . . . 33 5.4.7.1. GPRS Parameters Report extension . 33 5.4.7.2. WLAN Parameters Report extension . 33 5.4.7.3. DVB-T Parameters Report extension . 34 6. References 35 7. Acknowledgments 36 8. Author's Addresses 36 1. Introduction As a result of increasing popularity of wireless access networks such as cellular systems, wireless LANs (WLANs) and broadband wireless systems, it is envisaged that user systems will be Lach, Catalina Expires April 2004 [Page 2] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols increasingly mobile, changing their points of attachment to the network as they move. Mobile IP [MIP4] [MIP6] protocols specify how to maintain the connection of the mobile node to internet as it changes topologically its point of attachment to the network. It is the mobile node that initiates the IP handoff. However, it is envisaged that the mobile node along cannot always make the best decision on when to make an IP handoff and to which available access network. One source of information to aid the mobile node to make intelligent network selection is from the network, represented by one or more Network Access Agents (NAAs). The NAA is assumed to be able to obtain relevant network information, depending on the system deployment, such as network load in the access networks, operator policies of network use, movement trajectory of the mobile node, etc. One could imagine that the NAA could be used by the network operator to ensure most cost-efficient use of network resources. This draft propose the Network Access Co-ordination Protocol (NACP) that allows the mobile node to interact with the NAA to effectively co-ordinate the network access by the mobile node. The protocol is complementary to and independent of the Mobile IP protocols. Via this protocol, the mobile node will gain valuable recommendations from the NAA about the choice of access network to use. However, the mobile node is not obliged to follow solely the NAA's recommendation; it depends on the desired operational behaviour in the system deployment. 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2.1. General Terms General terms are as defined in [TERM]. Those of particular importance in this document are recalled hereunder: Mobile Node (MN) An IP node capable of changing its point of attachment to the network. Lach, Catalina Expires April 2004 [Page 3] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols 2.2. Specific Terms Network access co-ordination It refers to the co-ordination needed to determine a desired behaviour of network access by a mobile node. Such co-ordination is the function of the network access agent, which interacts with the mobile nodes under its scope of influence to recommend them the choice of access networks to use. Network Access Agent (NAA) It is the functional entity that co-ordinates the network access behaviours of the mobile nodes under its scope of influence. It could reside in any convenient node in the network infrastructure. Network Access Co-ordination Protocol (NACP) It is the protocol between a NAA and its MNs to achieve the network access co-ordination. 3. Network access co-ordination Mobile IP specifies a mechanism for a mobile node to initiate an IP handover. However, the process of network discovery and selection could best take advantage of the knowledge in the mobile node and the network. This allows different handover strategies to be adopted, taking into account of various desired criteria and policies. A mechanism is thus needed for the mobile node and the network to interact to jointly support selection, and re-selection, of the most appropriate access network for use by the mobile node in a heterogeneous network. This document introduces a Network Access Agent (NAA) in the network. It is responsible for collectively managing the network access behaviours of the mobile nodes under its scope of influence. The mobile node and the NAA exchange information towards beneficially combining the mobile node's "local view" (e.g. radio conditions in the area, services requested/received over the mobile node, etc.) and the "global view" of the network (e.g. traffic load over the various segments, the need to avoid congestion towards preserving QoS, etc). The desired MN-NAA interaction mechanism is expected to have the following technical requirements: * The mobile nodes are allowed to: Lach, Catalina Expires April 2004 [Page 4] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols -Notify the network about the candidate access networks in the area the mobile node is in. -Report to the network status parameters relating to the quality with which services are received over the mobile node; status values at the radio-, IP-, and (for enhanced services) application-level may be reported. -Ask from the network the engagement of new or additional services (at specific QoS levels, when these are available). -Notify the network about service termination. * The network access agent is enabled to: -Advise a mobile node about the access networks that should be selected (among the candidates) in decreasing order of appropriateness (determined by network load and the services received over the mobile node). A list of all alternative networks allows a mobile node to switch to the next network in the list, should the previous choice become suddenly unavailable. -Ask from mobile nodes to send status reports (as described above) whenever required for assessing the conditions in specific radio segments. -Instruct mobile nodes to switch to a different access network (either to preserve QoS in individual mobile nodes, or for the purpose of load balancing among different network segments). * The message protocol governing the interaction mechanism should not depend on the high-level IP means used for its implementation. In particular, the implementation should not assume that the order of messages sent from any communication end is preserved. Given the signalling nature of the protocol, low-overhead implementations requiring few packet exchanges may be preferable, but should not imposed by the protocol's structure. * The message protocol should be independent of the specific radio access technologies integrated into the composite network. As an example, this MN-NAA interaction mechanism could be used in a scenario in which: * The user of a terminal wants to engage a new service. The mobile node issues to NAA a request and the reply message indicates the access network that should be used (or deny the request). The mobile node switches to the indicated network. Lach, Catalina Expires April 2004 [Page 5] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols * Quality degradation is experienced at a mobile node. This is reported to NAA, which triggers an exchange of messages, so that the mobile node switches to a different access network, overcoming the problems. * In order to overcome problems in some network segment, or for load balancing purposes, the NAA determines that some terminals should change the access network they currently use. NAA triggers an exchange of messages with each of these terminals that leads to the appropriate network re-selections. 4. Overview of the Network Access Co-ordination Protocol (NACP) The messages of the signalling protocol between mobile nodes and the Network Access Agent fall in the following categories: * Initial mobile node registration/initialisation to the heterogeneous network; * A core pair of messages (a Service Request/Reply pair) used from a mobile node (the request) when asking for new services and/or when reporting a change in the currently running services (e.g. a stopped service) or in the candidate access networks, and from the NAA when replying with the appropriate network to be selected. * Messages for reporting quality status information from mobile nodes to the Network Access Agent. * A message from NAA to a MN for triggering a message exchange (a Service Request/Reply sequence) leading to reselection of the network segment used by the terminal. The messages of the protocol are further described by category in the following subsections. The final subsection illustrates the joint employment of protocol message exchanges and Mobile IP registration messages for effecting candidate network selection. 4.1. Service Contract Information Requests And Replies The "initialisation" messages are a Service Contract Information Request/Reply pair. The MN uses the Service Contract Information Request at startup to acquire Service Contract Information from the NAA. The Service Contract specifies the set of services (and the specific QoS level(s) for each service) a user is registered to. The information for each such service is contained within a (so called) Service Definition. All messages in the protocol (both in this and other subsections) refer to a particular service/QoS combination in an abstract way, through encoding numbers called Service Identifiers (SID). This arrangement allows the Lach, Catalina Expires April 2004 [Page 6] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols incorporation of new services or additional QoS levels without affecting the structure of information fields in the messages of the protocol. Figure 1 shows an example of a Service Contract Information Request/Reply exchange. Network Mobile Access Node Agent ... ... | | 1. Service Contract | | Information Request |----------->| | | |<-----------| 2. Service Contract | | Information Reply | | (Service Def. SD1; | | Service Def. SD2; | | ...) | | ... ... Figure 1. Service Contract Information Request/Reply example When the mobile node is turned on and connects to the network for the first time, it sends a Service Contract Information Request (message 1) to acquire the Service Definitions for the Services the user has subscribed to. The NAA replies with the list of Service Definitions for the specific terminal/user (message 2). 4.2. Service Requests and Replies The Service Request/Reply pair of messages constitute the core of the protocol. In brief, the mobile node uses the Service Request to tell the Network Access Agent its current configuration, that is, the list of available networks at this moment, and the services that the user is running. Correspondingly, the NAA uses the Service Reply to tell the mobile node which network to choose and accept or deny the execution of the user services. During startup, after the Service Contract Information has been obtained, the mobile node sends a Service Request to the NAA with the list of available networks and the network it has chosen. It must also tell the NAA that no services are being run at this moment. The NAA notes that the indicated terminal is running and takes it into account in its calculations. It must tell the mobile node the network it should choose. This is indicated through a list of preferred networks. The mobile node should switch to the first Lach, Catalina Expires April 2004 [Page 7] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols network on the list. If this fails for any reason, or the network becomes suddenly unavailable, the mobile node should switch to the next one on the list. When the user requests a service, the mobile node must send a new Service Request with the ID of the requested service. Every Service Request contains a list of the IDs of all the services currently running in the terminal. To notify that a service has stopped, the mobile node would simply send a Service Request in which the ID of the stopped service is not listed. Service Reply always contains a list with all the services that were present in the Service Request, and explicitly accepts or rejects each of them. If a service that had been accepted in a previous Service Request is now rejected, the mobile node must stop it. The NAA can use this to explicitly request the mobile node to stop a service. Figure 2 shows an example of Service Requests/Replies exchanges. Network Mobile Access Node Agent ... ... | | 1. Service Request | | (av. networks=GPRS(1), | | WLAN X(2), DVB-T(3); | | Services=none; | | Current network=1) |----------->| | | |<-----------| 2. Service Reply | | (Services=none; | | Pref. networks=2,1,3) | | ... ... Figure 2a. Service Request/Reply example: mobile node startup. Lach, Catalina Expires April 2004 [Page 8] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols Network Mobile Access Node Agent ... ... | | 3. Service Request | | (av. networks=GPRS(1), | | WLAN X(2), DVB-T(3); | | Services=video-hi; | | Current network=2) |----------->| | | |<-----------| 4. Service Reply | | (Services=(video-hi, | | accept); | | Pref. networks=3,2,1) | | ... ... Figure 2b. Service Request/Reply example: the mobile node requests a service. Network Mobile Access Node Agent ... ... | | 5. Service Request | | (av. networks=GPRS(1), | | DVB-T(3); | | Services=video-hi; | | Current network=3) |----------->| | | |<-----------| 6. Service Reply | | (Services=(video-hi, | | accept); | | Pref. networks=3,1) | | ... ... Figure 2c. Service Request/Reply example: an access network becomes unavailable in the mobile node. In the first example, in Figure 2a, when the mobile node is turned on and connects to the network for the first time it sends a Service Request with its current configuration (message 1). The mobile node has detected a GPRS network, with ID 1, a WLAN network whose ESSID is X with ID 2 and a DVB-T network with ID 3. The user is not running any service and the current active network is GPRS (ID 1). The NAA replies with the preferred network list for the current network configuration (message 2). When the mobile node Lach, Catalina Expires April 2004 [Page 9] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols receives this message it must switch to the WLAN network with ESSID X (ID 2). The next example, in Figure 2b, shows the message exchange when the user requests a new service. The mobile node sends a Service Request with the service ID. The NAA accepts the service and selects the DVB-T network for it. The MN must switch to the DVB-T network when it receives the Service Reply. The Service Reply also tells the MN which network to use as the return path for unidirectional networks, such as the DVB-T network. Note that the application software running over the terminal will not start the new service until the confirmation from NAA has arrived. In messages 5 and 6, in Figure 2c, the MN notifies the NAA that the WLAN network X is no longer available. The NAA just replies to accept the new situation. 4.3. Quality Report Requests and Replies In order to keep the service provision at a satisfactory quality level, the mobile node reports back to the Network Access Agent, whenever required. In emergency situations, such as overall network degradation, the NAA can request a report from the MN, via the Quality Report Request message. The MN issues a corresponding report towards the NAA, providing measurements that reflect the quality level at which each service is provided to the particular terminal. This report is encapsulated in the appropriate Quality Report Reply message. The information that should be contained in such a Quality Report Reply message consists of a set of parameters monitored by the mobile node. Figure 3 displays an example of a Quality Report Request/Reply exchange. Lach, Catalina Expires April 2004 [Page 10] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols Network Mobile Access Node Agent ... ... | | | | 1. Quality Report Request |<-----------| | | 2. Quality Report Reply |----------->| (WLAN id=3, | | bit rate=5 Mbps, | | signal=150 dbm, | | noise=20 dbm) | | | | ... ... Figure 3. Quality Report Request/Reply example The NAA identifies a new environment condition (e.g. traffic load alteration) and requires information from some mobile nodes. In order to obtain this information, the NAA issues a Quality Report Request towards these MNs. Each of the addressed MNs provides the required information by forming a corresponding Quality Report Reply message. First the NAA decides the terminals from which quality of service related information should be required. A Quality Report Request is sent to each MN (message 1). When the terminal receives the request it sends a Quality Report Reply (message 2). 4.4. Handover Required Notification If the network conditions change, the NAA may decide to switch one or more users to a different network. The NAA must send a message to the MN to tell it the new network. With Service Request/Reply messages this can only be done in Service Replies, but Service Replies can only be sent on response to Service Requests, thus the NAA cannot send an unsolicited Service Reply to the MN to make it switch networks. And this is where the Handover Required Notification comes in. The protocol specifies that when the MN receives a Handover Required Notification it must send a Service Request. Thus, the NAA uses the Handover Required message to force a new Service Request/Reply cycle. Note that the Handover Required Notification itself does not inform the MN of the new network selection. This is done on the Service Reply. Figure 4 shows how the Handover Required Notification works. First the NAA detects that the terminal should be switched to a different network, so it sends a Handover Required Notification (message 1). Lach, Catalina Expires April 2004 [Page 11] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols When the terminal receives the notification it sends a Service Request (message 2). The corresponding Service Reply (message 3) from the NAA specifies the new network that the terminal should use. The MN must switch networks when it receives the reply. Network Mobile Access Node Agent ... ... | | |<-----------| 1. Handover Required 2. Service Request | | Notification (av. networks=GPRS(1), | | WLAN X(2), DVB-T(3); | | Services=video-hi; | | Current network=3) |----------->| | | |<-----------| 3. Service Reply | | (Services=(video-hi, | | accept); | | Pref. networks=2,3,1) | | ... ... Figure 4. Handover Required Notification example It is envisaged that the NAA will periodically check if the network selection obtained from its optimisation algorithms and the current active network reported in the Service Request are different. In this case it sends a Handover Required Notification to force it to reconfigure. 4.5. Candidate network selection Figure 5 illustrates the joint employment of protocol message exchanges and Mobile IP registration messages for effecting candidate network selection. In the figure's example, the terminal starts by using the GPRS network. At a later time, the user decides to start a new service; in reflection of this, the MN sends a Service Request message to the NAA, containing the list of available networks and the list of running services. The NAA sends a reply telling the MN to switch to the WLAN network. Once a candidate network has been selected, the MN starts the Mobile IP registration process with the home agent. When the Mobile IP registration completes, data is transferred over the selected network. Note that a stationary MN, that is, a MN that is not moving, uses the same mechanism to perform handover, since the IP addresses are assigned independently to the GPRS and WLAN interfaces. The notion Lach, Catalina Expires April 2004 [Page 12] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols of movement in the Mobile IP context refers just to a change of care-of address. Since the WLAN and GPRS interfaces always have different care-of addresses, a vertical handover is considered as movement from the Mobile IP point of view. Home Correspondent Mobile Node Agent NAA Node GPRS WLAN | | | interface interface | | | | | | | | | /-------------------------------------------------\ | |< APPLICATION DATA >| | \-------------------------------------------------/ | | | | | | | | | | | | NACP Service Request | | | |-------------------------------------->| | | | | | | | NACP Service Reply | | | |<--------------------------------------| | | | | | | | | MIP Binding | | | | | Update | | | | |------------->| | | | | | | | | | MIP Binding | | | | | Ack. | | | | |<-------------| | | | | | | | | | /--------------------------------------\ | | |< APPLICATION DATA >| | | \--------------------------------------/ | | | | | | Figure 5. Protocol message exchange effecting Candidate Network Selection 5. Network Access Co-ordination Protocol (NACP) specification This section describes the Network Access Co-ordination Protocol as it has been used during our tests and experiments. The protocol is adapted to the particular case of our experiments, that is, an IPv4 network with IEEE802.11b, GPRS and DVB-T (unidirectional) segments using Mobile IPv4 to manage mobility between them. The protocol could be easily rearranged to work in IPv6/Mobile IPv6 based networks and with other access technologies. Lach, Catalina Expires April 2004 [Page 13] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols 5.1. General protocol considerations NACP is a UDP based protocol used to exchange signaling messages between the Mobile Node and the NAA. Both the NAA and the Mobile Node must listen to NACP messages. The NAA must listen on UDP port 1435, and the Mobile Node on port 1434. NACP messages consist of a header plus a variable number of TLV (Type-Length-Value) extensions. The NACP message header contains the following information: * An ID indicating the type of message. * A timestamp used to uniquely identify the message and to match requests and replies. This timestamp follows the same rules as the ID field of the Mobile IP registration headers. * The IP address of the sender, which is used for authentication purposes. The rest of the fields in the header depend on the particular message type. Message types can be classified in four categories: * Requests: request messages can contain any type of information. A NACP request always produces a reply. NACP requests must be retransmitted if a reply is not received within a certain time period (see Section 5.1.4 for details). Thus requests can be considered reliable, since they have an acknowledge mechanism. * Replies: they are sent in response to request messages. They can be used just as an acknowledgement or they can contain information of their own. * Notifications: they are just like requests, except that they do not produce a reply. They can be used when it is not important to guarantee that they arrive at their destination. * Errors: they are a special kind of notification. They are used to inform of protocol errors, like an invalid timestamp. They are always sent in response to an invalid incoming message (request, reply or notification). 5.1.1. Authentication NACP uses the same authentication mechanisms as Mobile IP [MIP4]. All messages must always contain an authentication extension, which must be the last extension. Lach, Catalina Expires April 2004 [Page 14] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols All NACP entities (the NAA and the MNs) have a Security Association database that holds the authentication algorithms and keys that have to be used to exchange NACP messages with other NACP entities. The database in the terminals only has the Security Association they need to communicate with the NAA. The authentication extension consists of an SPI (Security Parameters Index) and an authenticator. The terminal Home Address and the SPI are used to select a Security Association in the Security Association Database. The Security Association specifies which authentication algorithm and key must be used to create and validate the authenticator. Since the authentication system is exactly the same as in Mobile IP, the Security Associations can be shared. This means that the same Security Association that is used for Mobile IP registrations between the Home Agent and the terminal will be used to authenticate NACP messages between the NAA and the MN. 5.1.2. Timestamps The NACP message header contains a timestamp whose main function is the anti-replay protection. The timestamp contains the time of the day in NTP [NTP] format. It is assumed that all NACP entities have a clock that is more or less synchronized. NACP entities must not accept messages whose timestamp has a difference of more than 7 seconds to their current clock. If an entity receives a message whose timestamp does not fall into the 7 seconds time frame it must send a correction message to its peer. This way, the peer entity can adjust its timestamps by the specified delta. New messages must always use a timestamp greater than that of the previous messages. 5.1.3. Acknowledgements Requests must always be acknowledged by their corresponding replies. Requests and replies are matched using their ID fields. The ID field of a reply must be an exact copy of the ID field of its corresponding request. 5.1.4. Retransmission Requests must be retransmitted if their matching reply is not received within a certain time. In a retransmission an exact copy of the unacknowledged message must be sent, with the following differences: Lach, Catalina Expires April 2004 [Page 15] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols * The retransmitted message must have a new timestamp, thus counting as a new request. The sender should check the validity of the data contained in the request. If the request is no longer pertinent (for instance, the NAA has decided that the particular MN should switch to a different network) the request should not be retransmitted. * The authentication extension must be recalculated. In addition to retransmission of unacknowledged requests each terminal periodically sends Service Request messages every T time units, even if there is no updated information to report. These periodic messages act as "keep-alive" indicators, assuring the NAA that the terminal is "still there". T must be equal to half the lifetime of the Service Request. The NAA will consider that a Mobile Node is no longer available if it does not receive a Service Request message within the message's lifetime. 5.1.5. Message order A message must not be taken into account if its timestamp is older than that of a previous message of the same type. In this way timestamps are being used to guarantee the correct sequence of messages. 5.2. Generic header and extension format NACP messages consist of a header followed by a variable number of TLV extensions. This section introduces the generic format that all message types and extensions must follow. 5.2.1. Header format NACP messages are UDP messages exchanged between the MN and the NAA. The MN must use its home address in communications with the NAA. The MN listens to messages from the NAA in port 1434, and the NAA listens to messages from the MNs in port 1435. The UDP header is followed by the NACP message header shown in Figure 6: Lach, Catalina Expires April 2004 [Page 16] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |Version|Hdr len| Message length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN's home address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message header data | | ... | . ... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+-+-+-+-+- Figure 6. NACP message header format Message headers contain the following fields: * Type (8 bits): identifies the message type: -Request message types must be numbered between 0 and 63. -Reply message types are numbered between 64 and 127, and must equal the number of their corresponding request plus 64. -Notification message types are numbered between 128 and 191. -Error message types are numbered from 192 to 255. * Version (4 bits): protocol version. It must be set to 1. * Hdr len (4 bits): contains the length of the message header in 4-byte words. Its minimum value is 4, for a header of 16 bytes. Messages which require more than 64 bytes of information should consider the use of extensions (see Section 5.2.2). * Message length (16 bits): contains the total message length in bytes including the extensions, without the UDP and IP headers. * Identification (64 bits): message timestamp, in the format specified in the NTP [NTP] protocol: "NTP timestamps are represented as a 64-bit unsigned fixed-point number, in seconds relative to 0h on 1 January 1900. The integer part is in the first 32 bits and the fraction part in the last 32 bits." Lach, Catalina Expires April 2004 [Page 17] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols If the system cannot provide enough precision to fill all or part of the low order 32 bits (the fraction part of the timestamp), these must be obtained from a good source of randomness. IDs for new messages must be greater than the IDs of previous messages. For requests and notifications, the ID reflects the current system time when the message was sent. For replies, this value is the exact copy of the ID field of the matching request message. In error messages, the low order 32 bits of the ID field are copied from the low order 32 bits of the ID field of the message that caused the error. The 32 high order bits may be copied or changed, depending on the type of error. * MN's home address (32 bits): it is the home address of the MN that sends/receives the message. This field identifies the Mobile Node. Note that it is not necessary to identify the NAA. * Message header data: contains other message information. The format of this information depends on the message type. 5.2.2. Extension format A variable number of extensions can be added to any message after the header. They must follow the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Extension data .... +-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7. NACP message extension format. NACP extensions have the following fields: * Type (8 bits): a number that identifies the extension type. * Length (16 bits): extension length in bytes, including the type and length fields. * Extension data: it carries the extension information. Its format depends on the extension type. Lach, Catalina Expires April 2004 [Page 18] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols 5.3. NACP messages 5.3.1. Service Contract Information Request message * Message category: request (associated reply: Service Contract Information Reply, Section 5.3.2). * Message header format: the same as Figure 6, without any message header data. * Fields: -Type (8 bits): 0. -Version (4 bits): protocol version. It must be set to 1. -Hdr len (4 bits): 4. -Message length (16 bits): 16 + extensions length. -ID (64 bits): message timestamp. -MN's home address (32 bits): home address of the sending MN. * Mandatory extensions: -Authentication extension. 5.3.2. Service Contract Information Reply message * Message category: reply (associated request: Service Contract Information Request, Section 5.3.1). * Message header format: the same as Figure 6, without any message header data. * Fields: -Type (8 bits): 64. -Version (4 bits): protocol version. It must be set to 1. -Hdr len (4 bits): 4. -Message length (16 bits): 16 + extensions length. -ID (64 bits): timestamp of the corresponding Service Contract Information Request message. -MN's home address (32 bits): home address of the receiving MN. * Mandatory extensions: Lach, Catalina Expires April 2004 [Page 19] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols -Service Definition extension: it is used to define the QoS parameters and cost parameters for a service. The Service Contract Information Reply message must contain as many Service Definition extensions as services to which the user is subscribed. -Authentication extension. 5.3.3. Service Request message * Message category: request (associated reply: Service Reply, Section 5.3.4). * Message header format: see Figure 8. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |Version|Hdr len| Message length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN's home address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime |Current network|Q|Reserved = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8. Service Request message format. * Fields: -Type (8 bits): 1. -Version (4 bits): protocol version. It must be set to 1. -Hdr len (4 bits): 5. -Message length (16 bits): 20 + extensions length. -ID (64 bits): message timestamp. -MN's home address (32 bits): home address of the sending MN. -Lifetime (16 bits): time (in seconds) during which the Service Request is valid. When the lifetime expires the NAA must consider that the MN is not present anymore, and that the services it was running have stopped. The MN should send a new Service Request at least when half of the specified Lifetime has elapsed. Lach, Catalina Expires April 2004 [Page 20] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols -Current network (8 bits): ID of the currently selected network in the MN. Note that this message must carry one or more Network Availability extensions that maps each network to a network ID. -Q (1 bit): this bit is reserved for implementation-dependent extensions. For example, the MN sets this bit to 1 if degradation on the service quality, as reported by the applications, occurs, or if it detects the presence of a new access network. In these cases, quality report extensions may be added to the Service Request message. When the NAA receives a Service Request with the Q bit set to 1 it may take corrective actions in order to improve service quality. The NAA will also consider that the content of these quality report extensions serve its needs for quality reporting from that MN and will suppress a Quality Report Request that would otherwise be issued to that MN. -Reserved (7 bits): reserved for future use. Must be 0. * Mandatory extensions: -Service List extension: specifies the list of services currently running on the Mobile Node, or that the user has requested. This extension must be present even if no services are being run. -Network Availability extensions: used to communicate to the NAA the list of currently available networks. Note that there must always be at least one available network (if not it would not be possible to send the Service Request). -Authentication extension. * Non mandatory extensions (if the Q bit is set): -IP report parameters. -WLAN parameters report extension. -GPRS parameters report extension. -DVB-T parameters report extension. 5.3.4. Service Reply message * Message category: reply (associated request: Service Request, Section 5.3.3). * Message header format: see Figure 9. Lach, Catalina Expires April 2004 [Page 21] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |Version|Hdr len| Message length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN's home address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | Reserved = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9. Service Reply message format. * Fields: -Type (8 bits): 65. -Version (4 bits): protocol version. It must be set to 1. -Hdr len (4 bits): 5. -Message length (16 bits): 20 + extensions length. -ID (64 bits): timestamp of the corresponding Service Request message. -MN's home address (32 bits): home address of the receiving MN. -Lifetime (16 bits): time (in seconds) during which the Service Reply is valid. This lifetime could be greater or smaller than the one in the Service Request. The MN must accept the Lifetime specified on the Reply. Note that the MN should upgrade its current Service Request expiration timer by the difference between the lifetime indicated in the Service Request and the one indicated in the Service Reply. -Reserved (16 bits): reserved for future use. Must be 0. * Mandatory extensions: -Service List extension: specifies the list of services that the NAA accepts. All services present in the Service Request must be present in the Reply. The NAA uses this extension to accept or deny each service. If a service that was running previously is denied the MN must stop it. -Preferred Network List extension: it contains the list of networks that the MN should choose. Under normal circumstances, Lach, Catalina Expires April 2004 [Page 22] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols the MN will switch to the first network on the list. Should this network suddenly become unavailable, the MN will then choose the next one on the list and notify the NAA accordingly. For unidirectional networks (e.g. DVB-T) the subsequent preferred network will specify the return path. -Authentication extension. 5.3.5. Quality Report Request message * Message category: request (associated reply: Quality Report Reply, 5.3.6). * Message header format: the same as Figure 6, without any message header data. * Fields: -Type (8 bits): 2. -Version (4 bits): protocol version. It must be set to 1. -Hdr len (4 bits): 4. -Message length (16 bits): 16 + extensions length. -ID (64 bits): message timestamp. -MN's home address (32 bits): home address of the sending MN. * Mandatory extensions: -Authentication extension. 5.3.6. Quality Report Reply message * Message category: reply (associated request: Quality Report Request, Section 5.3.5). * Message header format: the same as Figure 6, without any message header data. * Fields: -Type (8 bits): 66. -Version (4 bits): protocol version. It must be set to 1. -Hdr len (4 bits): 4. -Message length (16 bits): 16 + extensions length. Lach, Catalina Expires April 2004 [Page 23] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols -ID (64 bits): timestamp of the corresponding Quality Report Request message. -MN's home address (32 bits): home address of the receiving MN. * Mandatory extensions: -IP report parameters. -Authentication extension. * Non mandatory extensions: at least one group of: -WLAN parameters report extension and WLAN availability extension. -GPRS parameters report extension and GPRS availability extension. -DVB-T parameters report extension. If one of the network extensions is missing, that means that the network is not present. If the network extension is completed with null parameters, then its statistics report is not applicable for this network. 5.3.7. Handover Required Notification message * Message category: notification. * Message header format: the same as Figure 6, without any message header data. * Fields: -Type (8 bits): 128. -Version (4 bits): protocol version. It must be set to 1. -Hdr len (4 bits): 4. -Message length (16 bits): 16 + extensions length. -ID (64 bits): message timestamp. -MN's home address (32 bits): home address of the sending MN. * Mandatory extensions: -Authentication extension. Lach, Catalina Expires April 2004 [Page 24] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols The NAA sends this message to the MN to force a new Service Request/Reply cycle. This typically happens when the NAA algorithms have decided to move the MN to a different network. A Mobile Node that receives a Handover Required Notification must immediately send a Service Request to the NAA. 5.3.8. Invalid ID message * Message category: error. * Message header format: the same as Figure 6, without any message header data. * Fields: -Type (8 bits): 192. -Version (4 bits): protocol version. It must be set to 1. -Hdr len (4 bits): 4. -Message length (4 bits): 16 + extensions length. -ID (64 bits): the low order 32 bits must be a copy of the low order 32 bits of the message that caused the error. The high order 32 bits must come from the system clock. -MN's home address (32 bits): home address of the receiving MN. * Mandatory extensions: -Authentication extension. This message is sent when a request or a notification with an invalid timestamp is received. A timestamp is considered to be invalid when its difference from the current time is greater than 7 seconds. When a host receives an invalid ID error message it should check if the low order 32 bits of its ID field match the low order 32 bits of the last message it has sent. If they do, then the ID of any new message to the same host must be corrected by the difference of the system's clock and the high order 32 bits of the ID field of the error message. Lach, Catalina Expires April 2004 [Page 25] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols 5.4. NACP Extensions 5.4.1. Authentication extension This special extension must be present in all NACP messages. Its format is shown in Figure 10. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenticator .... +-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10. Authentication extension format. This extension has the following fields: * Type (8 bits): 1. * Length (16 bits): authenticator size + 8. For HMAC-MD5 authentication it is 24 bytes. * Reserved (8 bits): reserved for future use. Must be 0. * Security Parameters Index (SPI) (32 bits): selects a Security Association among the contexts available for the NAA and a particular Mobile Node. * Authenticator: an authenticator value computed using the algorithm determined by the SPI and the terminal Home Address. The authenticator must protect: -all fields in the message header; -all previous extensions; -the type, length and SPI fields of the authentication extension. As indicated in Section 5.1.1, the authentication extension must always be the last extension of a NACP message. The authentication algorithm and key may be the same as the authentication algorithm and key used for Mobile IP registration. Thus all NACP entities must at least support HMAC-MD5 authentication [HMAC]. Lach, Catalina Expires April 2004 [Page 26] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols 5.4.2. Service Definition extension This extension is used in Service Contract Information Replies to inform the Mobile Node of the services to which the user is subscribed. Figure 11 shows the extension format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |S|Reserved = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved = 0 | Service ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Average Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Per | One Way Delay (OWD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11. Service Definition extension format. This extension has the following fields: * Type (8 bits): 2. * Length (16 bits): 20. * S bit (1 bit): if set, the user is subscribed to the given service. If not set, the service is available in the system, but the user is not subscribed to it. Services to which the user is not subscribed are provided for information purposes. If the Mobile Node tries to use a service to which the user is not subscribed, its request will be rejected. * Reserved (23 bits): reserved for future use. Must be 0. * Service ID (16 bits): identifies this service uniquely in the system. Service ID numbers must be greater than 0. * Average Rate (32 bits): the average bit rate of the service offered. * Per (8 bits): percentile, the negative decimal exponent indicating the percentile of the packets that may violate the One Way Delay specification. For example, for percentile = 2, then the probability of packets experiencing a delay greater than the one specified in the One Way Delay field, is smaller than or equal to 10-2. If the value of this field is zero, then the One Way Delay specification is taken as a mean value, rather than a percentile-specified threshold. Lach, Catalina Expires April 2004 [Page 27] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols * One Way Delay [OWD] (24 bits): the one way queuing delay in milliseconds experienced by packets when passing through the wireless infrastructure in use. * Cost (32 bits): specifies the cost of the service. It is provided for informational purposes only. 5.4.3. Network Availability extensions The purpose of this group of extension is to inform the NAA that a particular network is available in the MN. The extension must carry the information regarding the network configuration, such as the assigned IP address that has been assigned to the corresponding interface in the MN. A different extension must be defined per network type. The following sections define the availability extensions for the particular cases of GPRS, IEEE802.11b WLAN and DVB-T. Other extensions may be defined to extend the protocol for other network types. 5.4.3.1. GPRS Availability extension The MN uses this extension in Service Requests to inform about the availability of a GPRS network. Figure 12 shows the extension format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cell ID | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Location Area ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Assigned IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12. GPRS Availability extension format. This extension has the following fields: * Type (8 bits): 3. * Length (16 bits): 16. * Index (8 bits): network index assigned to this network in the MN. Network indexes must be greater than 0. * Cell ID (16 bits): ID of the current cell to which the MN is attached. * Location Area ID (48 bits): ID of the current location area. Lach, Catalina Expires April 2004 [Page 28] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols * Assigned IP address (32 bits): IP address of this interface in the Mobile Node. 5.4.3.2. WLAN Availability extension The MN uses this extension in Service Requests to inform the NAA about the availability of a WLAN network. Figure 13 shows the extension format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Assigned IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BSSID (MAC address of access point) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ESSID length | ESSID ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... ESSID ... +-+-+-+-+-+-+-+-+- Figure 13. WLAN Availability extension format. This extension has the following fields: * Type (8 bits): 4. * Length (16 bits): 15 + ESSID length + 1. * Index (8 bits): network index assigned to this network in the MN. Network indexes must be greater than 0. * Assigned IP address (32 bits): IP address of this interface in the MN. * BSSID (48 bits): IEEE802.11b Base Station ID, which normally corresponds to the MAC address of the current access point. * ESSID length (8 bits): size of the ESSID in bytes, not counting the terminating NULL character. * ESSID: a NULL terminated character string specifying the ESSID of the detected network. 5.4.3.3. DVB-T Availability extension The MN uses this extension in Service Requests to inform the NAA about the availability of a DVB-T network. Figure 14 shows the extension format. Lach, Catalina Expires April 2004 [Page 29] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Assigned IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14. DVB-T Availability extension format. This extension has the following fields: * Type (8 bits): 5. * Length (16 bits): 8 * Index (8 bits): network index assigned to this network in the MN. Network indexes must be greater than 0. * Assigned IP address (32 bits): IP address of this interface in the MN. 5.4.4. Service List extension The MN uses this extension in Service Requests to inform the NAA of the services that are currently running or that have been requested by the users. The NAA uses this extension in Service Replies to accept or reject the services requested by the MN. Figure 15 shows the extension format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service ID | Instance ID | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Figure 15. Service List extension format. This extension has the following fields: * Type (8 bits): 6. * Length (16 bits): 4 + 4 x number of (Service ID, Instance ID, Status) triplets. * Reserved (8 bits): reserved for future use. Must be 0. Lach, Catalina Expires April 2004 [Page 30] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols * (Service ID, Instance ID, Status) list: it specifies each service and its status: -Service ID (16 bits): ID of the service, greater than 0. -Instance ID (8 bits): an integer greater than 0 used to differentiate instances of the same service. For instance: if a MN is receiving two high quality video streams (that is, twice the same service), it will assign two different Instance IDs to be able to tell the difference between them. -Status (8 bits): specifies the status of this service. Its possible values are the following: o 1 = service has been requested or is being run. This code is only used in Service Requests. o 2 = service accepted. This code is only used in Service Replies. o 3 = service refused. This code is only used in Service Replies. Note that it is possible to include in the Service Request message several times the same Instance ID for different Service IDs. This is used to inform the NAA of the different services that are acceptable for a particular service instance. For each service instance the NAA decides which of the requested services can be used at the given moment (based on the network conditions, for instance), and includes only the selected Service ID in the Service Reply message. Thus the Service Replies contain only one Service ID per Instance ID. 5.4.5. Preferred Network List extension The NAA appends this extension to Service Replies to select a network for the MN. Its format is shown in Figure 16. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Network index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Index | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 16. Preferred Network List extension format. Lach, Catalina Expires April 2004 [Page 31] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols This extension has the following fields: * Type (8 bits): 7. * Length (16 bits): 3 + number of networks in the list * Network index list (8 bits per network index): list of the indexes of the preferred networks, in order. The MN must select the first network on the list. If it becomes unavailable or an error occurs when performing a Mobile IP registration with this network, the MN should select the next network on the list. Network indexes are always greater than 0. If a unidirectional link network is specified (such as DVB-T) the next network index in the list must be used for the return path. 5.4.6. IP Parameters Report extension The MN uses this extension in Quality Report Requests to inform the NAA of the values of the IP level aggregated related statistical parameters. Its format is shown in Figure 17. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 17. IP parameters report extension This extension has the following fields: * Type (8 bits): 8. * Length (16 bits): 12 bytes. * Reserved (8 bits): reserved for future use. Must be 0. * Upstream rate (32 bits): terminal transmitted rate in kbps. * Downstream rate (32 bits): terminal received rate in kbps. These rates should be measured and averaged over an appropriate time period. The exact mechanism for averaging is transparent to the protocol itself. Lach, Catalina Expires April 2004 [Page 32] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols 5.4.7. Network Parameters Report extensions This groups of extensions are used to report network parameters for each of the available networks in the MN on Quality Report Replies messages. A different extension is used for each possible network type. The following sections describe the Network Parameter Report extensions for the particular cases of GPRS, IEEE802.11b WLAN and DVB-T. Other extensions could be defined for other network types. 5.4.7.1. GPRS Parameters Report extension The MN uses this extension in Quality Report Replies to inform the NAA of the values of the GPRS parameters. Its format is shown in Figure 18. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Network index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MSCoT | Received power | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 18. GPRS Parameters Report extension This extension has the following fields: * Type (8 bits): 10. * Length (16 bits): 8 bytes. * Network index (8 bits): network index assigned to this network in the MN. Network indexes must be greater than 0 (same as the network availability extensions). * MSCoT (16 bits): Multislot class of terminal. * Received power (16 bits): Received power (dbm). Note that not all drivers might be capable of retrieving all these values. If not applicable, such extensions may be omitted or parameter values may be invalid. 5.4.7.2. WLAN Parameters Report extension The MN uses this extension in Quality Report Replies to inform the NAA, of the values of the WLAN statistical parameters. Figure 18 shows the extension format. Lach, Catalina Expires April 2004 [Page 33] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Network index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bit rate | Signal level | Noise level | Link quality | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 19. WLAN parameters report extension This extension has the following fields: * Type (8 bits): 9. * Length (16 bits): 8 bytes. * Network index (8 bits): network index assigned to this network in the MN. Network indexes must be greater than 0 (same as the network availability extensions). * Bit rate (8 bits): the nominal WLAN bit rate in Mbps (1,2,5 or 11 Mbps). * Singal level (8 bits): dbm. * Noise level (8 bits): dbm. * Link quality (8 bits) 5.4.7.3. DVB-T Parameters Report extension The MN uses this extension in Quality Report Replies to inform the NAA, of the values of the DVB-T parameters. Figure 20 shows the extension format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Network index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bit Error Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal strength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|Y|V|C|L|I|S|P| Reserved = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 20. DVB-T Parameters Report extension * Type (8 bits): 11. * Length (16 bits): 16. Lach, Catalina Expires April 2004 [Page 34] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols * Network index (8 bits): network index assigned to this network in the MN. Network indexes must be greater than 0 (same as the network availability extensions). * Bit Error Rate (32 bits). * Signal Strength (32 bits). * Receiver flags (8 bits): various flags from the DVB-T receiver: -P: power. -S: signal. -I: spectrum inversion. -L: lock. -C: carrier present. -V: Viterbi. -Y: sync. -T: tuner has lock. Note that in some cases a particular driver might not be able to retrieve all these settings. As in the case of GPRS the MN might choose not to include the DVB-T Parameters Report extension in such a case. 6. References [MIP4] "IP Mobility Support for IPv4", C. Perkins (Editor), RFC 3344, August 2003. [MIP6] "Mobility Support in IPv6", D. Johnson, C. Perkins, and Jari Arkko, draft-ietf-mobileip-ipv6-21.txt, work in progress, February 2003. [TERM] "Mobility Related Terminology", J. Manner, M. Kojo, draft-ietf-seamoby-mobility-terminology-01.txt, work in progress, November 2002. [NTP] Mills D., "Network Time Protocol (Version 3). Specification, Implementation." RFC 1305, March 1992. [HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. Lach, Catalina Expires April 2004 [Page 35] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols [KWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 7. Acknowledgments This work has been performed in the framework of the IST project IST-2001-33093 CREDO, which is partly funded by the European Union. The CREDO consortium consists of Motorola Labs - Paris (project coordinator), NCSR "Demokritos" (technical coordinator), IBM Greece, National Technical University of Athens (NTUA), Motorola GSG Italy, Thales Broadcast & Multimedia, Vodafone Greece. We would like to acknowledge the work of the people who have participated on the elaboration, development and testing of the Network Access Co-ordination Protocol: * Panagiotis Demestichas (National Technical Univerisy of Athens), * Kimon Kontovasilis (NCSR "Demokritos"), * Artemis Koutsorodi (National Technical Univerisy of Athens), * Pierre Roux (Motorola Labs - Paris), * Panagiotis Stathopoulos (National Technical Univerisy of Athens), * Vera Stavroulaki (National Technical Univerisy of Athens). We would also like to thank Alexandru Petrescu for his advices and help in writing this document. 8. Author's Addresses Hong-Yon Lach Motorola Labs - Paris Parc Les Algorithmes - Saint Aubin 91193 Gif-sur-Yvette Cedex FRANCE Email: hong-yon.lach@motorola.com Miguel Catalina-Gallego Motorola Labs - Paris Parc Les Algorithmes - Saint Aubin 91193 Gif-sur-Yvette Cedex FRANCE Email: miguel.catalina@motorola.com Lach, Catalina Expires April 2004 [Page 36] Internet Draft Network Access Co-ordination October 2003 to Complement IP Mobility Protocols Copyright Notice Copyright (C) The Internet Society (2002). 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 organizations, 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 languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Funding for the RFC editor function is currently provided by the Internet Society. Lach, Catalina Expires April 2004 [Page 37]