INTERNET-DRAFT Thomas Clausen IETF NEMO Working Group Emmanuel Baccelli Expiration: 15 April 2005 LIX, Ecole Polytechnique, France Ryuji Wakikawa Keio University/WIDE 15 October 2004 NEMO Route Optimisation Problem Statement draft-clausen-nemo-ro-problem-statement-00.txt Status of this Memo This document is a submission to the Network Mobility Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the nemo@ietf.org mailing list. Distribution of this memo is unlimited. By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 The NEMO working group has developed a protocol suite, extending the notion of edge-mobility on the Internet to include that of network mobility. This implies that a set of nodes, along with their mobile router, change their point of attachment and that traffic to these nodes is tunneled to be delivered through their new point of Clausen, Baccelli, Wakikawa [Page 1] INTERNET-DRAFT RO Problem Statement 15 October 2004 attachment. This mechanism is transparent to applications in that existing traffic to a node is being encapsulated and tunneled, regardless of where the network containing the destination node is attached. The NEMO specification is not limited to a single level of mobile networks, attaching to the stationary Internet. Rather, arbitrary levels of nested mobile networks are supported, employing for each level of nesting the same encapsulation and tunneling mechanisms. With arbitrarily deep nested mobile networks, the overhead incurred through tunneling and encapsulation of data traffic can, however, become large. As a consequence, a number of different proposals exist, which aim at performing "route optimization" for nested mobile networks. This document aims at describing the different scenarios in which route-optimization is desired, as well as the different proposed solutions for achieving route-optimization in nested mobile networks. Clausen, Baccelli, Wakikawa [Page 2] INTERNET-DRAFT RO Problem Statement 15 October 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. NEMO-to-NEMO . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Internet-to-NEMO . . . . . . . . . . . . . . . . . . . . . . . 6 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. NEMO-to-NEMO . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. Route Optimization Mechanisms Within Nested NEMO . . . . . . 9 3.1.2. Ad-hoc Network of Mobile Routers . . . . . . . . . . . . . . 9 3.2. Internet-to-NEMO . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.1. Route Optimization Mechanisms Initiated by MR or MNN . . . . 11 3.2.2. Route Optimization Initiated by a Non-Mobile Router . . . . . 12 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Clausen, Baccelli, Wakikawa [Page 3] INTERNET-DRAFT RO Problem Statement 15 October 2004 1. Introduction The NEMO protocol suite extends Mobile IP in enabling a set of nodes, along with their mobile router, to change their point of attachment to the Internet. NEMO enables the traffic to these nodes to be tun- neled for delivery through their new point of attachment. The use of tunneling makes this mechanism transparent to applications, wherever the new point of attachement, even in case of several layers of nested mobility (i.e. mobile nodes, or mobile routers, indirectly accessing the Internet through other mobile routers). However, this approach is not without a certain cost: with arbitrar- ily deep nested mobile networks, the overhead due to tunneling, dog- leg routing and encapsulation of data traffic can become large. A number of different solutions have been proposed in order to optimize this routing in some of these cases. A review of some of these solutions is provided in this document, as well as the discussion of which cases and to what extent route opti- mization is desireable with NEMO. 1.1. 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 RFC2119 [5]. It is assumed that readers are familiar with NEMO terminology as described and employed in [1] and [8]. 1.2. Applicability This document aims at discussing scenarios where route optimization is desirable in a NEMO environment, and what level of route optimiza- tion is desired in those cases. A review of some existing solutions and ideas is thereby provided. 2. Scenarios At least two distinct scenarios exist, where route optimization is desireable. Those are, respectively, when a node in a NEMO network wishes to communicate with a node in another NEMO network which is part of the same nesting, and when a node from the Internet wishes to communicate with a node in a nested NEMO network. Clausen, Baccelli, Wakikawa [Page 4] INTERNET-DRAFT RO Problem Statement 15 October 2004 While the scenarios may have commonalities, their possible solution- space differs and they are therefore described seperately below. 2.1. NEMO-to-NEMO In this scenario, a number of NEMO networks are nested to one another, and nodes in the different NEMO networks are communicating with one another. For the purpose of this scenario description, refer to the schematics below: ---------- ---------- ---------- | | | | | | | NEMO 1 |--| NEMO 2 |--| NEMO 3 |--Internet | | | | | | | ---------- ---------- ---------- | | ---------- ---------- | | | | | |----| HA 2 | | HA 1 |---------| | | | | | ---------- ---------- | ---------- | | | HA 3 | | | ---------- Figure 1: Nested NEMO networks -- NEMO-to-NEMO communication We assume that each box labeled "NEMO x" refers to a Mobile Router (MR), running the NEMO protocol, as well as the nodes attached to that mobile router. We further assume, that each line indicates a direct connection between routers -- i.e. the mobile router in "NEMO 1" has a direct connection to the mobile router in "NEMO 2". Each box labeled "HA x" refers to the Home Agent for the NEMO network x -- i.e. that HA 1 is the Home Agent for the mobile network NEMO 1. If a node from NEMO 3 wishes to communicate with a node from "NEMO 1", then the data traffic would first be sent to the Home Agent of NEMO 1 -- i.e. to HA 1. At HA 1, a binding would exist, identifying NEMO 1 as being attached to the network of NEMO 2. Thus, the traffic would be encapsulated, and sent to the HA of NEMO 2, i.e. HA 2. At HA 2, a binding would exist, identifying that, indeed, NEMO 2 is attached to the network of NEMO 3. Another encapsulation would ensure, and the traffic sent to HA 3. At HA 3, a binding would Clausen, Baccelli, Wakikawa [Page 5] INTERNET-DRAFT RO Problem Statement 15 October 2004 identify the point of attachment of NEMO 3 to the internet, and the data traffic would be encapsulated one final time prior to being delivered to NEMO 3 -- where decapsulation and handoff to NEMO 2, then NEMO 1 occurs. In this scenario, short path between NEMO 1 and NEMO 3, without transversing the Internet and HA1-3, exists, however is not used in the current NEMO specification. More generally, assume a set of NEMO networks forming a connected network via their mobile routers without transversing the Internet. For communication between nodes in these NEMO networks, a solution should exist, which provides routes between the nodes without transversing the Internet and without incuring excessive nested encapsulations. 2.2. Internet-to-NEMO In this scenario, a number of NEMO networks are nested to one another, and a node in the Internet wishes to communicate to a node in one of the NEMO networks. For the purpose of this scenario description, refer to the schematics below: ---------- ---------- ---------- ---------- | | | | | | | | | NEMO 1 |--| NEMO 2 |--| NEMO 3 |--Internet--| Node 1 | | | | | | | | | | ---------- ---------- ---------- | ---------- | ---------- ---------- | | | | | |----| HA 2 | | HA 1 |---------| | | | | | ---------- ---------- | ---------- | | | HA 3 | | | ---------- Figure 2: Nested NEMO networks -- Internet-to-NEMO communication The node labeled "Node 1" wishes to communicate with a node in NEMO 1. Similarly to the previous scenario, this will happen through con- necting to HA 1, then encapsulation and tunneling data to HA 2 and HA3 before the data arrives at the edge of our nested NEMO network. Clausen, Baccelli, Wakikawa [Page 6] INTERNET-DRAFT RO Problem Statement 15 October 2004 Only then can decapsulation and transmission via NEMO 3, NEMO 2 and NEMO 1 happen. In this scenario, while no direct link exists between Node 1 and the node in NEMO 1, triple encapsulation and transmission via HA1-3 occurs. More generally, a path between a node in the Internet and the edge of the nested NEMO networks exists, which does not necessarilly involve any of the Home Agents for the NEMO networks. For such communication, a solution should exist which avoids nested encapsulations (i.e. allows data to be encapsulated only once, in order to arrive at the edge of the nested NEMO networks), and which does not force a path which involves all the Home Agents of the nested NEMO networks on the path to the destination. In addition, nested encapsulation brings a limitation to the number of nested levels, due to MTU size. For example, the current NEMO basic support specification does not allow a level higher than 40 in nesting in NEMO (with usual MTU = 1500 bytes), due to the size of the 40 IPv6 headers, i.e. 40 bytes x 40 > MTU. In this case IP fragmen- tation does not help, since the total size of IPv6 headers exceeds the MTU. Thus, the avoidance of nested encapsulations also eliminates the limitation on the level of nesting in NEMO. 3. Solutions Common for the scenarios from the previous section is, that the encapsulation and tunneling is due to the facts that: - the node which originates data traffic does not know where the destination node is located and therefore assumes that the node is at its Home Network; - no router knows the full path to the destination, which in particular means that: - no router knows the topology of the nested NEMO network(s). As a concequence, each logical hop (from source to Home Agent of des- tination, or from Home Agent to Home Agent of the nested NEMO net- works) adds layers of encapsulation, until the point of attachment between the Internet and the NEMO edge, the Access Router (AR) is reached. Concequently, if the source node, or any intermediate node, had addi- tional information about the network topology, more beneficial Clausen, Baccelli, Wakikawa [Page 7] INTERNET-DRAFT RO Problem Statement 15 October 2004 tunnels could be created, and less encapsulation would be required. For example if, in figure 2 above, Node 1 knew directly that the gateway from the Internet to "the network where nodes from NEMO 1 are attached" was the Access Router of NEMO 3, and if the mobile router in NEMO 3 knew the topology of the nested NEMO network, a tunnel could be directly created from Node 1 to NEMO 3, with assurance that the mobile router in NEMO 3 would be able to route data packets cor- rectly to the destination. 3.1. NEMO-to-NEMO The NEMO-to-NEMO problem, as described in section 2.1, is one of how to avoid transversing the Internet in order to communicate between two nodes which are part of the same nested NEMO network. More gener- ally, this can be expressed as "how traffic is routed within the NEMO network". NEMO basic support [1] specifies that traffic be routed via Home Agents, indicating an assumption of limited depth of nested networks and traffic patterns being predominantly traffic of the Internet-to- NEMO type. Each mobile router in a NEMO network knows only of its attachments, i.e. its access router and the nodes within its own mobile network. A mobile router in NEMO does not know about any nest- ings, i.e. it does not know the topology of the nested NEMO network -- and as such, can only provide routes to the Home Agents on the Internet. In order to avoid the scenario described in section 2.1, where data packets for delivery within the nested NEMO network are routed through the Internet and the nested networks Home Agents, when a more localized aproach would have been possible, additional state can be maintained in the nested NEMO networks. A number of approaches for maintaining state in mobile routers and/or Home Agents of mobile net- works have been discussed, including [3], [4], [9], [10], [11], [12], [13], in which techniques such as route caching are discussed. These techniques can be deployed in Home Agents, in routers, specifically designated as aggregation points for NEMO tunnels, as well as within the mobile routers in order to optimize routes within a nested NEMO network. This is detailed in section 3.1.1. Essentially, however, the issue of route optimization within a nested NEMO network is one of routing: maintaining state in each mobile router such that an intelligent forwarding decision can be made. I.e., if the destination can be detected to be "local" to the nest of NEMO networks, a route to the destination can be constructed directly Clausen, Baccelli, Wakikawa [Page 8] INTERNET-DRAFT RO Problem Statement 15 October 2004 through the NEMO mobile routers without passing through the Home Agents. Alternatively, if the destination is not local, data are routed to the Home Agent, where basic NEMO tunneling and encapsula- tion take effect. Deploying a routing protocol for maintaining suffi- cient state in the nodes in the nested NEMO network is detailed in section 3.1.2. 3.1.1. Route Optimization Mechanisms Within Nested NEMO Some approaches have been proposed to tackle the problem of route optimization inside nested NEMO networks. For instance, Nested NEMO Tree Discovery [4] offers a mechanism that aims at avoiding routing loops by organizing and maintaining a tree structure within the net- work of nested NEMOs, the root being the Access Router or the Mobile Router directly connected to the Access Router (the Top Level Mobile Router). Source routing is also proposed to be used in this environment. Approaches like RRH [12] use the recording of the sequences of tra- versed Mobile Routers on the way out of the nested NEMO network (to the Internet, say, to bind) in order to forward traffic efficiently in the nested NEMO network. On the other hand, approaches like ORC (Optimized Route Cache Proto- col [3]) could be adapted to serve the purpose of insuring some level of optimized routing inside nested NEMO networks. Some router, say the top level mobile router, could be configured to play a role simi- lar to a correspondent router, organizing the forwarding of packets inside the nested NEMO network. This special router could be dynami- cally discovered inside the nested NEMO network. A more general form of this mechanism would be to have each MR in the nested NEMO network possess this extended information about the nested NEMO network. This does then, de-facto, become a situation where each MR knows the entire topology of the nested NEMO network, and will be able to act in the capacity of router for such traffic. This generalized mechanism is described in more details in section 3.1.2. 3.1.2. Ad-hoc Network of Mobile Routers A NEMO network consists of a mobile router, to which a set of nodes are (statically) attached. The mobile router communicates with (i.e. has direct links with) other mobile routers, and possibly with the Internet at large. As such, a NEMO network is not much different from Clausen, Baccelli, Wakikawa [Page 9] INTERNET-DRAFT RO Problem Statement 15 October 2004 any other network. What makes NEMO networks different from other net- works is, that they may change their point of attachment at will -- i.e. the topology formed by NEMO mobile routers is dynamic. Thus, in order to provide routes between any two nodes in the nested NEMO network, a mechanism must be in place which ensures that the dynamic topology of the nested NEMO network can be accurately tracked and used for routing table calculations. The IETF MANET working group has been developing routing protocols for dynamic ad-hoc networks, such as OLSR [2] and AODV [6] (both RFC), with the characteristics that the developed protocols should be light-weight, able to react to rapid topology changes and limit the signalling overhead. An approach to route optimization within the NEMO-to-NEMO scenario could therefore be to consider the mobile routers of the nested NEMO networks as nodes in an ad-hoc network, and run an ad-hoc routing protocol to ensure that each mobile router would be able to determine if data could be locally (i.e. within the nested NEMO network) delivered, or had to be tunneled back to the Home Agent. OLSR [2], for example, provides light-weight OSPF-like [7] routing functionality. This includes efficient maintenance of the topology spanned by the links between the mobile routers in the face of net- work dynamics, as well as the ability for a mobile router to adver- tize associated nodes which do not run the OLSR routing protocol (e.g. nodes associated to a mobile router, which are not themself mobile routers). It is also possible for Mobile Network Nodes to obtain global connectivity, as described in [16]. Employing a protocol such as OLSR among the mobile routers in a nested NEMO network would yield the ability for any mobile router to determine if a destination can be reached through a path local to the nested NEMO network, or if forwarding to the Home Agent is required. Additionally, this would also ease the Internet-to-NEMO scenario. In order to deliver an IP datagram to a node in the nested NEMO network, only a path to the access router between the nested NEMO network and the Internet would be required: once an IP datagram arrives in the nested NEMO network, the routing tables in the mobile routers, as provided by OLSR, would allow direct routing to the destination. Thus, there would no longer be a requirement to do nested encapsula- tion on each logical hop (i.e. each transversal of a Home Agent) in order to be able to decapsulate and correctly forward IP datagrams in the nested NEMO network. Thus even if no route optimizations are performed in the Internet-to- NEMO scenario, an overhead reduction can still be achieved through much lower encapsulation requirements. Clausen, Baccelli, Wakikawa [Page 10] INTERNET-DRAFT RO Problem Statement 15 October 2004 3.2. Internet-to-NEMO The goal here is, again, to avoid unnecessary encapsulation and dog- leg routing. Indeed, it is desirable to avoid letting the level of nested mobility on the edges of the network dictating the number of Home Agents (and therefore the amount of encapsulation) the packets have to go through. There should be a way to limit the level of tun- neling to only one encapsulation IP in IP, and at the same time, min- imize the traffic relayed by Home Agents. Existing solution to route optimization problems in NEMO therefore aim at, basically, minimizing the required amount of tunneling in various nested mobility cases. They can be categorized as follows: - route optimization initiated by Mobile Routers (MR) or Mobile Network Nodes (MNN); - route optimization initiated by intermediate non-mobile routers on the path to Corresponding Nodes. The following sub-sections briefly review these solutions. 3.2.1. Route Optimization Mechanisms Initiated by MR or MNN In case of nested mobility (i.e. a mobile router attaches to another mobile router, or a visiting mobile node attaches to a mobile router), several encapsulations will occur on top of each other, and a sub-optimal path will be used to reach the destination, going through each and every Home Agent. In order to slim this down, sev- eral nested tunnel optimizations have been discussed. The HMIP-like mechanisms suggested in [15] or the TLMR (Top Level Mobile Router [11]) approach use one or more Mobile Routers chosen for their location (closest to the Access Router) to act as proxy for Mobile IP, and/or act as Home Agents for other mobile nodes inside the attached mobile networks, like proposed in [14]. Instead of adding another layer encapsulation, those TLMR switch between ingress and egress tunnels and can reduce the amount of binding. Similarily, ARO (Access Router Option [13]) proposes nested tunnel optimizations based on the registration of the top level Access Router of any nested NEMO to the Home Agent in order to bypass the HAs of all the MR on the way to the Access Router. On the other hand, source routing approaches like RRH (Reverse Clausen, Baccelli, Wakikawa [Page 11] INTERNET-DRAFT RO Problem Statement 15 October 2004 Routing Header [12]) or Path Control Header [9] use loose source routing in order to avoid IP encapsulation. However, source routing is not always desirable, and might not be widely accepted. 3.2.2. Route Optimization Initiated by a Non-Mobile Router Some approaches such as ORC (Optimized Route Cache Protocol [3]) or other proposals using so called Anchor Routers or Correspondent side routers (see [10] for further references), advocate the adding of new functionalities in some routers that are ideally chosen to be opti- mally placed with respect to traffic flows between ASs. Those routers intercept and terminate the tunneling on behalf of the Correspondent Node, therefore optimizing the route from then on. However, this is not easy to deploy, and the optimization is partial. 4. Acknowledgements The authors would like to thank Hitachi Labs Europe for their support. 5. Authors' Addresses Thomas Heide Clausen, Project PCRI Pole Commun de Recherche en Informatique du plateau de Saclay, CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud, Ecole polytechnique, Laboratoire d'informatique, 91128 Palaiseau Cedex, France Phone: +33 1 69 33 40 73, Email: T.Clausen@computer.org Emmanuel Baccelli HITACHI Labs Europe/ Project PCRI, Pole Commun de Recherche en Informatique du plateau de Saclay, CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud, Ecole polytechnique, Laboratoire d'informatique, 91128 Palaiseau Cedex, France Phone: +33 1 69 33 40 73, Email: Emmanuel.Baccelli@inria.fr Ryuji Wakikawa Keio University and WIDE Clausen, Baccelli, Wakikawa [Page 12] INTERNET-DRAFT RO Problem Statement 15 October 2004 5322 Endo Fujisawa Kanagawa 252 JAPAN Phone: +81-466-49-1394 EMail: ryuji@sfc.wide.ad.jp Fax: +81-466-49-1395 6. References [1] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert. Nemo Basic Support Protocol (work in progress). Internet Draft (draft- ietf-nemo-basic-support-02), Internet Engineering Task Force, December 2003. [2] T. Clausen, P. Jacquet, Optimized Link State Routing Protocol. Request for Comments (Experimental) 3626, October 2003. [3] R. Wakikawa, M. Watari. Optimized Route Cache Protocol (ORC) (work in progress). Internet Draft (draft-wakikawa-nemo-orc-00.txt), Internet Engineering Task Force, July 2004. [4] P. Thubert, N. Montavont. Nested Nemo Tree Discovery (work in progress). Internet Draft (draft-thubert-tree-discovery-00.txt), Internet Engineering Task Force, May 2004. [5] S. Bradner. Key words for use in RFCs to Indicate Requirement Lev- els. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [6] C. Perkins, E. Belding-Royer, S. Das. Ad hoc On-Demand Distance Vec- tor (AODV) Routing, Request for Comments (Experimental) 3561, July 2003 [7] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [8] T. Ernst, H-Y. Lach. Network Mobility Support Terminology (work in progress). Internet Draft (draft-ietf-nemo-terminology-01), Inter- net Engineering Task Force, February 2004. [9] Jongkeun Na et al. Route Optimization Scheme based on Path Control Header (work in progress). Internet Draft (draft-na-nemo-path-con- trol-header-00), Internet Engineering Task Force, April 2004. [10] P. Thubert et al. Taxonomy of Route Optimization models in the Nemo Context (work in progress). Internet Draft (draft-thubert-nemo-ro- taxonomy-02), Internet Engineering Task Force, February 2004. [11] H. Kang et al. Route Optimization for Mobile Network by Using Bi- directional Between Home Agent and Top Level Mobile Router (work in Clausen, Baccelli, Wakikawa [Page 13] INTERNET-DRAFT RO Problem Statement 15 October 2004 progress). Internet Draft (draft-hkang-nemo-ro-tlmr-00.txt), Inter- net Engineering Task Force, June 2003. [12] P. Thubert et al. IPv6 Reverse Routing Header and its application to Mobile Networks (work in progress). Internet Draft (draft-thu- bert-nemo-reverse-routing-header-05), Internet Engineering Task Force, June 2004. [13] C. Ng et al. Securing Nested Tunnels Optimization with Access Router Option (work in progress). Internet Draft (draft-ng-nemo- access-router-option-01), Internet Engineering Task Force, July 2004. [14] E. Perera et al. Extended Network Mobility Support (work in progress). Internet Draft (draft-perera-nemo-extended-00.txt), Internet Engineering Task Force, July 2003. [15] H. Ohnishi et al. HMIP based Route Optimization Method in a Mobile Network (work in progress). Internet Draft (draft-ohnishi-nemo-ro- hmip-00.txt), Internet Engineering Task Force, April 2003. [16] R. Wakikawa et al. Global Connectivity for IPv6 Mobile Ad Hoc Net- works (work in progress). Internet Draft (draft-wakikawa-manet- globalv6-03.txt), Internet Engineering Task Force, October 2003. 7. Changes This is the initial version of this specification. 8. IANA Considerations This document does currently not specify IANA considerations. 9. Security Considerations This document does not specify any security considerations. 10. Copyright 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. 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 INFOR- MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES Clausen, Baccelli, Wakikawa [Page 14] INTERNET-DRAFT RO Problem Statement 15 October 2004 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.