NSIS O. Schelen Internet-Draft Operax Expires: May 5, 2003 A. Couturier Alcatel R. Bless Univ. Karlsruhe R. Geib T-Systems O. Dugeon FTR&D November 4, 2002 Path-coupled and Path-decoupled Signaling for NSIS draft-schelen-nsis-opopsig-01 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. This Internet-Draft will expire on May 5, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract The NSIS Work group will develop the requirements, architecture and protocols for the next IETF steps on signaling. Two approaches for a signaling model have been discussed: path-coupled and path-decoupled (previously denoted as on-path and off-path). This draft provides a Schelen, et al. Expires May 5, 2003 [Page 1] Internet-Draft Path-coupled / Path-decoupled Signaling November 2002 conceptual comparison between path-coupled and path-decoupled signaling together with reasons for why an NSIS protocol should be designed to support both cases. The collection of data objects to be carried by the protocol should basically be the same in both cases and will evolve over time as new usages for NSIS protocol are identified. The differences between the two flavors of this NSIS protocol are then explained. 1. Conventions used in this document The key words "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 [1]. 2. Introduction The Next Steps in Signaling (NSIS) working group is chartered to develop the requirements, architecture and protocols for the next IETF steps on signaling. Two approaches about the signaling model have been discussed: path-coupled and path-decoupled. This draft provides a conceptual comparison between those two approaches together with reasons for why an NSIS protocol should be designed to support them both by offering two different flavors. The collection of data objects to be carried by the protocol should basically be the same in both cases and will evolve over time as new usages for NSIS are identified. We identify at a high level the differences between the path-coupled and path-decoupled flavors of the protocol. 3. Terminology NSIS Initiator (NI) - NSIS Entity that initiates NSIS signaling for a network resource based on user or application requirements. This can be located in the end system, but may reside elsewhere in network [2]. NSIS Responder (NR) - NSIS Entity that terminates NSIS signaling and can optionally interact with applications as well. NSIS Forwarder (NF) - NSIS Entity on the path between a NI and NR, which may interact with local resource management function (RMF) for this purpose. NSIS Forwarder also propagates NSIS signaling further through the network. It is responsible for interpreting the signaling carrying the user parameters, optionally inserting or modifying the parameters according to domain network management policy [2]. Control Information: information that governs the treatment to be applied to a flow or an aggregate (e.g., QoS treatment including Schelen, et al. Expires May 5, 2003 [Page 2] Internet-Draft Path-coupled / Path-decoupled Signaling November 2002 service class, flow administration, and any associated security or accounting information [2]. 4. Path-coupled Signaling 4.1 Description of path-coupled signaling Path-coupled signaling refers to the situation where the signaling path is tied to the data path of the IP flow to be signaled. That means signaling messages referring to a particular data flow follow the same path as packets of that data flow, i.e., signaling messages pass through the same devices as data packets of the data flow. In the forward direction signaling messages usually carry the same IP destination address as data packets of the related user data flow. It must be noted, that some signaling messages (e.g., responses) may also follow the same path in the reverse direction. Usually, the previous hop must be remembered and directly addressed in this case. An example for a path-coupled signaling protocol is RSVP [4]. In summary path-coupled signaling shows the following properties: o Only network elements that forward data packets can participate in signaling, i.e., routers must process the signaling messages. o Routers that forward IP packets along the data path can participate in the signaling by intercepting and processing incoming signaling messages. o The next signaling hop in forwarding direction is discovered by transmitting signaling packets through an ordinary lookup in the local IP forwarding table, using the final destination address of the signaling packets. The signaling path in the reverse direction (upstream) has to be remembered from the forward direction (i.e., the previous hop must be stored), because routes can be asymmetric. o The path of the signaling messages adapts automatically to route changes for data packets (if associated with a soft-state mechanism). o Signaling unaware routers can forward a signaling message correctly to the next hop if the destination address of the signaling message is the same as for the data flow. Schelen, et al. Expires May 5, 2003 [Page 3] Internet-Draft Path-coupled / Path-decoupled Signaling November 2002 4.2 Advantages of path-coupled signaling 4.2.1 Efficient device configuration One advantage of path-coupled signaling is that nodes along the data path can install or update configuration data (state) just by receiving, processing and forwarding signaling packets, following the traditional routing mechanisms. In case the devices to be configured are located along the path, this mechanism is considered the simplest. It does not require additional configuration protocol exchange, as the signaling hops are the same as the IP forwarding ones. 4.2.2 Bypassing signaling unaware clouds In case of an IP cloud which is signaling unaware (e.g., because of over-provisioning), signaling packets can go through the cloud transparently, like normal IP packets. At the egress router of that cloud, signaling still follows the data path and can be processed by the next hops. Even if an IP cloud following the traditional IP routing is signaling unaware, it is still a path-coupled signaling carrier. 4.2.3 Automatic adaptation to changed routes The path of signaling messages adapts automatically to route changes which is often, but not always, desired. As a result of route changes, reservation state will automatically be installed in routers along a new path while it will be removed in routers along the old path. 4.3 Disadvantages of path-coupled signaling 4.3.1 Limited flexibility for integration of other entities Typically IP networks are provisioned for delivering certain services internally, while customers/peers have various access schemes at edges/boundaries. Accountable services (e.g., max bandwidth with ensured QoS, max number of concurrent VoIP calls, access bandwidth variations over time of day and day of week, advance reservations, price profiles) require installing states in policy servers that are not located on the data path. Establishing such services typically requires interaction between client and NSIS forwarder (policy server) to perform state processing and state installation. However, entities and hosts that are not located on the data path cannot be easily included into a path-coupled signaling process. This makes it more difficult to use signaling proxies or Schelen, et al. Expires May 5, 2003 [Page 4] Internet-Draft Path-coupled / Path-decoupled Signaling November 2002 administrative servers (e.g., policy or accounting servers). The latter is for example required when a server hosting user profiles participates in the admission control procedure. In general, all actions that require keeping persistent states, e.g., for accounting or retrieving service level data (such as user profiles or policies) cannot be easily supported by routers. The current solution is to out-source the signaling processing via the COPS interface [5]. As policies are more and more important especially in cases of customer access and peering between several ISPs, policy servers are expected to be extensively involved in signaling processing. 4.3.2 Impact of non contiguous signaling paths Path-coupled signaling is based on the fundamental assumption that the signaling path is the same as the data path. Usually, in a stable network condition (no route changes occur) consecutive packets of a single flow are all routed the same way, based on the IP destination address. This will be called "traditional IP routing" in the following. Traditional IP routing is of course predominant in the Internet today, therefore path-coupled signaling benefits from deployment advantages. This situation may suffer from threats in several deployments. QoS routing, traffic engineering or load balancing technologies may route flows differently than in the traditional IP routing model. In these cases, a signaling unaware cloud is not anymore a transparent signaling carrier, as nothing assures it will forward the signal at the same place it will forward the data flow. Then, signaling unaware clouds can break the path-coupled signaling, and can simply install reservation state at wrong paths. 4.3.3 Signaling processing and complex control functions in routers One problem is that signaling message processing and more complex control tasks (e.g., resource-based admission control) have to be implemented in routers. A change of control functions (e.g., admission control algorithms) requires also a change to the routers. One problem of RSVP and IntServ is that every router in the network must implement IntServ and RSVP in order to link the sink and the source with a chain of QoS capable routers that all allocate resources for the flow. Of course, RSVP aggregation [6], or RSVP over DiffServ [7][8] architectures propose to reduce the number of flow states inside network domains by concentrating per-flow reservations in strategically positioned routers, called RSVP aggregators and de-aggregators (e.g., positioned at diffserv ingress and egress routers). However, this model still imposes that all flow-aware nodes must implement the signaling. In a network Schelen, et al. Expires May 5, 2003 [Page 5] Internet-Draft Path-coupled / Path-decoupled Signaling November 2002 consisting of several providers, de-aggregation into micro-flows and re-aggregation is performed at all domain boundaries (ingress points and peering points). This imposes that a large portion of the routers must be upgraded in order to build a coherent signaling and QoS capable network. 4.3.4 Limited support in mobile scenarios In some scenarios with mobile senders or receivers it may be desirable to have a "seamless" hand-over. In this case, resources along the new path should be reserved before the data flow is actually switched from the old path to the new path. 4.3.5 Protection and Security Path-coupled signaling messages being transmitted to an unknown next signaling hop may be hard to protect. 4.3.6 NAT and private address schemes Path-coupled signaling messages transmitted through a Firewall/NAT must be changed when passing this device. When a network operator uses a private address scheme, the end user IP address must be translated before reaching the public part of the network. NAT devices that translate addresses in headers must also translate addresses carried in the body of signaling messages to reflect the NAT processing. To achieved this goal, NAT devices must be NF devices to convey NSIS compliant signaling messages. 5. Path-decoupled Signaling 5.1 Description of Path-Decoupled Signaling Path-decoupled signaling refers to the situation where the signaling path is not necessarily bound to the data path of the signaled flow. End stations/users may signal to particular entities (e.g., servers) in the network of their providers. The "path" taken by path- decoupled signaling messages correspond to the AS path rather than the hop by hop path taken by path-coupled signaling messages. That means signaling messages may be destined to devices that are not on the forwarding path of the particular flow. This happens either when signaling is not initiated by end hosts, or when signaling is directed to NSIS forwarders that are not on the data path. In this model, the IP destination address of a signaling message is separated from the destination address flow(s) for which resources are requested. In summary path-decoupled signaling shows the following properties: Schelen, et al. Expires May 5, 2003 [Page 6] Internet-Draft Path-coupled / Path-decoupled Signaling November 2002 o The signaling path is decoupled from the actual data path, therefore it allows to signal entities that are not on the data path. This allows to shift some control functions to other entities than routers. o Path-decoupled signaling simplifies interworking with domains applying forwarding planes other than IP (e.g. MPLS or WDM) or using private addressing schemes. o To modify and control resources at the routers passed by the data- flow corresponding to a path-decoupled signaling message, the data path must be predicted by path-decoupled signaling units. o The path-decoupled signaling system must be able to configure routers in the data path by access to a management interface. o Path-decoupled signaling must be able to discover the next signaling hop. 5.2 Advantages of path-decoupled signaling 5.2.1 Independence of signaling plane and forwarding plane By nature, path-decoupled signaling isolates signaling processing (e.g., admission control in case of QoS signaling) from the underlying network nodes. Because the complexity of the service control and admission control is isolated in servers, it allows in the short term to implement QoS signaling on top of a simple DiffServ network. A similar architecture based on pre-provisioned networks is explained in [10]. The advantage is to preserve the IP legacy of stateless class-based forwarding (not requiring state with respect to individual data flows). This provides scalability in routers, both in control and forwarding plane. Signaling can be carried out at the application layer between NSIS initiators and NSIS Forwarders. Path- decoupled signaling offers the same type of benefits in the long term. The separation between the signaling layer and the IP forwarding layer allows an ISP to isolate functionalities, and make them evolve independently. There is flexibility in network evolution as new routers or nodes can be integrated in the network without having to be per-flow or NSIS session aware. Also, new algorithms for admission control can be deployed without having to upgrade the routers. 5.2.2 Low upgrade complexity in routers To support a path-decoupled signaling standard, upgrading of routers is not needed or may be limited to a relay function identifying an Schelen, et al. Expires May 5, 2003 [Page 7] Internet-Draft Path-coupled / Path-decoupled Signaling November 2002 NSIS message and transmitting it to a path-decoupled signaling unit responsible for this router. The latter method can be used for interworking with path-coupled signaling. 5.2.3 Flexibility in signaling entity deployment In deployment of a new protocol, there may be some applications and end-points that are NSIS aware while others are not. The path- decoupled model can work transparently to end-points and application by having NSIS initiated from application frameworks or from separate network/resource management frameworks. Also, endpoints or web servers can offer applications allowing end-users to self-manage their general purpose network access. VoIP or multimedia network applications relies on servers such as soft- switches, gatekeepers, SIP proxies and application servers that are not on the data path of the multimedia flows. These servers are candidates to be an NI, as they are responsible for the service sessions. These kinds of NIs could use a path-decoupled signaling protocol to interact with an NF. 5.2.4 Support for non-traditional routing Network sections applying forwarding planes other than IP may require an interworking functionality with NSIS signaling. While layer 2 issues are out of scope for NSIS, MPLS is operational in several large international IP backbones. While a path-coupled signaling architecture requires an IP/MPLS gateway to implement the new NSIS protocol, an interworking function and possibly some modified MPLS signaling protocol, a path-decoupled system could take care of all that. End to end service deployment across heterogeneous network platforms may benefit from path-decoupled signaling. 5.2.5 Mobility Path-decoupled signaling enables seamless hand-overs combined with a reduction of signaling in the case of wireless mobility. A path- decoupled signaling unit learning about a mobile terminal now connected to a new access router may transfer the signaling context of the mobile terminal to the new access router and simultaneously remove state in the old access router. No additional air interface signaling is required to re-install state in the new access router. The resulting hand-over is fast and saves scarce battery power. 5.2.6 Security Path-decoupled signaling units may discover neighboring path- decoupled signaling units prior to any end to end service reservation. Hence, it is sound to expect signaling between path- decoupled systems to be protected once end to end messages are Schelen, et al. Expires May 5, 2003 [Page 8] Internet-Draft Path-coupled / Path-decoupled Signaling November 2002 processed. Similar to security mechanisms to be applied by NSIS, the discovery mechanism for a path-decoupled protocol may not have to be specified by NSIS. 5.3 Disadvantages of path-decoupled signaling 5.3.1 Determining the next signaling hop Because signaling entities are not placed along the data path, the next destination of a signaling message cannot be determined by determining the next hop in the data path. However, there are several ways to determine the next signaling node. One possibility is to extend legacy configuration mechanisms at access networks such as DHCP or stateless auto configuration by the required addresses of NFs. Adjacent domains may have either statically configured next hops or may use an extra discovery mechanism. Routing tables can be used to determine which domain is the next hop. 5.3.2 Synchronization with routing tables In addition to admission control or state installation, a path- decoupled NSIS Forwarder must determine where to route the signaling messages, depending on where the flow to be signaled is routed. In case of path-coupled signaling, the signaling packet is ignored or processed, and then routed as a normal packet. A path-decoupled NF must determine where particular traffic leaves its domain and enters a neighboring domain. For this, topology awareness is needed. This draft does not intend to give an exhaustive list of architectures enabling a routing synchronization between the forwarding plane, and the signaling plane as this is out of the scope of the NSIS charter. However, there are solutions that can be implemented by passively participating in intra-domain routing (e.g., OSPF, IS-IS) and listening to inter-domain routing (e.g., by IBGP to edge routers inside the domain). The functionality is similar to what is found inside a router today but passive in the sense that no routes are advertised and no peering is performed with routers in other domains. 5.3.3 Installing state in routers When considering QoS provisioning in DiffServ networks, path- decoupled signaling typically involves configuration of traffic conditioners at domain boundaries in order to perform policing and marking at the network edges (especially in the very first router). Various standards and proprietary interfaces can be supported by an Schelen, et al. Expires May 5, 2003 [Page 9] Internet-Draft Path-coupled / Path-decoupled Signaling November 2002 NSIS Forwarder in order to transport the necessary configuration data (e.g., profiles) to the routers. SNMP or COPS are two IETF standards that can be used to configure routers. It has to be noted that this signaled configuration of network elements may have a performance issue due to the available mechanisms. 6. A Combined Solution Up to this point, the draft presents the advantages and issues of path-coupled and path-decoupled signaling, as it has been discussed in the mailing list. The aim of this chapter is to advocate for a non-exclusive solution. 6.1 Path-coupled and path-decoupled models inter-working A strategy for NSIS could be to focus on a particular model, the preferred one being path-coupled, and refuse or postpone the work concerning path-decoupled. As both models have their benefits and weaknesses, depending on the environment, the NSIS WG solution should be flexible enough to allow them both. There are situations where the signaling models could be combined for the same flow. For example, the following situation should be possible: o One ISP may use an application-level path-decoupled solution to provide services to its customers, while continuing the signaling path-coupled towards a peering domains that adopt traditional IP routing. This situation corresponds to the gatekeeper/SIP proxy/ content server initiating a reservation. o One ISP may prefer path-coupled signaling from terminals and at access router link forwards the request to a policy framework that can take decisions based on customer profiles and network status, and also based on contracts with neighboring domains using path- decoupled signaling. o At the border between a domain following the traditional IP routing with another domain which adopts e.g. traffic engineering techniques, the path-coupled signaling can be extracted and then continued path-decoupled. These situations need a "signaling gateway router" implementing path- coupled signaling on some of its interfaces and path-decoupled signaling on the others. Because it would be useful to have a simple implementation of the signaling gateway router, and because the additional required specification work is small, a unified solution presenting two Schelen, et al. Expires May 5, 2003 [Page 10] Internet-Draft Path-coupled / Path-decoupled Signaling November 2002 flavors - path-coupled and path-decoupled - of the same signaling is a reasonable choice. The following sections will explain the differences between these two flavors. 6.2 Data objects for path-coupled and path-decoupled signaling 6.2.1 Destination address The information that are used to identify a flow are generally port numbers and IP address/prefix for destination and origination, protocol number, DSCP/TOS value and, in IPv6, flow label. In case of path-coupled signaling for a micro-flow, the destination address of the flow must be the same as the one of the signaling packet. However, this does not preclude a replication of the IP destination address in the IP payload of the signaling packet. This is the case in RSVP. When the flow is an aggregate, there must be in the signaling packet's header an IP destination address chosen inside the aggregate prefix, and the prefix itself must be inside the signaling packet payload. So, concerning path-coupled model, the signaling carries a flow specification that can contain a destination address or prefix. In the path-decoupled case, the signaling carries a flow specification that must always contain a destination address or prefix, as the packet header contains the destination address of the next NF. 6.2.2 Ingress address In the path-decoupled model, it is necessary to specify in the request what is the entry point of a flow in the domain controlled by an NF. This can be done by using the IP address of the router interface that receives the flow or alternatively the source address for a host sending a request to its local ISP (provided it is well- defined which ingress interface that the host will use). The reason for this is that with path-decoupled signaling, the requests sent to an NF can encompass flows entering the domain through several interfaces of one or several routers. In order to know which router and which interface will receive the flow, this information must be added in the request. For requests between adjacent NFs the upstream NFs must find out which incoming interface of the downstream domain that will be used. To summarize, the differences between an path-coupled signaling and its associated path-decoupled version are: o the addition, if not already mandatory in path-coupled, of the IP destination address/prefix in the flow specification Schelen, et al. Expires May 5, 2003 [Page 11] Internet-Draft Path-coupled / Path-decoupled Signaling November 2002 o the addition of an ingress address object in the flow specification. It is expected that a signaling gateway router receiving an path- coupled signaling message, after having processed it, will add the destination address (if needed) and the ingress address in the message, and forward it. 6.3 Protocol concepts Path-coupled signaling has traditionally been implemented as a specific protocol on top of IP that is interpreted by routers along the path. It is likely that an NSIS path-coupled flavor will be designed along these lines as routers typically are not involved in application layer signaling. This is a quite complex task both in terms of specification and deployment in routers. A path-decoupled signaling flavor can be implemented at the application layer (over TCP, UDP or other transport protocol). The design can therefore focus more on specifying data-objects as no new support is needed for transport functionality. It will also be possible to try out and deploy the signaling in networks with current diffserv standard, without requiring new standards in the routers. Both path-coupled and path-decoupled models should use pair-wise handshake between NFs involved in providing e2e service. Early path- coupled protocols (e.g., RSVP) did signal along the path without handshake for reliable delivery between adjacent neighbors, but it has been identified [9] that such a model has problems meeting required state maintenance. 7. Conclusion Both path-coupled and path-decoupled models are relevant for signaling in IP networks, and answer technical needs. In order to increase the applicability and deployment of a new signaling, this document proposes to specify in NSIS one protocol that has one path- coupled and one path-decoupled flavor. The identified differences between the two variants are one or two protocol objects defining ingress and destination address for requests. The path-decoupled flavor may be implemented at application layer, while the path- coupled flavor most likely would be implemented as a protocol on top of IP. 8. Security Considerations Because this document only discusses aspects of path-coupled and path-decoupled signaling there are no direct security implications. Schelen, et al. Expires May 5, 2003 [Page 12] Internet-Draft Path-coupled / Path-decoupled Signaling November 2002 However, for both signaling modes several security mechanisms should be applied, especially integrity protection and authentication of signaling messages in order to prevent unauthorized usage of resources and to allow proper accounting. Thus, several security mechanisms can be applied and combined, e.g., using IPsec mechanisms to secure the transport of signaling messages, use of dedicated authentication and integrity protection mechanisms in the signaling protocol itself as well as integration of existing AAA solutions. 9. Acknowledgements The terms path-coupled and path-decoupled were proposed by Robert Hancock et al. in [3]. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Brunner, M., "Requirements for Signaling Protocols", draft- ietf-nsis-req-04 (work in progress), August 2002. [3] Freytsis, I., "Next Steps in Signaling: Framework", draft-ietf- nsis-fw-00 (work in progress), October 2002. [4] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [5] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. [6] Baker, F., Iturralde, C., Le Faucheur, F. and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001. [7] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [8] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000. Schelen, et al. Expires May 5, 2003 [Page 13] Internet-Draft Path-coupled / Path-decoupled Signaling November 2002 [9] Braden, B. and B. Lindell, "A Two-Level Architecture for Internet Signaling", draft-braden-2level-signal-arch-00 (work in progress), November 2001. [10] De Clercq, J., Van den Bosch, S. and A. Couturier, "An architecture for a gradual deployment of end-to-end QoS on an Internet-wide scale", draft-declercq-vsn-arch-00 (work in progress), October 2002. [11] Schulzrinne, H., Tschofenig, H., Fu, X., Eisl, J. and R. Hancock, "CASP - Cross-Application Signaling Protocol", draft- schulzrinne-nsis-casp-00 (work in progress), September 2002. Authors' Addresses Olov Schelen Operax AB Aurorum 8 SE 97775 Lulea Sweden EMail: Olov.Schelen@operax.com URI: http://www.operax.com Alban Couturier Alcatel Ets de Marcoussis R&I/ULC Route de Nozay 91461 Marcoussis CEDEX, France FR EMail: Alban.Couturier@alcatel.fr Roland Bless Institute of Telematics, Universitaet Karlsruhe (TH) Zirkel 2 76128 Karlsruhe Germany Phone: +49 721 608 6413 EMail: bless@tm.uka.de URI: http://www.tm.uka.de/~bless Schelen, et al. Expires May 5, 2003 [Page 14] Internet-Draft Path-coupled / Path-decoupled Signaling November 2002 Ruediger Geib T-Systems Nova GmbH Am Kavalleriesand 3 64295 Darmstadt Germany Phone: +49 6151 832 138 EMail: Ruediger.Geib@t-systems.com URI: http://www.t-nova.de Olivier Dugeon France Telecom R&D 2 Avenue Pierre Marzin F-22307 Lannion France Phone: +33 296 05 2880 EMail: Olivier.Dugeon@francetelecom.com Schelen, et al. Expires May 5, 2003 [Page 15] Internet-Draft Path-coupled / Path-decoupled Signaling November 2002 Full Copyright Statement 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Schelen, et al. Expires May 5, 2003 [Page 16]