Internet Draft Document: draft-schelen-nsis-opopsig-00.txt Alban Couturier Expires: December 2002 Alcatel Olov Schelen Operax June 2002 On path and off path signaling for NSIS Status of this Memo This document is an Internet-Draft and is subject to 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 The NSIS Work group will develop the requirements, architecture and protocols for the next IETF steps on signaling. Two approaches about the signaling model have been discussed: on-path and off-path. This draft provides a conceptual comparison between on-path and off-path 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. Schelen and Couturier Expires December 2002 [Page 1] INTERNET-DRAFT On path and off path signaling for NSIS June 2002 Table of Contents Status of this Memo 1 Abstract 1 Conventions used in this document 2 1. Introduction 2 2. Terminology 2 3. On-path signalling 3 4. Off-path signalling 4 5. A Mixed solution 6 6. Conclusion 9 7. Security Considerations 9 8. References 9 9. Author's Addresses 10 10.Full Copyright Statement 10 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]. 1. 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: on-path and off-path. 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 on-path and off-path flavors of the protocol. 2. Terminology QoS Initiator (QI): NSIS entity responsible for generating the QSCs for traffic flow(s) based on user or application requirements and signaling them to the network as well as invoking local QoS provisioning mechanisms. This can be located in the end system, but may reside elsewhere in the network.[2] QoS Controller (QC): NSIS entity responsible for interpreting the signaling carrying the user QoS parameters, optionally inserting/ modifying the parameters according to local network QoS management Schelen and Couturier Expires December 2002 [Page 2] INTERNET-DRAFT On path and off path signaling for NSIS June 2002 policy, and invoking local QoS provisioning mechanisms. Note that the QoS controller might have very different functionality depending on where in the network and in what environment they are implemented.[2] QoS Service Classes (QSC): Specification of the QoS requirements of a traffic flow or aggregate. Can be further sub-divided into user specific and network related parameters. [2] 3. On-path signaling 3.1. Description of on-path signaling On-path signaling refers to the situation where signaling is bound to the data path of the IP flow to be signaled. This is typically the case of RSVP [3]. The advantage of on-path signaling is that the equipments along the data path can receive configuration data just by receiving and forwarding signaling packets, following the traditional routing mechanisms. In case the equipments to be configured are along the path, this mechanism is considered the simplest. It does not require additional configuration, as the signaling hops are the same as the IP forwarding ones. 3.2. Issues of on-path signaling 3.2.1 Signaling unaware clouds and signaling continuity The on-path signaling relies on the fundamental assumption that packets are all routed the same way, based on the IP destination address. This will be called in this draft the "traditional IP routing". Traditional IP routing is of course predominant in the Internet today, therefore on-path signaling benefits from deployment advantages. In case of an IP cloud which is signaling unaware (e.g. because of over-provisioning), the signal can go through the cloud transparently, like a normal IP packet. At the egress router of that cloud, the 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 an on-path signaling carrier. This situation may suffer from threats in several deployments. QoS routing, traffic engineering or load balancing technologies may route differently flows than in the traditional IP routing model. In these cases, a signaling unaware cloud is not anymore a signaling carrier, as nothing assures it will forward the signal at the same place it will forward the dataflow. Then, signaling unaware clouds can break the on-path signaling, and can simply introduce bad state installations downstream. Schelen and Couturier Expires December 2002 [Page 3] INTERNET-DRAFT On path and off path signaling for NSIS June 2002 3.2.2 Integration with policy servers An issue is raised when states must be installed or processed by hosts that are not located on the data path. This happens for example when a server hosting user profiles participates in the admission control procedure. The current solution is to outsource the signaling processing via the COPS interface [4]. As policies are more and more important especially in case of peering between several ISPs, policy servers are expected to be extensively involved in signaling processing. The on-path model does not easily provide a natural interface between domain boundaries (e.g., client-provider, provider-provider). Accountable services (e.g., max bandwidth with ensured QoS, max number of concurrent calls, variations over time of day and day of week, advance reservations, price profiles) require installing states in policy servers that are located off-path. This typically requires interaction between client and QoS controller (policy server) that is not easily supported by on-path signaling. 3.2.3 Separation of signaling processing and 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 [5], or RSVP over diffserv [6] [7] 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 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. Off-path signaling 4.1. Description of Off-Path signaling Off-path signaling refers to signaling which does not follow the IP flows to be signaled. This happens either when signaling is not initiated by end hosts, or when signaling is directed to QoS controllers that are not on the data path. In this model, the IP destination address of the signaling is separated from the destination address flow(s) for which resources are requested. Schelen and Couturier Expires December 2002 [Page 4] INTERNET-DRAFT On path and off path signaling for NSIS June 2002 4.2. Benefits of Off-path signaling 4.2.1 Independence of signaling plane with forwarding plane By nature, off-path 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. 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 QoS initiators and QoS controllers. Therefore, upgrading routers to a new signaling standard is not necessary to support off-path signaling. Off-path 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 a better 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. 4.2.2 Flexibility in signaling entity placement 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 QI, as they are responsible for the service sessions. These kind of QIs could use an off-path signalling protocol to interact with a QC. Possible alternatives could be to deploy NSIS stacks and QSC aware applications in every VoIP/multimedia terminal along with synchronization with the network applications based on signaling outsourcing , or to insert on-path signaling proxies. These solutions require complex deployments that can be avoided thanks to the placement's flexibility associated to the off-path model. 4.2.3 Support for non-traditional routing As seen in the on-path signaling section, a network based on non- traditional routing, because of e.g. traffic-engineering, may deviate the signaling from the flow to be signaled, and thus may not be a signaling carrier. Therefore, a network based on non-traditional IP routing must implement a signaling carrier function in order to be a decent transit network between QI and QR. This function can be implemented in the routers, or in off-path QoS controllers. In the later case, alternative routing rules that are implemented in the network must be replicated in the QoS controllers. Schelen and Couturier Expires December 2002 [Page 5] INTERNET-DRAFT On path and off path signaling for NSIS June 2002 4.3. Issues of off-path signaling 4.3.1 Synchronization with routing tables In addition to admission control or state installation, an off-path QoS controller must determine where to route the signaling, depending on where the flow to be signaled is routed. In case of on-path signaling, the signaling packet is ignored or processed, and then routed as a normal packet. An off-path QoS-controller 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 a router but passive in the sense that no routes are advertised and no peering is performed with routers in other domains. 4.3.2 Admission control In case the QoS controller's customers are not trusted, off-path signaling may involve configuration of edge traffic conditioners in order to do policing at the edges. Efficient standard approaches should be defined for this. Various standards and proprietary interfaces can be supported by a QoS controller. SNMP, or COPS are two IETF standards that can be used to interface with edge routers. It has to be noted that remote configuration of network elements may have a performance issue. 5. A Mixed solution Up to this point, the draft presents the advantages and issues of on-path and off-path signaling, as it has been discussed in the mailing list. The aim of this chapter is to advocate for a non-exclusive solution. 5.1. On-path and Off-path models inter-working A strategy for NSIS could be to focus on a particular model, the preferred one being on-path, and refuse or postpone the work concerning off-path. As both model 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. Schelen and Couturier Expires December 2002 [Page 6] INTERNET-DRAFT On path and off path signaling for NSIS June 2002 For example, the following situation should be possible: - One ISP may use an application-level off-path solution to provide services to its customers, while continuing the signaling on-path towards a peering domains that adopt traditional IP routing. This situation corresponds to the gatekeeper/SIP proxy/content server initiating a reservation. - One ISP may prefer on-path 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 neighbouring domains using off-path signaling. - At the border between a domain following the traditional IP routing with another domain which adopts e.g. traffic engineering techniques, the on-path signaling can be extracted and then continued off-path. These situations need a "signaling gateway router" implementing on-path signaling on some of its interfaces and off-path 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 flavors - on-path and off-path - of the same signaling is a reasonable choice. The following sections will explain the differences between these two flavors. 5.2. Data objects for on-path and Off-path signaling 5.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 on-path signaling for a micro-flow, the destination address of the flow must be the same than 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 on-path model, the signaling carries a flow specification that can contain a destination address or prefix. In the off-path case, the signaling carries a flow specification that must always contain a destination address or prefix, as the packet header contains in destination address the IP address of the next QoS controller. Schelen and Couturier Expires December 2002 [Page 7] INTERNET-DRAFT On path and off path signaling for NSIS June 2002 5.2.2 Ingress address In the off-path model, it is necessary to specify in the request what is the entry point of a flow in the domain controlled by a QC. 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 off-path signaling, the requests sent to a QoS controller 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 QoS controllers the upstream QoS controller must find out which incoming interface of the downstream domain that will be used. To summarize, the differences between an on-path signaling and its associated off-path version are: - the addition, if not already mandatory in on-path, of the IP destination address/prefix in the flow specification - the addition of an ingress address object in the flow specification. It is expected that a signaling gateway router receiving an on-path signaling message, after having processed it, will add the destination address (if needed) and the ingress address in the message, and forward it. 5.3. Protocol concepts On-path 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 on-path 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. An off-path 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 on-path and off-path models should use pair-wise handshake between QoS controllers involved in providing e2e service. Early on-path protocols (e.g., RSVP) did signal along the path without handshake for reliable delivery between adjacent neighbors, but it has been identified [8] that such a model has problems meeting required state maintenance. Schelen and Couturier Expires December 2002 [Page 8] INTERNET-DRAFT On path and off path signaling for NSIS June 2002 6. Conclusion Both on-path and off-path 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 draft proposes to specify in NSIS one protocol that has one on-path and one off-path flavor. The identified differences between the two variants are one or two protocol objects defining ingress and destination address for requests. The off-path flavor may be implemented at application layer, while the on-path flavor most likely would be implemented as a protocol on top of IP. 7. Security Considerations TBC 8. References [1] RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [2] Brunner, M., "Requirements for QoS Signaling Protocols", draft-ietf-nsis-req-02.txt, May 2002, Work in progress [3] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) Version 1 - Functional Specification", RFC 2205, September 1997. [4] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. [5] Baker F., Iturralde C., Le Faucheur F., Davie B., "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, Septembe 2001. [6] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [7] Bernet Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "Integrated Services Operation Over Diffserv Networks", RFC 2998, November 2000. [8] Braden, R., Lindell, B., "A Two-level Architecture for Internet Signalling" draft-braden-2level-signal-arch-00.txt, Nov 2001. Schelen and Couturier Expires December 2002 [Page 9] INTERNET-DRAFT On path and off path signaling for NSIS June 2002 9. Author's Addresses Alban Couturier Ets de Marcoussis R&I/ULC Route de Nozay 91461 Marcoussis CEDEX, France Email: Alban.Couturier@alcatel.fr Olov Schelen Operax AB Aurorum 8 SE 97775 Lulea, Sweden Email: Olov.Schelen@operax.com 10. Full Copyright Statement "Copyright (C) The Internet Society (date). 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 implmentation 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. Schelen and Couturier Expires December 2002 [Page 10]