NEMO Working Group Mazen TLAIS Internet Draft Houda LABIOD Expires: May 8, 2005 Nadia BOUKHATEM ENST - Paris November 9, 2004 resource reservation for NEMO networks Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3667. 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 Degradation or forced service termination may occur because of frequent handoffs that may occur within NEMO networks. This paper presents a resource reservation scheme aiming at supporting quality of service guaranty. We focus on a reservation protocol adapted to NEMO specifications. For doing so, we use a generic signaling protocol that may exploit advantages of both reservation protocols; IntServ and DiffServ. Tlais, et al. Expires May 2005 [Page 1] Internet-Draft resource reservation November 2004 TABLE OF CONTENTS 1. Introduction.................................................. 3 2. Terminology................................................... 5 3. Description of the NEMOR protocol............................. 6 3.1. Generic signaling protocol............................... 6 3.2. Resource reservation procedures.......................... 7 3.3. MR-HA resource reservation............................... 9 3.4. HA-CN resource reservation...............................10 3.5. MR-CNs resource reservation..............................11 3.6. Resource reservation for new mobile nodes................12 3.7. Resource reservation in handoff state....................13 4. Reservation for nested mobile network.........................13 5. Example of the NEMOR protocol.................................15 6. Security considerations.......................................17 7. References....................................................18 8. Authors' addresses............................................19 Tlais, et al. Expires May 2005 [Page 2] Internet-Draft resource reservation November 2004 1. Introduction The primary goal of the NEMO working group is to specify a solution to provide continuous Internet connectivity to nodes in a mobile network at all times while the mobile network changes its point of attachment [1]. NEMO networks may lead to frequent handoffs while mobile networks move among access routers (ARs) remaining connected to the fixed network. Quality of service (QoS) degradation or forced service termination may occur when there are insufficient resources required for handoff requests. During the handoff process, we address two special cases. The first one concerns the resource reservation, in fact resources must be reserved and allocated to the mobile network as quickly as possible to avoid decreasing QoS. The second one deals with the situation when a new mobile router or mobile node (MN) appears, necessary resources with appropriate QoS must be provided. A mobile network is composed by one or more IP-subnets and is viewed as a single unit. It is connected to the Internet by means of mobile routers (MRs). Network mobility (NEMO) arises when a mobile router (MR) connecting an entire network to the Internet dynamically changes its point of attachment to the Internet. Nodes behind the MR primarily comprise fixed nodes, and mobile nodes. Mobile networks are typically connected to fixed networks by wireless links. ____ | | | CN | |____| ___|____________________ | | | | | Internet | | | |________________________| __|_ __|_ | | Access | | | AR | Router | AR | |____| |____| ______|__ foreign __|_____________ home link __|_ link | | | MR | Mobile Router |____| _________|_______ NEMO-link __|__ __|__ | | | | | MNN | | MNN | Mobile Network Nodes |_____| |_____| Figure 1: NEMO architecture Tlais, et al. Expires May 2005 [Page 3] Internet-Draft resource reservation November 2004 A mobile network, at home or away from home, may itself be visited by mobile nodes and other mobile networks. Such scenarios may lead to an increasely number of internal nodes with densely connected nodes. We can quote the example of users in a train who need to interact with servers in Internet. Mobile network will have to provide support for different applications performed by the users (real-time, non-real-time,...). Each user may run an application that requires an end-to-end provision of suitable quality of service (QoS). An application may require low-delay and low-jitter for customers who are willing to pay a premium price to run real-time applications. Another application may require predictable services for customers who are willing to pay for reliability. This end-to-end QoS can be achieved and guaranteed through proper configuration, reservation and allocation of corresponding resources. Provision of QoS tends to become complicated due to the large number of users and the train's mobility. If we assume that each user in the train launch a separate resource reservation operation to ensure his QoS with appropriate flow characteristics, this increases the control overhead on the entire network. Our work focuses on a particular resource reservation protocol taking into account the characteristics of NEMO networks based on the NEMO basic support specification [2]. Our protocol handles resource reservation in a NEMO context. Necessary resources are provided in the case of handoff and arrival of new mobile nodes aiming at optimizing of network's performances. We called this protocol, NEMO Reservation (NEMOR). Integrated Services (IntServ) and Differentiated Services (DiffServ), proposed by the Internet Engineering Task Force (IETF), are two of the current approaches for improving quality of service (QoS) guarantees in the Internet. -RSVP is a resource reservation setup protocol designed for an IntServ model; before data is transmitted, applications must set up paths and reserve resources in all nodes along the path. This reservation is executed hop by hop in each intermediate router [3]. RSVP however, requires the core routers to remember the state of a large number of connections giving rise to scalability issues in the core of the network. It is therefore suitable when the number of connections is limited. Tlais, et al. Expires May 2005 [Page 4] Internet-Draft resource reservation November 2004 -The DiffServ model is currently being standardized to provide service guarantees to aggregate traffic instead of individual connections used in RSVP. The model does not require significant changes to the existing Internet infrastructure or protocol. We create on each router queues of various priorities which correspond to traffic classes. The DiffServ model marks each packet with a code to identify and arrange flows in a particular queue according to the flow's priority [4]. DiffServ does not suffer from scalability issues. The need for aggregation because of the large number of nodes in a NEMO network and the necessity to provide quality of service for different applications lead us to propose an approach that combines advantages of IntServ and DiffServ protocols to guarantee QoS for NEMO networks. For doing so, we need to use a new signaling protocol that must be generic to support both IntServ and DiffServ specifications. 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 [5]. Network Mobility related terminology is defined in [6] and [7]. In addition this draft defines the following terms: active access router: An access router is called active AR, if the MR uses this AR to send its traffic. flow: a stream of packets from sender to receiver. Each flow is distinguished by some flow identifier (priority). Aggregated flow: a collection of packets with the same priority crossing a link in a particular direction. Virtual tunnel: after aggregating flows, the mobile router transmits the flows in the virtual tunnel constructed by the resource reservation signaling. NSIS protocol: Next Step In Signaling, a generic signaling protocol. NSIS Signaling Layer Protocol (NSLP): generic term for an NSIS protocol component that supports a specific signaling application. For the purpose of this document, we use the term 'NSLP' to refer generically to any protocol within the signaling application layer. Tlais, et al. Expires May 2005 [Page 5] Internet-Draft resource reservation November 2004 NSIS Transport Layer Protocol (NTLP): placeholder name for the NSIS protocol component that will support lower layer (signaling application independent) functions. For the purpose of this document, we use the term 'NTLP' to refer to the component that will be used in the transport layer. NSIS Entity (NE): the function within a node that implements an NSIS Protocol. 3. Description of the NEMOR protocol 3.1. Generic signaling protocol The working group NSIS (Next Step In Signaling [8]) is created to define a new and generic signaling protocol. The intention of NSIS is to re-use, where appropriate, the protocol mechanisms of RSVP while at the same time simplifying it and applying a more general signaling model [9]. The NSIS protocol suite is structured into two layers: -NTLP: NSIS Transport Layer Protocol is responsible for moving signaling messages around and should be independent of any particular signaling application. -NSLP: NSIS Signaling Layer Protocol is the upper layer that contains functionality such as message formats and sequences, specific to a particular signaling application. R1 R2 R3 R4 +------+ +------+ +------+ +------+ | NE | | NE | | NE | | NE | |+----+| |+----+| |+----+| |+----+| ||NSLP|| ||NSLP|| ||NSLP|| ||NSLP|| |+----+| |+----+| |+----+| |+----+| |+----+| |+----+| |+----+| |+----+| ====>||NTLP||===>||NTLP||===>||NTLP||===>||NTLP||===> |+----+| |+----+| |+----+| |+----+| +------+ +------+ +------+ +------+ ^ ^ ^ ^ | | | | (-->: Established state) (==>: Message direction) (Ri: intermediate router) (NE: NSIS Entity) Figure 2: Protocol stack for NSIS Figure 2 states the protocol stack of the NSIS signaling, intermediate routers must support NTLP layer and may support NSLP layer according to needs. Tlais, et al. Expires May 2005 [Page 6] Internet-Draft resource reservation November 2004 [9] proposes an NTLP layer to support the RSVP signaling. Moreover, [10] and [11] propose NSLP layers to support respectively RSVP and DiffServ models. In our NEMOR protocol we assume that the NTLP layer supports the RSVP signaling to reserve resources for aggregated flows. The NSLP layer supports added information to distinguish between different aggregated flows. Therefore, we define two NSLP objects: -A DiffServ-NSLP object is responsible of configuring queues, in the intermediate routers along the way to the home agent, to support aggregated flows. -An RSVP-NSLP object that configures the home agent to disaggregate flows and launch reservations towards different destinations. Recall that each message NSIS may contain multiple NSLP objects according to the application's needs, but one NTLP. 3.2. Resource reservation procedures NEMO basic support proposes a bi-directional tunnel between the mobile router and its home agent. This tunnel is set up when the mobile router sends a successful Binding Update (BU) to its home agent, informing the home agent of its current point of attachment. All traffic between nodes in the mobile network and Correspondent Nodes (CN) passes through the home agent [2]. The route between MR and HA is transparent for the different destinations (correspondent nodes), consequently this part of the route is not affected by the apparit ion of novel nodes requesting new correspondent nodes (see Figure 3). Moreover, the route between CN and HA is transparent for the AR serving the mobile networks, consequently this part of the route is not affected by the handoff and the mobility of the NEMO networks. Figure 4 illustrates the displacement of the mobile network from the coverage of the home agent to the neighborhood of another access router. We see that the route between the correspondent node and the home agent is not affected by the motion. Tlais, et al. Expires May 2005 [Page 7] Internet-Draft resource reservation November 2004 +-----------+ Correspondent node1 nnnnnnnnnnnnnnnnnnnnnnn | | Correspondent node2 nnnnnnnnnnnnnnnnnnnnnnn | | . | Home Agent| . | | Correspondent nodei nnnnnnnnnnnnnnnnnnnnnnn | | +-----------+ # c # # c # # c # # c # # c # # c # +-----------+ | Mobile | | Router | +-----------+ | ====Mobile Network======= # :== Tunnel n :== Non-common route c :== common route Figure 3: MR-HA reservation is transparent for the destinations ########### Correspondent cccccccccccc Home Agent nnnnnnnnnnn Access router n ########### # n # n # n # n # n # n # n # n # n # n # n # +------+ |Mobile| => |Router| +------+ | ====Mobile Network======= # :== Tunnel n :== Non-common route c :== common route Figure 4: HA-CN reservation is transparent for the ARs Tlais, et al. Expires May 2005 [Page 8] Internet-Draft resource reservation November 2004 Therefore, we distinguish in our resource reservation protocol two main phases of reservation. The first phase is located between the mobile router and the home agent. The second phase is executed between the home agent and the different correspondent nodes. 3.3. MR-HA resource reservation The base of our idea is to create a virtual RSVP resource reservation tunnel with the suitable QoS between the mobile router and the home agent. The mobile router will involve the construction of this tunnel with sufficient resources to support all the mobile nodes in the mobile network. Once the virtual tunnel is constructed, the mobile router aggregates flows and marks outer packets with appropriate priorities. Then, it sends the packets through the virtual tunnel. Let us note that the mobile router can at any time renegotiate to extend or reduce allocated resources for the virtual tunnel according to the executed applications and the number of mobile nodes attached to the mobile network. This part of our resource reservation protocol is common for all the mobile nodes in a mobile network. When the mobile router is active in a given area, it sends a request message for resource reservation (RRRM, Resource Reservation Request Message) to the home agent. This message must be treated in each intermediate router (Figure 5) along the path to the home agent and must contain: -an NTLP to configure the quality of service of the virtual tunnel in all routers in the path to the home agent. NTLP uses RSVP policies, it reserves resources for the aggregated flows belonging to all the mobile nodes in the mobile network. We called this tunnel a virtual RSVP tunnel (Figure 6). -a DiffServ-NSLP object to configure each intermediate router to correctly insert the aggregated flows in the queues according to the flow's priority. Receiving aggregated flows, queue selector in the intermediate router must put each flow in the corresponding queue. Then the scheduler sends the flows according to their priorities. DiffServ-NSLP uses DiffServ policies (Figure 7). -an RSVP-NSLP object that contains the destinations' addresses and the desired quality of services for all correspondent nodes. This object is used to constitute the resource reservation messages for the second part of the route (home agent-correspondent node). RSVP-NSLP uses RSVP policies (Figure 8). Tlais, et al. Expires May 2005 [Page 9] Internet-Draft resource reservation November 2004 RRRM RRRM RRRM RRRM +---+ -----> +---+ -----> +---+ -----> +---+ -----> +---+ |MR |--------|R1 |--------|R2 |--------|R3 |-- .... --|HA | +---+ +---+ +---+ +---+ +---+ Figure 5: MR-HA resource reservation _____ _____ | | ########################################## | | | MR | Aggregated flows | HA | |_____| ########################################## |_____| Figure 6: virtual RSVP tunnel (NTLP-RSVP) ____________________________ | ---------------------+ | | Queue for priority 1 | | | ---------------------+ | +--------------+ | ---------------------+ | +---------+ |Queue selector| => | Queue for priority 2 | | => |Scheduler| +--------------+ | ---------------------+ | +---------+ | . | | . | | ---------------------+ | | Queue for priority i | | | ---------------------+ | |____________________________| Figure 7: Aggregated flows behavior in each intermediate router (DiffServ-NSLP) Queue selector: To disaggregate the flows and arrange the packets in the queues according to their priorities. Scheduler: To re-aggregate flows and send packets through the virtual tunnel according to their priorities. 3.4. HA-CN resource reservation Upon receiving resource reservation request message (RRRM) the home agent must reserve necessary resources for the aggregated flows. Then it must launch resource reservation protocol to each correspondent node. The destination address and the desired QoS of each correspondent node are in the RSVP-NSLP object. Tlais, et al. Expires May 2005 [Page 10] Internet-Draft resource reservation November 2004 The RRRM message emitted by the home age nt to each correspondent node must contain an NTLP to configure the quality of service in all routers in the path to the correspondent node (Figure 8). NTLP uses RSVP policies. +------+ RRRM RRRM RRRM RRRM | | -----> +---+ -----> +----+ -----> +----+ -----> +---+ | |--------|Ri |--------|Ri+1|--------|Ri+2|-- .... --|CN1| | | +---+ +----+ +----+ +---+ | HA | | | RRRM RRRM RRRM RRRM | | -----> +---+ -----> +----+ -----> +----+ -----> +---+ | |--------|Rj |--------|Rj+1|--------|Rj+2|-- .... --|CN2| +------+ +---+ +----+ +----+ +---+ Figure 8: HA-CN resource reservation 3.5. MR-CNs resource reservation Figures 9 and 10 illustrate the couple steps in our resource reservation protocol for mobile networks. This mechanism is initiated by the mobile router. Step 1: Figures 5 and 9 show a diagram of our signaling configuration step 1. A resource reservation signaling request is sent from an application in the sender (MR) to the home agent (HA) via routers R1 (AR), R2 and R3. MR R1 R2 R3... HA | | | | | | RRRM | RRRM | RRRM | RRRM | |--------------->|--------------->|--------------->|...--------------->| |(NTLP + |(NTLP + |(NTLP + | (NTLP + | |DiffServ-NSLP + |DiffServ-NSLP + |DiffServ-NSLP + | DiffServ-NSLP + | |RSVP-NSLP) |RSVP-NSLP) |RSVP-NSLP) | RSVP-NSLP) | | | | | | Figure 9: MR-HA resource reservation Tlais, et al. Expires May 2005 [Page 11] Internet-Draft resource reservation November 2004 Step 2: Figures 8 and 10 show a diagram of our signaling configuration step 2. Upon receiving RRRM message, the home agent uses the RSVP-NSLP object to construct a reservation request to each correspondent node; via routers Ri, Ri+1 and Ri+2 for CN1, and via Rj, Rj+1 and Rj+2 for CN2. HA Ri Ri+1 Ri+2 ... CN1 | | | | | | RRRM | RRRM | RRRM | RRRM | |---------->|---------->|---------->| ... ---------->| | (NTLP) | (NTLP) | (NTLP) | (NTLP) | | | | | | | | | Rj Rj+1 Rj+2 ... CN2 | | | | | | RRRM | RRRM | RRRM | RRRM | |---------->|---------->|---------->| ... ---------->| | (NTLP) | (NTLP) | (NTLP) | (NTLP) | | | | | | Figure 10: HA-CNs resource reservation 3.6. Resource reservation for new mobile nodes When a new mobile node appears in the neighborhood of the mobile router, it will send an RRRM message to the mobile router. This message must contain the correspondent node address and the desired quality of service in the NTLP object. The mobile router encapsulates this packet and sends it to the home agent with high priority. Intermediate routers will simply route the packet as quickly as possible because of its high priority and respecting the virtual RSVP tunnel rate. Upon receiving encapsulated RRRM message, the home agent launches RSVP resource reservation for the correspondent node with appropriate quality of service (Figure 11). MN MR HA Rk Rk+1 ... CN | | | | | | | RRRM | encapsulated (RRRM) | RRRM | RRRM | RRRM | |------>|--------------------->|----->|------>| ...-------------->| |(NTLP) | (high priority) |(NTLP)|(NTLP) | (NTLP) | | | | | | | Figure 11: Resource reservation for new mobile nodes Tlais, et al. Expires May 2005 [Page 12] Internet-Draft resource reservation November 2004 3.7. Resource reservation in handoff state When a mobile network needs to perform handoff and changes its active access router. The mobile router does not have to include the RSVP-NSLP object in the RRRM message because the routes between the home agent and the correspondent nodes are not affected by the mobility. The mobile router needs only to reconfigure the virtual RSVP tunnel with the home agent (Figure 12). So, the RRRM message contains only a DiffServ-NSLP object. MR R1 R2 R3 ... HA | | | | | | RRRM | RRRM | RRRM | RRRM | |------------->|--------------|------------->| ...------------->| |(NTLP + |(NTLP + |(NTLP + | (NTLP + | |DiffServ-NSLP)|DiffServ-NSLP)|DiffServ-NSLP)| DiffServ-NSLP)| | | | | | Figure 12: Resource reservation in handoff state 4. Reservation for nested mobile network We also focus on NEMO nested architectures. This section covers the case where one mobile network is within another mobile network. For example, a car which contains a mobile network moves into the ferry which has another mobile network. The nested mobile network is illustrated in Figure 13. When a new mobile router (MR2) appears in the neighborhood of the mobile router 1 (MR1), MR2 will send an RRRM message to MR1. This message must contain NTLP and RSVP-NSLP object. MR1 encapsulates this packet and sends it to its home agent HA-MR1 with high priority. Intermediate routers will simply route the packet as quickly as possible because of its high priority. HA-MR1 decapsulates received RRRM message and launches the construction of a virtual RSVP tunnel to the home agent of MR2 (HA-MR2). Upon receiving resource reservation request message (RRRM), HA-MR2 must launch resource reservation protocol to each new correspondent node (Figure 14). Tlais, et al. Expires May 2005 [Page 13] Internet-Draft resource reservation November 2004 ____ | | | CN | |____| ___|____________________ | | | | | Internet | | | |________________________| __|_ __|_ | | Access | | | AR | Router | AR | |____| |____| ______|__ foreign __|_____________ home link __|__ link | | | MR1 | |_____| _________|_____________________ __|__ __|__ __|__ | | | | | | | MNN | | MNN | | MR2 | |_____| |_____| |_____| ______|_______ __|__ __|__ | | | | | MNN | | MNN | |_____| |_____| Figure 13: Nested NEMO architecture MR2 MR1 HA-MR1 ... HA-MR2 ... CN | | | | | | | | | | | RRRM |encapsulated (RRRM)| RRRM | RRRM | |--------------->|------------------>|...--------------->| ...----->| |(NTLP + | (high priority) | (NTLP + | (NTLP)| |DiffServ-NSLP + | | DiffServ-NSLP + | | |RSVP-NSLP) | | RSVP-NSLP) | | | | | | | Figure 14: Resource reservation for nested mobile network Tlais, et al. Expires May 2005 [Page 14] Internet-Draft resource reservation November 2004 5. Example of the NEMOR protocol This section gives an example to illustrate our NEMOR protocol using a mobile router and two mobile network nodes (see Figure 15). Intermediate routers are presented in Figure 16. ____ ____ | | | | | CN1| | CN2| |____| |____| ___|_____________|______ _______ | | | | | |-| HA-MR | | Internet | |_______| | | |________________________| __|_ | | | AR | |____| ______|__ foreign __|_ link | | | MR | |____| ______|______________ ___|__ ___|__ | | | | | MNN1 | | MNN2 | |______| |______| HA-MR : The home agent of MR. Figure 15: Mobile router attached to foreign link ____ ____ ____ ____ ____ | | | | | | | | | | |MNN1|-----| | ____ ____ | |-----| R2 |-----|CN1 | |____| | | | | | | | | |____| |____| ____ | MR |-----| AR |-----| R1 |-----|HA- | ____ ____ | | | | |____| |____| | MR | | | | | |MNN2|-----| | | |-----| R3 |-----|CN2 | |____| |____| |____| |____| |____| Figure 16: detailed route to correspondent nodes Tlais, et al. Expires May 2005 [Page 15] Internet-Draft resource reservation November 2004 First, the mobile router constructs a virtual RSVP tunnel as described in section 3 (see Figure 17). _____ _______ | | ########################################## | | | MR | Aggregated flows | HA-MR | |_____| ########################################## |_______| Figure 17: virtual RSVP tunnel Consider the case where MNN1 and MNN2 belonging to the mobile network send respectively packets to correspondent nodes CN1 and CN2. MNN1 runs a real time application and MNN2 runs a non real-time application. The mobile router encapsulates each packet, marks it with appropriate priority according to the application's need; real time application's packets marked with high priority and non real time application's packets marked with low priority. Then, the mobile router sends the aggregated packets to the access router. The queue selector in the access router puts the real-time application packets in the queue for high packets' priority and the non real time application packets in the queue for low packets' priority. Then the scheduler will process the queues according to their priorities as quickly as possible respecting the virtual RSVP tunnel rate. In this way, real-time application packets will be processed more quickly than non real-time application packets (see Figure 18). _________________________ | ---------------------+ | | Queue for real time | | | application | | | ---------------------+ | +--------------+ | ---------------------+ | +---------+ |Queue selector|=>| Queue for non real | |=>|Scheduler| +--------------+ | time application | | +---------+ | ---------------------+ | |_________________________| Figure 18: Queues' behavior in each intermediate router When the router R1 receives the packets, it will behave like the access router and sends the packets according to their priorities as quickly as possible respecting the virtual RSVP tunnel rate. Tlais, et al. Expires May 2005 [Page 16] Internet-Draft resource reservation November 2004 Upon receiving encapsulated packets, the queue selector of the mobile router's home agent (HA-MR) puts the packets in the queues, then the scheduler decapsulates the packets and sends each packet to its next hop. The next hop of the packets destinated to CN1 is R2. For those destinated to CN2 the next hop is R3. R2 and R3 do not have any DiffServ behavior; there is not any queue and priority support. On the other hand, R2 and R3 must provide negotiated RSVP quality of service. Finally, packets are received by correspondent nodes. Let us note that our draft does not specify an inter ARs protocol to reserve resources while the mobile router moves between ARs. [12] presents a possible scenario of an intelligent element contribution to reserve resources for node when performing handover. 6. Security considerations This draft does not discuss any security considerations related to our NEMOR protocol. They will be considered in a separate draft. Tlais, et al. Expires May 2005 [Page 17] Internet-Draft resource reservation November 2004 7. References [1] T. Ernst. "Network Mobility Support Goals and Requirements". Internet Draft, IETF. draft-ietf-nemo-requirements-02.txt (work in progress). February 2004. [2] V. Devarapalli, "Nemo Basic Support Protocol", draft-ietf-nemo- basic-support-02.txt (work in progress). December 2003. [3] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [4] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] J. Manner and M. Kojo. "Mobility Related Terminology". Internet Draft, IETF. draft-ietf-seamoby-mobility-terminology-05.txt (work in progress). November 2003. [7] T. Ernst, and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-01.txt (work in progress). February 2004. [8] http://www.ietf.org/html.charters/nsis-charter.html. [9] T. Luu, N. Boukhatem, G. Pujolle et al, "NSIS Transport Layer Protocol, Considerations and Implementation". Internet Draft, IETF. draft-luu-ntlp-con-imp-01.txt (work in progress). May 2004 [10] S. Van den Bos ch, G. Karagiannis, A. McDonald, "NSLP for Quality-of-Service signalling". Internet Draft. draft-ietf- nsis-qos-nslp-04.txt (work in progress). July 19, 2004. [11] Bader, A., Westberg, L., Karagiannis, G., Kappler, C. and T. Phelan, "Resource Management in Diffserv (RMD) Framework", draft-bader-nsis-rmd-diffserv-qsm-00.txt (work in progress). July 2004. [12] Mazen Tlais, Houda Labiod, "Handoff and Resource Management for Multi-homed Networks". Internet Draft, IETF. draft-tlais-nemo- handoff-resource-management-00.txt (work in progress). August 2004. Tlais, et al. Expires May 2005 [Page 18] Internet-Draft resource reservation November 2004 8. Authors' addresses Questions about this memo can be directed to: Mazen TLAIS Ecole Nationale Superieure des Telecommunications (ENST) GET/ENST/INFRES Department, LTCI-UMR 5141 CNRS 46 rue Barrault - 75634 Paris Cedex 13 - France E-mail: tlais@enst.fr Houda LABIOD Ecole Nationale Superieure des Telecommunications (ENST) GET/ENST/INFRES Department, 46 rue Barrault - 75634 Paris Cedex 13 - France Tel : +33 (0)1.45.81.74.36 Fax : +33 (0)1.45.81.31.19 E-mail: labiod@enst.fr Nadia Boukhatem Ecole Nationale Superieure des Telecommunications Departement Informatique-Reseaux 46 Rue Barrault 74013 Paris - FRANCE Phone: (+33) (-0)1 45 81 82 16 Email: Nadia.Boukhatem@enst.fr Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Tlais, et al. Expires May 2005 [Page 19]