Working Group: NSIS V. Mancuso Internet Draft University of Palermo, Italy G. Bianchi University of Rome Tor Vergata, Italy N. Blefari-Melazzi University of Rome Tor Vergata, Italy Document: draft-mancuso-nsis-impl-sign-00.txt July 2004 Category: Informational Expires January 2005 Implicit Signaling over Stateless Networks 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. 1. Abstract This memo defines a mechanism for NSIS Signaling Layer Protocol (NSLP). The driving motivation is that some network domains, e.g. based on Differentiated Services data plane, might not explicit support a per-router and/or per-domain admission control rule. Hence, for such domains, explicit signaling is not a viable approach. To partially solve this issue, we suggest an admission control paradigm devised to provide ôImplicit Signalingö via data plane packet delivery operation. Implicit Signaling relies the decision to admit a new flow upon the successful and timely delivery, through the domain, of Probe packets independently generated by the NSIS initiator (NI). The key idea is to use failed receptions of Probes to discover, at the NI, that a congestion condition occurs in the network segment between NSIS initiator and NSIS Responder (NR), and to abort a reservation procedure. Since Implicit Signaling is not able to communicate per-flow traffic and QoS parameters, in principle it cannot exert a QoS control as tight as in the case of explicit mechanisms. However, it is important to notice that Implicit Signaling can indeed operate in a differentiated manner on the basis of traffic and QOS parameters, if i) Probes are marked according to the flow traffic and QoS requirements, ii) marked Probes experience a dropping behaviour according to their mark, and iii) Probe dropping is controlled Mancuso, at al. Informational ¡ Expires January 2005 1 Implicit Signaling over Stateless Networks July 2004 according to measurements taken into the core routers. Table of Contents 1.Abstract.....................................................1 2. Terminology.................................................2 3. Introduction................................................3 4. Implicit Signaling: key concepts............................5 4.1 End nodes operation........................................5 4.2 Core Routers operation.....................................6 5. Heterogeneous traffic and multiple QoS support..............9 5.1 Multiple QoS levels........................................9 5.2 Heterogeneous bandwidth requirements.......................9 6. Edge-to-edge and cross-domain Implicit Signaling operation.10 6.1 Explicit to Implicit Signaling mapping....................11 6.2 Implicit-to-Implicit Signaling mapping....................14 7. Deployment considerations..................................15 8. Security considerations....................................15 9. References.................................................16 10 Author's Addresses.........................................17 11 APPENDIX A.................................................18 12 APPENDIX B.................................................19 13 APPENDIX C.................................................24 14 Full Copyright Statement...................................28 2. Terminology 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. This document uses terms defined in [1]. Furthermore, these following terms are often used in this document: - NSIS Entity (NE): The function within a node, which implements an NSIS protocol. In the case of path-coupled signaling, the NE will always be on the data path. - NSIS Forwarder (NF): NSIS Entity between a NI and NR, which may interact with local state management functions in the network. It also propagates NSIS signaling further through the network. - NSIS Initiator (NI): NSIS Entity that starts NSIS signaling to set up or manipulate network state. - NSIS Responder (NR): NSIS Entity that terminates NSIS signaling and can optionally interact with applications as well. - Flow: A traffic stream (sequence of IP packets between two end systems) for which a specific packet level treatment is provided. The flow can be unicast (uni- or bi-directional) or multicast. For multicast, a flow can diverge into multiple flows as it propagates Mancuso, at al. Informational ¡ Expires January 2005 2 Implicit Signaling over Stateless Networks July 2004 toward the receiver. For multi-sender multicast, a flow can also diverge when viewed in the reverse direction (toward the senders). - Data Path: The route across the networks taken by a flow or aggregate, i.e., which domains/subdomains it passes through and the egress/ingress points for each. - Signaling Path: The route across the networks taken by a signaling flow or aggregate, i.e., which domains/subdomains it passes through and the egress/ingress points for each. - Receiver (DR or R): the node in the network, which is receiving the data packets of a flow. - Sender (DS or S): the node in the network, which is sending the data packets of a flow. - Policy rule: In general, a policy rule is "a basic building block of a policy-based system. It is the binding of a set of actions to a set of conditions - where the conditions are evaluated to determine whether the actions are performed" [2]. In this context the condition is the network congestion level with reference to a specific aggregate of flows; actions to be taken are connection admission or rejection. - DiffServ: the differentiated services approach to providing quality of service in networks by means of a small, well-defined set of building blocks from which a variety of aggregate behaviors may be built. Traffic Class octet, is used to mark a packet to receive a particular forwarding treatment, or per-hop behavior, at each network node. - Domain: an interconnected set of network nodes owned by the same network provider, and supporting a set of network services. Each domain is connected to the outer network through selected routers. 3. Introduction This draft focuses on mechanisms that can be used in order to enable a service provider to offer support for QoS in a stateless network domain. Since, by definition, no states (neither distributed in the core routers, nor centralized in control entities such as Bandwidth Brokers) can be handled nor maintained in such a kind of networks, NSIS entities can only be placed at the edge of the stateless domain, and no resource reservations can be performed over internal nodes. This means that, in a stateless domain, core routers are not able to set apart resources for a specific flow, nor manage it separately from the others: no NSIS forwarder can be placed in the core of a stateless domain. Following the approach proposed in [3], the NSIS protocol suite is layered into a signaling transport layer and a signaling application layer. The former (NTLP) is a generic transport protocol, and it is Mancuso, at al. Informational ¡ Expires January 2005 3 Implicit Signaling over Stateless Networks July 2004 signaling independent, since no correlations arise with specific signaling methods. The latter (NSLP), on the contrary, contains mechanisms specific of a signaling application. A different NSPL is needed to support each specific signaling application, while a single NTLP gives support to any kind of NSLP. QoS mechanisms are specific of NSLP protocols, while NTLP provides a simple message transfer service. Thus, the complexity of the signaling is mainly located in the NSIS signaling application layer. The Internet scenario is characterized by heterogeneous networks and deeply different administrative domains. Given a specific data path, it is very frequent that a significant number of nodes belonging to that path are not QoS aware. Furthermore, while access network segments are often QoS aware and stateful, it is very common to go across stateless network domains in the core part of the network. The solution we envision consists in an idea that somehow resembles what TCP congestion control technique does. The difference from TCP is that ôwe apply the control to admission controlö. In what follows, we refer to the proposed solution with the name ôImplicit Signalingö. The idea is to try to estimate the network congestion level by means of implicit information such as lack of reception of acknowledgements corresponding to the transmission of particular probing packets. In order to obtain significant performance enhancements, Probes should experience a worse treatment than normal data packets. This consideration has a twofold impact: 1) Information packets and Probes must be differentiated, and intermediate routers should distinguish between Data (Information) and Probes; 2) routers should enforce worse performance on Probes, and enforce anticipated Probe dropping when congestion situations arise. The possibility to deploy Implicit Signaling is thus related to the capability of routers to locally take decisions about the degree of congestion in the network, and suitably drop Probe packets when congestion conditions are detected. Note that the two above mentioned conditions are fully supported by the DiffServ framework. As discussed in [4], and here reviewed in Appendix A, DiffServ has defined a key per-hop-behavior called Assured Forwarding (AF) [5]. Packets belonging to an AF class experience up to three levels of dropping behaviors, where the dropping probability depends on aggregate measurements taken on the AF class. Hence, an AF class defines what we call a "paired" PHB, meaning that the performance experienced by traffic belonging to the different drop levels in the AF class are related each other. Thus, due to its "paired" behavior, the AF class results to be a natural candidate to deploy Implicit Signaling. It is sufficient to mark Probes with a low-priority drop level, mark accepted data traffic as high-priority, and leave the network routers to exert dropping on these Probes on the basis of aggregate measurements taken on the whole AF class. Mancuso, at al. Informational ¡ Expires January 2005 4 Implicit Signaling over Stateless Networks July 2004 4. Implicit Signaling: key concepts In this Section, for convenience of presentation, we assume that i) a single QoS level is considered across the domain, ii) all flows have the same traffic specifications in terms of peak and average bandwidth requirements, and iii) a flow is being set-up in a single network domain and the admission control procedure is managed by the end-nodes operation (transmitter and receiver). These three assumptions will be removed in the next Sections. Implicit Signaling has been adopted to control network congestion since the introduction of TCP congestion control in 1986. The idea of Implicit Signaling is to allow the network endpoints to autonomously determine whether congestion occurs along the network path, and to react accordingly. Congestion conditions are discovered at the end points by analyzing packet losses. Upon congestion within a network node, packets are lost, and this information is implicitly conveyed to the end nodes. 4.1 End nodes operation The idea is to convey the Y/N decision regarding the admission or rejection of a newly incoming flow via the successful or failed delivery of a data plane packet. Let us consider the setup of an "uplink" (source to destination) mono-directional flow. When a user terminal requests a connection with a destination terminal, the Source Node starts a Probing Phase, by injecting in the network in principle just one Probe Packet. Meanwhile, it activates a probing phase timeout. If no response is received from the destination node before the timeout expiration, the source node enforces rejection of the connection setup attempt. Otherwise, if a Feedback packet is received in time, the connection is accepted, the probing phase is terminated, and control is given back to the user application which starts a Data Phase, simply consisting in the transmission of Information packets (Data). The role of the Destination Node simply consists in monitoring the incoming IP packets, intercepting the ones labeled as Probes, reading their source address, and, for each incoming Probe packet, just relaying with the transmission of a Feedback packet, if the destination is willing to accept the set-up request. The only mandatory requirement is that Probes and Information packets are labeled with different values of the DiffServ codepoint (DSCP) field in the IP packet header. This enables DiffServ routers to provide different forwarding methods to Probes and Information packets (see Section 4.2). In this case, the Feedback packet shall be labeled as an Information packet (i.e., prioritary). Probing packets are not required to explicitly carry any information describing the characteristics of the associated data traffic (e.g. peak bandwidth).However, since probing packets may be parsed at the Mancuso, at al. Informational ¡ Expires January 2005 5 Implicit Signaling over Stateless Networks July 2004 Destination Node, they may contain application-level signaling information. Note that the described operation is trivially extended to provide setup for bidirectional connections. In such a case, the destination node will simply relay with a Probe packet instead than with a Feedback packet. A Feedback will be ultimately sent back by the source node upon reception of the destination Probe (to close the three way connection setup handshake ¡ independent probing mechanisms are clearly needed to test both uplink and downlink network paths, which generally differ). Finally, Implicit Signaling can be adapted to support "downlink" (destination to source) flows. The source node needs to issue a Trigger Packet to drive (by means of application-level protocol information, contained in the Trigger Packet payload) the destination node to start a Probing Phase on its own. 4.2 Core routers operation In order to support Implicit Signaling in a performance effective manner, network routers must be able to recognize Probe packets from Information packets. This can be accomplished on the basis of the packet labels (such as the DSCP tag). Thanks to the above described end nodes operation, packets labeled as Information are generated by flows that have successfully passed an admission control test. Conversely, packets labeled as Probes are generated by flows that are requiring an admission control decision. Core routers are in charge of deciding whether to accept or reject new incoming flows, on the basis of run-time measurements taken on the traffic aggregate labeled as Information (i.e., on the accepted traffic). This problem, namely Measurement Based Admission Control (MBAC), has been widely studied in the literature. See e.g. [6] and related references, for a number of proposed algorithmic solutions and the related performance evaluation. Implicit Signaling comes into play when we resort on Probe losses to communicate the end nodes the result of the admission control decision locally and independently taken at each network router. The complete core router operation is illustrated in Fig. 1. For convenience of presentation, we assume that the router handles only admission controlled traffic. Other traffic classes (e.g., best-effort traffic) can be handled by means of additional queues, possibly with lower priority. At each router output port, two distinct queues are implemented, one for Data packets, i.e. belonging to flows that have already passed an admission control test, and one for probing traffic. Packets are dispatched to the respective buffers according to the Probe/Data DSCP tag. The core router measures the aggregate accepted traffic. On the basis of the running traffic measurements, the router enforces a Decision Criterion, which continuously drives the router to switch between two states: ACCEPT and REJECT. When in the ACCEPT state, the Probing Mancuso, at al. Informational ¡ Expires January 2005 6 Implicit Signaling over Stateless Networks July 2004 -------------------------- ------ | / \ Data Queue |/ Server \----------- |\ / | -------------------------- \ / | || ------ | || Measure | \/ | ------------------------ --------\/---------- | Decision Criterion | | | Packets | Controller Module | | Priority Server |--------> ------------------------ | | || -------------------- || /\ || Accept/Reject Switch | \/ | ------------------------- ------ | | / \ | Probe Queue |/ Server \----------- |\ / ------------------------- \ / ------ Figure 1: Core router operation queue accommodates Probe packets, and serves them according to the described priority mechanism. Conversely, when the router switches to the REJECT state, it discards all the Probing packets contained in the Probing queue, and blocks all new Probing packets arriving. In other words, the router acts as a gate for the probing flow, where the gate is opened or closed on the basis of the traffic estimates. The simplest decision criterion is to run-time provide a filtered and smoothed measure of the bandwidth used by the accepted traffic, and drive the router to switch from the ACCEPT to REJECT states when the bandwidth consumed gets above or below a pre-defined threshold. In order to avoid traffic fluctuations, smoother dropping mechanisms can be considered. For example, the decision criterion may drive the router to switch between three states: ACCEPT, REJECT and INTERMEDIATE, according to whether the measured bandwidth is below, above or between two predefined bandwidth thresholds. When in the INTERMEDIATE state, Probe packets can be lost according to a probabilistic dropping criterion, where the probability of dropping a Probe packet increases as long as the measured bandwidth gets closer to the upper threshold. Performance investigation for such a policy has been carried out in [7]. The described mechanism is independently and locally run at each core router. It results scalable as i) it does not require any form Mancuso, at al. Informational ¡ Expires January 2005 7 Implicit Signaling over Stateless Networks July 2004 of centralized control: the whole operation is fully distributed: the procedures have a local scope and each network device operates autonomously; ii) it is purely based on data-plane operation (forwarding/dropping packets); iii) it does not require the routers to discriminate among flows and/or to store per-flow state information in the routers (only aggregate measurements are taken), and iv) it does not require the routers to parse the contents of the Probe packets. The consequence of the proposed mechanism is that it provides an Implicit Signaling pipe to the end points, of which the network remains unaware. Each router is locally in charge of deciding, on the basis of its own criteria, whether it can admit new flows, or it is congested. The internal router decision is summarized in the router state, and it is implicitly advertised to the end points (whose flow setup path crosses the considered router) by letting Probes cross through or being blocked by the router. With reference to the performance achievable, it is easy to conclude that the level of QoS support provided depends on the degree of effectiveness of the Decision Criterion implementation. Several Measurement-Based mechanisms [6,8] have been described in the literature and may be applied. Still regarding the achievable performance, it is easy to see that the described mechanism cannot be designed to be as robust as a state-based admission control scheme. In fact, a decision whether to admit or reject a flow is based on the current aggregate bandwidth measures, and thus it can only partially account for the future effect of the newly admitted flow. In more details, assuming that all flows are homogeneous in their bandwidth requirements, the ACCEPT/REJECT bandwidth thresholds can be configured to guarantee a sufficient bandwidth margin to accommodate a newly admitted flow. However, it is easy to see that this is not sufficient, especially in the case of bursty admission control requests. In fact, when the router switch is in the ACCEPT state, several new flows can be simultaneously admitted, and the effects of these newly admitted flows will not be immediately accounted for, in the run-time measurements, until they start to steadily transmit, and until their effect will be reflected in the filtered and smoother bandwidth aggregate measurement. As discussed in [6], this "transient" effect due to newly activating flows may lead to performance impairments to the MBAC operation. This drawback may be mitigated either by attempting to keep into account the transient effect of forwarded Probes or by conservatively design the bandwidth thresholds to leave some margin for temporary overflows. An example of the first strategy is to temporarily lower the admission thresholds, according to the number of forwarded Probes [9], i.e. the number of new flows which are expected to arrive. Although a detailed discussion of such a possible approach is out of the scopes of the present draft, we just remark that the price to pay is to rely on a more complex implementation of the router operation as it is not sufficient to Mancuso, at al. Informational ¡ Expires January 2005 8 Implicit Signaling over Stateless Networks July 2004 count the number of forwarded Probes, but it is also necessary to distinguish Probes belonging to different flows. Finally, as an implementation note, we remark that there is actually no need to have two separate queues for Information and Probe packets, as both packet types can be integrated in a single buffer managed via a RIO policy (e.g., as in the case of the DiffServ AF class - see Appendix A). 5. Heterogeneous traffic and multiple QoS support In this Section we discuss and remove assumptions (i) and (ii) adopted in the previous Section 4 for convenience of presentation. We still assume through this Section that a single network domain is considered, and that the end nodes involved in the admission control rule are the transmitting and receiving end-points. 5.1 Multiple QoS levels The described approach can be trivially extended to support multiple QoS levels. It is sufficient to implement a separate set of paired (Information, Probe) packet labels per each pre-determined QoS level, and independently manage the related decision criteria. Specifically, when the source node wants to set up a flow, it firstly selects the domain QoS level Qi, which best matches the flow QoS requirements. Then, it proceeds by sending a packet marked as Probe for the QoS level Qi. Each router manages a separate pair of queues for each QoS level, and exerts a dropping behaviour on Probes for the QoS level Qi on the basis of the measurements taken on the relevant aggregate traffic for QoS level Qi. 5.2 Heterogeneous bandwidth requirements A more interesting issue is related to the extension of the proposed approach to manage traffic flows with highly different bandwidth requirements. In fact, the described Implicit Signaling operation does not require a core router to be able to parse the contents of a probing packet. Hence, in terms of router operation, the decision whether to admit or reject a flow does not take into account the amount of resources (e.g. peak or average bandwidth)required by the incoming flow. However, a possible solution is to partially transfer the semantics of the admission control request down to the data plane by using a differentiated set of Probes for different traffic profiles. A possible idea is to use, for a given QoS level Qi, a single DSCP for admitted traffic, and multiple DSCP marks for Probes. In [7] we have detailed the case in which three DSCPs are reserved for the Implicit Signaling operation (where the value three is related to the number of drop levels available in a DiffServ AF class). Traffic whose peak (or average) bandwidth requirements is above a given value use a Mancuso, at al. Informational ¡ Expires January 2005 9 Implicit Signaling over Stateless Networks July 2004 different DSCP label for their Probes. Consistently, network routers start dropping these latter Probes in advance with respect to the "normal" Probes. The rationale is that flow whose bandwidth requirements are "large" need to be blocked in advance with respect to traffic whose bandwidth requirements are "small". Clearly, the obvious drawback of the described approach is that the number of packet labels supported by a domain might be extremely small with respect to the large variety of possible traffic descriptors. However, the described approach at least provides a rough mechanism to take into account different traffic profiles, without abandoning the advantages provided by the Implicit Signaling approach. 6. Edge-to-edge and cross-domain Implicit Signaling operation The Implicit Signaling description given in Section 4 was based on the simplified assumption of end-to-end admission control operation, where the end points of the admission control procedure were the two end hosts, and where the core routers involved in the admission control procedure were considered to belong to the same network domain. To make Implicit Signaling deployable, a necessary extension is to localize the Implicit Signaling operation into the network domains that are not expected to deploy alternative state-based admission control forms, meanwhile allowing to extend the Implicit Signaling concepts to make them compatible with explicit signaling approaches adopted in network domains involved in the admission control operation. A general framework which allows coexistence of implicit and explicit signaling is to decouple the admission control in the following elements: 1. Intra-domain resource reservation mechanisms. These mechanisms should be limited to provide admission and congestion control functions whose scope is limited to a single administrative domain, and whose design is related to the specific requirements of the considered domain (e.g. a radio access network, a core backbone, a small campus LAN, etc). The degree of QoS support provided within each domain will depend on the tightness of control that the edge to-edge mechanism will be capable to support. Schemes ranging from explicit per-flow resource reservation mechanisms (such as RSVP), down to aggregate forms of traffic control (e.g. via measurement based mechanisms, such as the one of Implicit Signaling) should be allowed to independently operate in different domains. The ultimate goal is that each domain should be placed in the ideal condition of determining the suitable throughput/QoS support tradeoff within the domain. Mancuso, at al. Informational ¡ Expires January 2005 10 Implicit Signaling over Stateless Networks July 2004 2. Inter-domain signaling mechanisms. To allow heterogeneous domains to exchange basic control information, a cross-domain signaling procedure should be deployed. Our view of such a cross domain signaling exchange is twofold: a: one possibility is to deploy a novel standard to allow domains to exchange control information (e.g. whether a flow can be admitted in the considered domain). The drawback of such a solution is that the format and the contents of these control packets needs to be standardized, and this may limit the timely deployment of this cross-domain mechanism. b: a much more simple, and in our opinion, appealing possibility, is to allow the coexistence of the above mentioned cross-domain signaling protocol under development with an IMPLICIT cross-domain signaling scheme, based on drop of signaling packets and thus usage of the principle of packet loss as a way to notify congestion. The rationale is that QoS provisioning in the Internet should be outlined following an evolutionary approach. That is, each individual domain should be put in the condition of independently and asynchronously upgrade its network components and management schemes to provide support for QoS. Note that intra-domain and inter-domain resource reservations are both in the scope of NSIS signaling layer protocols (NSLP). In both cases, a common NTLP should provide common transport facilities to NSIS entities, while different NSLPs should be suitably used, and possibly nested by NFs, in different scenarios (note that, as to the nested protocol, a NF triggering the intra-domain procedure can also be considered a NI, as well as the NF connecting with the following domain, would act like a NR). NSLP translation will be needed in order to set up a reservation through a path crossing several administrative domains, with possibly different network architectures. Note that the case of a stateless domain can be seen by NSIS forwarders like a single virtual link between two NSIS nodes: the NSLP is aware of the behavior of such a virtual link and operates in a suitable way (e.g., a DiffServ cloud can be seen like a link to Probe with Implicit Signaling mechanisms - a similar approach was considered also in the IntServ operation across DiffServ [10]). 6.1 Explicit to Implicit Signaling mapping Consider, as a concrete example, the scenario depicted in figure 2. Here, the source to destination path comprises three different domains, namely A, B, and C, each running a possibly different intra-domain reservation protocol (namely RP1, Implicit Signaling, and RPX). Each reservation protocol has its own scheme. For simplicity of presentation, we assume that domain border routers coincide (e.g. R2 functionally acts as a edge router for both Domain A and B - though in practice these functionalities will be split in the two involved edge routers). Mancuso, at al. Informational ¡ Expires January 2005 11 Implicit Signaling over Stateless Networks July 2004 __________ __________ __________ / \ / \ / \ / \ / \ / \ +---+ +--+ +---+ +---+ +--+ +---+ |SRC|--|R1| Domain A | R2| Domain B | R3| Domain C |R4|--|DST| +---+ +--+ (RP1) +---+ (Impl-Sign)+---+ (RPX) +--+ +---+ \ / \ / \ / \__________/ \__________/ \__________/ Figure 2: Multi-domain scenario The distinction between inter-domain and intra-domain resource reservation mechanisms is particularly effective in the case of Implicit Signaling. In fact, a source node which wants to set up a QoS flow sends an admission control request to the node, in the first domain, in charge of processing the reservation request (in the example, node R1 in Domain A). The semantics related to the request (traffic specification, QoS requirements) are contained in the signaling packet. This signaling packet carries both application-level information to be used at the destination node, as well as information upon which intra-domain reservation protocols rely on for performing their reservation tasks. Node R1 converts these QoS semantics in procedures supported by the specific intra domain resource reservation mechanism, and triggers the specific edge-to-edge reservation mechanism RP1 running through Domain A. At the end of the reservation procedure, if the domain is capable of admitting the flow, then the signaling packet is forwarded out of the domain by the egress node and forwarded to edge node R2 in the adjacent domain. Otherwise, it is dropped. Assume that Domain B does not support any intra-domain explicit signaling mechanism, but it is capable to support the Implicit Signaling operation described in the previous Sections. Edge node R2 is thus in charge to: - read the contents of the explicit signaling message; - find the best match (according to the QoS requirements ¡ see Section 5.1 - and to the traffic specification - see Section 5.2) with the Probe tagging supported in the domain; - tag the signaling message as a Probe and send it across the network domain; - in case of successful delivery, edge router R3 will intercept the signaling packet. It will send a Feedback packet to R2 in order to complete the Implicit Signaling exchange, and will invoke the intra-domain resource reservation mechanism for Domain C (if any). Note: if the end-to-end signaling path is expected to provide an ack on the same forwarding path, router R2 may wait for ack reception and piggy-back the feedback information necessary for the completion of the Implicit Signaling loop over the end-to-end ack. Mancuso, at al. Informational ¡ Expires January 2005 12 Implicit Signaling over Stateless Networks July 2004 Task of the Domain B administrator is to determine a proper matching between the information delivered into the inter-domain signaling packet and the DSCP marks - Probe(s) and Information - used inside the domain. Finally, the signaling packet arrives at the ingress node of Domain C. Here, the ingress node recognizes that the packet is for signaling, but it finds that the packet does not carry information useful for the reservation protocol RPX (i.e. the packet and even the relevant DiffServ codepoint is incompatible with this domain inner procedures). Therefore, Domain C can decide to: a: run a "generic" (e.g. un-parameterized) edge-to-edge signaling procedure; b: drop the packet (i.e. drop the entire flow). c: simply forward the packet, with no admission control, on a best effort basis. In case of end-to-end reservation procedures with receiver-initiated resource reservation (e.g., this is the case of RSVP, in which resources are reserved by means of a RESV message, sent by the destination node as a feedback for the PATH message sent by the source node), the Implicit Signaling operation can also be triggered by the reception of the message carrying the reservation indication (e.g., the RESV message in the RSVP example) in the download direction. In this case, R2 has to transparently forward uplink signaling messages; instead, R2 has to parse downlink signaling, store end-to-end signaling messages and start a probing phase with (possibly dummy) Probe packets in the uplink direction. If this independent intra-domain signaling session succeed, then the stored end-to-end signaling message is forwarded in the downlink direction, inside Domain A. Although the above example is very loose, and several problems need a thorough investigation, nevertheless it appears that such an Implicit Signaling approach can be the "glue" for the coexistence of highly heterogeneous edge-to-edge reservation mechanisms. Moreover, note that the outlined approach allows the coexistence of domains running a reservation protocol with best effort domains. Clearly, the QoS provisioned to the considered end-to-end flow will be bottlenecked by the worst case domain. But in the same time, domains that run a reservation mechanism are capable of limiting the traffic admitted, and thus locally guaranteeing QoS support. A thorough understanding of this latter issue is of importance. The cross-domain reservation scheme described above is not necessarily aimed at providing an end-to-end QoS support or performance guarantees. Conversely, it is devised to guarantee each domain that the performance encountered by packets crossing the given domain are kept under control (depending on the degree of tightness of the reservation protocol adopted). In other words, our view of the Mancuso, at al. Informational ¡ Expires January 2005 13 Implicit Signaling over Stateless Networks July 2004 performance provided is domain-centric, rather than an end-to-end guaranteed performance view. Possibly, suitable routing schemes and SLAs can find a path that comprises only QoS aware domains. Note that this is line with the way of operation of other functions in the Internet (e.g. routing), which allow different domains to adopt different schemes. 6.2 Implicit-to-Implicit Signaling mapping Most interesting is the case of two adjacent domains, both relying on Implicit Signaling. In fact, to extend the per-flow Implicit Signaling approach, it is sufficient to provide a DSCP to DSCP matching at the interconnection node. ___________ ___________ / \ / \ / \ / \ | +----+ | | Domain A | R2 | Domain B | | (Impl-Sign) +----+ (Impl-Sign) | \ / \ / \___________/ \___________/ Figure 3: Implicit to Implicit Signaling mapping Specifically, consider the case illustrated in the figure 3, and assume that the QoS classes supported in Domains A and B are different, either in their number as well as in the supported QoS levels. Via external agreements (where the QoS level semantics are considered), Domain B may determine a "best matching" between Probe labels used in Domain A and corresponding Probe labels used in Domain B. A corresponding matching for information labels is also provided. This translates into a simple DSCP to DSCP table, according to which packets incoming from Domain A are labeled when forwarded through Domain B. If performed properly, this DSCP to DSCP marking has several important properties. First, Probes in Domain A remain Probes also in Domain B. This implies that a per-flow admission control request in Domain A is propagated, with no need to parse the content of the signaling packet, also through Domain B. This allows to extend per-flow admission control even through domains connected at gigabit speed, with no need to invoke higher layer entities which would be hardly scalable. Second, the domain administrators may rely on a loose matching between QoS levels across different domains. This implies that the QoS model internally deployed in each domain does not need to be the same across different domains. In other words, the extension of the Mancuso, at al. Informational ¡ Expires January 2005 14 Implicit Signaling over Stateless Networks July 2004 Implicit Signaling does not automatically implies an extension of the same QoS semantics (which are agreed offline) across different domains. 7. Deployment Considerations As discussed in Appendix A, Implicit Signaling is suited to be deployed over DiffServ network by using the AF specification. However, commercial routers do not typically allow to configure the dropping behavior of AF drop levels via bandwidth measurements. In fact, they typically determine the dropping probability via (filtered) measurements of the queue size and RED/RIO policies. We have carried out some early simulations [11] as well as, more recently, some preliminary measurements to see how effective is the support of Implicit Signaling over available AF implementations. Results show that it is possible to achieve a significantly better than best effort performance level, when the dropping threshold for the Probe packets is set to a very low queue occupancy level (e.g. just 1 packet). However, a tight QoS control requires to be able to drive Probe losses through bandwidth measurements in order to be able to start dropping Probes well before queues start to build up. Protecting Implicit Signaling from possible route changes, due to the eventual dynamics of routing protocols, is a task of the NSIS transport layer protocol (see the General Internet Messaging Protocol for Signaling proposed in [12]); we can think to enhance NTLP protocols with additional probing features, in order to periodically send packets after the setup of a flow to "refresh" both the inter-domain and end-to-end path. On the other side, DiffServ will be probably deployed in the core network where forwarding mechanisms such as MPLS, will limit the frequency of route changes below typical session duration. 8. Security Considerations As all admission control functions, our solution presents the risk of theft of resources through the unauthorized admission of traffic. Although, logically, user terminals are the natural nodes where the endpoint admission control should operate, this is clearly not realistic, for the obvious reason that the user may bypass the admission control test and directly send Information packets. Identity authentication and integrity protection are therefore needed in order to mitigate this potential for theft of resources [13]. Administrators are then expected to protect network resources by configuring secure policers at interfaces (e.g. access routers) with untrusted customers. Similar protections must be provided at the interface between different domains. In particular, it may be necessary to restrict the access to the DiffServ class(es) used for admission controlled traffic. For example, a DiffServ domain should re-mark packets when they come from an un-trusted adjacent DiffServ domain. In more generality, we remark that policing and conditioning Mancuso, at al. Informational ¡ Expires January 2005 15 Implicit Signaling over Stateless Networks July 2004 rules enforced at the border routers of each domain depend on the usage of the considered class within the specific domain and thus have to be accounted for in the definition of each specific Per Domain Behaviour (PDB) supporting admission control. A quite obvious security hazard is flooding the network with Probe packets. The objective is twofold. On one side, denial of service situations can be easily created, as a massive loading of the network with Probe packets prevent the setup of normal connection. On the other side, the goal might be to affect fairness: the continuous transmission of Probe packets at a rate higher than normal connection requests is a mean to gain faster access to resources when these are made available by a router along the path. This implies that some form of traffic conditioning and policing is necessary over probe streams. While it is simple to recognize an hard attack, by monitoring the Probe packets crossing an edge router (the probing traffic ¡ at most a few packets per originating connection - is minimal in normal conditions, and thus sudden increments of the probing load are suspicious), it may be not straightforward for DiffServ boundary routers to recognize smoother fairness attacks. However, note that the same fairness problem is present also in more complex reservation mechanisms, such as RSVP (malicious users can continuously require setup to increase their access possibility with respect to normal users). Finally, all the security considerations expressed in [13] apply also to our solution. 9. References [1] M.Brunner et al., "Requirements for Signaling Protocols",RFC 3726, April 2004. [2] A.Westerinenx et al., "Terminology for Policy-Based Management", RFC 3198, November 2001. [3] R.Hancock et al., "Next Steps in Signaling: Framework", DRAFT draft-ietf-nsis-fw-05.txt, October 2003. [4] G.Bianchi, N. Blefari-Melazzi: "Admission Control over Assured Forwarding PHBs: a Way to Provide Service Accuracy in a DiffServ Framework", IEEE Globecom 2001, San Antonio, Texas, USA, November 2001, pp. 2561-2565. [5] J.Heinanen, F.Baker, W.Weiss, J.Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. [6] L.Breslau, S.Jamin, S.Schenker: "Comments on the performance of measurement-based admission control algorithms", IEEE Infocom 2000, Tel-Aviv, March 2000. [7] G.Bianchi, V.Mancuso, P.Di Francesco, "An API for advanced Mancuso, at al. Informational ¡ Expires January 2005 16 Implicit Signaling over Stateless Networks July 2004 traffic control in DiffServ routers", proceeding of Net- Con'2002, Paris, France, October 2002 [8] M.Grossglauser, D.N.C.Tse: "A Time-Scale Decomposition Approach to Measurement-Based Admission Control", Proc. of IEEE Infocom 1999, New York, USA, March 1999. [9] G.Bianchi, N.Blefari-Melazzi, M.Femminella, "Per-flow QoS support over a stateless Differentiated Services IP domain", Computer Networks, Elsevier, special issue on ôThe New Internet Architecture", 2002, pp. 73-87. [10] Y.Bernet, R.Yavatkar, P.Ford, F.Baker, L.Zhang, M.Speer, R.Braden, B.Davie, J.Wroclawski and E. Felstaine, "A Framework for Integrated Services Operation Over DiffServ Networks", RFC 2998, November 2000. [11] G.Bianchi, N.Blefari-Melazzi,V.Mancuso, "Endpoint Admission Control over Assured Forwarding PHBs and its performance over RED implementations", LCNS 2170 - Evolutionary trends of the internet, Proc. of IWDC 2001 Conference, Taormina, Italy, September 2001 [12] H.Schulzrinne and R.Hancock, "GIMPS: General Internet Messaging Protocol for Signaling", DRAFT draft-ietf-nsis-ntlp-02.txt, May 30, 2004. [13] G.Huston, "Next Steps for the IP QoS Architecture", RFC2990, Nov. 2000. 10. Author's Addresses Vincenzo Mancuso DIE, University of Palermo 9, Viale delle Scienze - Parco d'Orleans 90128 Palermo, ITALY Tel: +39 091 6615 273 e-mail: vincenzo.mancuso@tti.unipa.it Giuseppe Bianchi DIE, University of Rome Tor Vergata 1, Via del Politecnico, 00133 Rome, ITALY Tel: +39 06 7259 7453 E-mail: bianchi@elet.polimi.it Nicola Blefari-Melazzi DIE, University of Rome Tor Vergata 1, Via del Politecnico 00133 Rome, ITALY Tel: +39 06 7259 7501 e-mail: blefari@uniroma2.it Mancuso, at al. Informational ¡ Expires January 2005 17 Implicit Signaling over Stateless Networks July 2004 11. Appendix A: Implicit Signaling over DiffServ Quite unexpectedly (and not as a consequence of a design criterion) the Differentiated Services Assured Forwarding PHB specification results to be perfectly suited to support Implicit Signaling deployment, which thus does not require the introduction of new PHBs, but whose deployment can be made by reusing (with different semantics) the AF classes. We recall that the Assured Forwarding PHB defines multiple DSCP with a strict precedence relation. Four AF PHB classes have been standardized, each composed of three drop levels. In what follows, we will use the notation AFxj to indicate packet marks belonging to the AF class x, with drop level j. Conforming to [5], within a class x, if i| measurement |----+ | | module | | input | +--------------+ | +------------+ output ----->| || |->| FIFO queue |-------> | \/ | +------------+ |AFx2 +--------------+ | +----->| AFx2 dropper |----+ +--------------+ Figure 4: logical handling of an AF class x A measurement module is devised to run-time measure the aggregate AFx1 traffic. The measurement module depicted in the figure does not interact with the AFx1 packets forwarding, i.e., these packets are forwarded to the FIFO buffer placed at the output regardless of the measurements taken. On the basis of such measurements, this module triggers a suitable dropping algorithm on the AFx2 traffic. With respect to the general AF PHB operation, we are restricting the AFx2 dropping algorithm to depend only on AFx1 traffic measurements. Mancuso, at al. Informational ¡ Expires January 2005 18 Implicit Signaling over Stateless Networks July 2004 The simplest dropping algorithm is represented by a "gate". When the measurement module does not detect congestion on the AFx1 traffic, being the notion of congestion implementation-dependent, it keeps the gate opened (we call this "ACCEPT" state). When the gate is open no AFx2 packet is dropped. Conversely, the measurement module keeps the gate closed ("REJECT" state) when congestion is detected, i.e. it enforces a 100% drop probability over AFx2 packets. Note that this operation does not violate the AF drop level relationship, as AFx1 dropping probability is lower than the AFx2 one. The above description is simply a particular implementation of an AF class. Indeed, its interpretation in terms of Implicit Signaling simply requires to: 1) dedicate a considered AF class x to the support of QoS aware flows, requiring an admission control procedure; 2) label traffic generated by flows which have already passed an admission control test as AFx1; 3) reserve AFx2 to mark "signaling" packets injected in the network by flows during the setup phase According to the described operation, an AFx2 packet is delivered to its destination ONLY IF it encounters all the routers along the path in the ACCEPT state. This operation provides an implicit binary signaling pipe, semantically equivalent to a one-bit explicit congestion notification scheme. 12 APPENDIX B: RSVP transparent signaling across DiffServ domains In this appendix we will focus on a scenario similar to the one dealt with in Section 6. More in detail, the following represents a possible application of the concept presented in Section 6. 12.1 case 1: RSVP over Implicit Signaling Let's consider an RSVP-handled connection between two hosts (SRC and DST - see figure 5), and suppose that the path between the two end- points traverse three different administrative domains. Domain A and Domain C use a stateful IntServ network architecture, while Domain B is a stateless DiffServ domain. _________ _________ _________ / \ / \ / \ / \ / \ / \ +---+ +--+ +---+ +---+ +--+ +---+ |SRC|--|R1| Domain A | R2| Domain B | R3| Domain C |R4|--|DST| +---+ +--+(IntServ1) +---+(DiffServ) +---+(IntServ2) +--+ +---+ \ / \ / \ / \_________/ \_________/ \_________/ Figure 5: Intserv-DiffServ scenario Mancuso, at al. Informational ¡ Expires January 2005 19 Implicit Signaling over Stateless Networks July 2004 When the source SRC needs to setup a flow to the destination, it opens an RSVP session by sending a PATH messages, that semantically operates like a Probe injected in the network. Then, the sender waits for a RESV message, which semantically operates like a Feedback. The PATH signaling packet injected in the network carry application-level information to be used at the destination node, DST; these information can be read by any RSVP router along the path. Of course, this is not the case of routers inside Domain B, where DiffServ is deployed. When the PATH message firstly reaches the ingress node of Domain A (i.e. R1), this node recognizes, in the order, that the packet is a signaling packet, and it contains information usable by RSVP reservation protocol. This signaling packet is meant for end-to-end reservation, i.e. for the reservation resource procedure between SRC and DST (or between R1 and R4, if, for security reasons, reservation is operated by the network provider, once given a user request). Anyway, the PATH packet triggers the specific edge-to-edge reservation mechanism (RSVP) through Domain A. If routers in the path segment between R1 and R2 have resource enough to accommodate the connection, then the PATH message is forwarded out of the domain by the egress node. In Domain B, instead of RSVP, Implicit Signaling over AF PHB is used. In this case the original PATH message is simply labeled as a Probe packet and forwarded from ingress router R2 to egress router R3. If multiple paired PHBs are available in Domain B, i.e. different QoS classes are provided, a SLA between Intserv and DiffServ domains establishes the mapping between the IntServ requested service and DIffServ PHBs. If congestion is not present in Domain B, PATH message is not dropped and can be further forwarded to Domain C, where it is recognized as an RSVP signaling message. Thus the RSVP reservation procedure is started also in Domain C, and the connection request can eventually be delivered to DST. Finally, if DST accepts the connection, it sends a RESV message to the sender (or it trigger R4 to generate such a message). The RSVP RESV message crosses back Domain C, then enter Domain B where is labeled as a Probe Feedback and not parsed by DiffServ core routers. If this message reaches the egress router R2 before the timeout adopted by the Implicit Signaling expires, then the Implicit Signaling entity located at R2 forwards the message to Domain A, and reservation procedure for DiffServ domain is completed. Otherwise the RESV message is dropped and SRC will not receive a feedback for its connection request. In case that the admission control in the DiffServ domain gives a positive outcome, the RESV message is parsed by RSVP routers in Domain A and finally by the source. If the reservation procedure gives positive response separately in each domain, then SRC positively activate the flow by emitting Information packets. In case the signaling feedback (RESV) does not arrives back in due time, the flow setup is aborted. Mancuso, at al. Informational ¡ Expires January 2005 20 Implicit Signaling over Stateless Networks July 2004 The flow message chart relative to the described operation is reported in figure 6. As to NSIS terminology, SRC acts like a NSIS Initiator (NI), DST acts like a NSIS Responder (NR), while edge routers and RSVP routers operate the NSIS forwarding (NF). Furthermore, edge routers run NSLP translation (from RSVP support to Implicit Signaling and vice versa). SRC R1 R2 R3 R4 DST | | | | | | | RSVP PATH | | | | |---------------------->| | | | | | | RESV PATH | | | | | | (Probe label) | | | | | |--------------------->| | | | | | | | | | | | | RSVP PATH | | | | |------------->| | | | | | | | | | | RSVP RESV | | | | |<-------------| | | | RSVP RESV | | | | | | (Feedback label) | | | | | |<---------------------| | | | RSVP RESV | | | | |<----------------------| | | | | | | | | | | | | | | | | | | | | | | | | | | | | DATA | | | | | | (IntServ | | | | | classified) | | | | |---------------------->| | | | | | | | | | | | | DATA | | | | | | (DiffServ labeled) | | | | | |--------------------->| | | | | | | | | | | | | DATA (IntServ| | | | | classified) | | | | |------------->| | | | | | Figure 6: Message sequence chart for RSVP over Implicit Signaling 12.2 case 2: RSVP plus Implict Signaling Let's consider again an RSVP-handled connection between two hosts (SRC and DST - see figure 5), and suppose that the path between the Mancuso, at al. Informational ¡ Expires January 2005 21 Implicit Signaling over Stateless Networks July 2004 two end-points traverse three different administrative domains. Domain A and Domain C use a stateful IntServ network architecture, while Domain B is a stateless DiffServ domain. When the source SRC needs to setup a flow to the destination, it opens an RSVP session by sending a PATH messages (or it triggers R1 to do it). Then, the sender waits for a RESV message. The PATH signaling packet injected in the network carries application-level information to be used at the destination node, DST; these information can be read by any RSVP router along the path. Of course, this is not the case of routers inside Domain B, where DiffServ is deployed. When the PATH message reaches ingress node of Domain A, this node recognizes, in the order, that the packet is a signaling packet, and it contains information usable by RSVP reservation protocol. If routers in the path segment between R1 and R2 have resource enough to accommodate the connection, then the PATH message is forwarded out of the domain by the egress node R2 (otherwise, it is dropped). This packet is then transparently forwarded in the DiffServ domain, i.e., it is labeled and forwarded according to SLAs and routing protocols, no matter the content of the datagram. Thus the RSVP message reaches R3, where it is parsed according to the RSVP policy and eventually forwarded to the final destination through Domain C. At this point, the RSVP entity in the DST (or in R4, triggered by DST) has to ack by means of a RESV message or refuse the connection. Considering the case of positive acknowledgement, the RESV message has to cross the DiffServ domain. In Domain B (DiffServ) the RESV message is simply labeled according to SLAs and DiffServ policy and reaches the egress router R2. Then the message is blocked and a specific edge-to-edge reservation mechanism through Domain B is triggered. In other words, an Implicit Signaling is triggered by R2 towards R3 (i.e. in the uplink path, while the RESV message travels in the downlink path) in the DiffServ domain. A Probe is sent towards R3, which is in charge of respond with a Feedback or refuse. If a Feedback is received by R2 before a timeout expires, the connection request is locally accepted in the DiffServ domain and the previously blocked RESV message is forwarded in the IntServ Domain A. If routers in the path segment between R2 and R1 have resource enough to accommodate the connection, then the RESV message is forwarded to R1 and SRC is made aware of the network possibility to accommodate a new connection. The flow message chart relative to the described operation is reported in figure 7. As to NSIS terminology, SRC (or R1) and R2, when sending Probes for Implicit Signaling, act like NSIS Initiators (NI) for two nested signaling sessions; DST (or R4) and R3, when receiving a Probe and responding, act like NSIS Responders (NR), while edge routers R2 and Mancuso, at al. Informational ¡ Expires January 2005 22 Implicit Signaling over Stateless Networks July 2004 R3, when dealing with RSVP messages, and RSVP routers in Domains A and C, operate the NSIS forwarding (NF). Furthermore, edge routers run NSLP translation (from RSVP support to Implicit Signaling and vice versa). SRC R1 R2 R3 R4 DST | | | | | | | RSVP PATH | | | | |---------------------->| | | | | | | RESV PATH | | | | | | (AFx1 label) | | | | | |--------------------->| | | | | | | | | | | | | RSVP PATH | | | | |------------->| | | | | | | | | | | RSVP RESV | | | | |<-------------| | | | RSVP RESV | | | | | | (AFx1 label) | | | | | |<---------------------| | | | | | | | | | | | PROBE | | | | | | (AFx2 label) | | | | | |--------------------->| | | | | | | | | | | | PROBE FEEDBACK | | | | | | (AFx1 Label) | | | | | |<---------------------| | | | | | | | | | RSVP RESV | | | | |<----------------------| | | | | | | | | | | | | | | | | DATA | | | | | | (IntServ | | | | | classified) | | | | |---------------------->| | | | | | | | | | | | | DATA | | | | | | (DiffServ labeled) | | | | | |--------------------->| | | | | | | | | | | | | DATA (IntServ| | | | | classified) | | | | |------------->| | | | | | Figure 7: Message sequence chart for RSVP plus Implicit Signaling for a IntServ Class mapped on an AFx PHB. Mancuso, at al. Informational ¡ Expires January 2005 23 Implicit Signaling over Stateless Networks July 2004 13 APPENDIX C: A case study: satellite gateways in a DiffServ domain A very critical issues is represented by the NSLP translation, whose functionalities can also be extended to the interaction with QoS handlers mechanisms in a specific node. This could append, for instance, when the signaling information has to be translated from a specific reservation mechanism to another. This issue (not stressed in the example presented in APPENDIX B, but also present) is focused in the following example. Here we consider a scenario similar to the one presented before in Section 6 and in APPENDIX B, but with a fourth domain, which is a satellite DVB-RCS link. In the DVB-RCS satellite it is possible to manage six different level of priority, independently from higher layer reservation procedures. Nevertheless it is possible to harmonize the usage of DVB-RSC-specific QoS mechanisms and any other kind of resource reservation protocol and admission control function. DVB-RCS profile classes and their corresponding behaviours are shown in the following Table 1: MTPD: Maximum Packet Transfer Delay PtPDV: Peak-to-peak Delay Variation PLR: Packet Loss Ratio +--------+-----------------+-----------------+------------------+ |DVB-RCS | | | | |Profile | MPTD | PtPDV | PLR | |Class | | | | +--------+-----------------+-----------------+------------------+ | 1 | Highly sensitive| Highly sensitive| Loosely sensitive| | | (hundreds of ms)| (tens of ms) | (less than 10^-3)| +--------+-----------------+-----------------+------------------+ | 2 | Sensitive | Highly sensitive| Sensitive | | | (less than 1s) | (tens of ms) | (less than 10^-4)| +--------+-----------------+-----------------+------------------+ | 3 | Sensitive | Loosely or not | Highly sensitive | | | (less than 2s) | sensitive | (less than 10^-6)| +--------+-----------------+-----------------+------------------+ | 4 |Loosely sensitive| Not sensitive | Sensitive | | | (few seconds) | | (less than 10^-4)| +--------+-----------------+-----------------+------------------+ | 5 |Loosely sensitive| Not sensitive | Highly sensitive | | | (some seconds) | | (less than 10^-6)| +--------+-----------------+-----------------+------------------+ | 6 | Not sensitive | Not sensitive | Not sensitive | | | | | | +--------+-----------------+-----------------+------------------+ Table 1: DVB-RCS profile classes and their specifications Mancuso, at al. Informational ¡ Expires January 2005 24 Implicit Signaling over Stateless Networks July 2004 For sake of simplicity, in this example we consider the scenario depicted in figure 8, where SRC and DST end-nodes are RSVP-capable. The operation described in APPENDIX B, case 1, is adopted in what follows. ______ ______ ______ / \ / \ / \ / Domain \ / Domain \ +------+ / Domain \ +---+ +--+ A +--+ B +--+ Sa- |--| D +--+ +---+ |SRC|--|R1| |R2| |GW| tel- |TR| |R4|--|DST| +---+ +--+ Int- +--+ Diff- +--+ lite |--| Int- +--+ +---+ \ Serv / \ Serv / +------+ \ Serv / \____1_/ \______/ \____2_/ Figure 8: IntServ-DiffServ-Satellite scenario In order to start a new connection, a PATH message is sent from SRC and accordingly dealt with in Domain A. If RSVP routers in Domain A have room enough to accommodate the requested connection, R2 starts an Implicit Signaling admission control procedure in the scope of Domain B. GS: Guaranteed service (IntServ) CLS: Controlled Load Service (IntServ) EF: Expedited Forwarding Per Hop Behaviour (DiffServ) AFx (x=1,2,3,4): Assured Forwarding PHBs (DiffServ) BE: Best Effort service +---------+-------------------------------+----------+ | IntServ | Application | DiffServ | | Class | Requirements/priority | PHB | +---------+-------------------------------+----------+ | GS | high priority, | EF | | | low loss | | +---------+-------------------------------+----------+ | CLS |_________ high priority | | | | | and high rate | AF1 | | | | | | | | |_______ high priority | | | | | and low rate | AF2 | | | | | | | | |_______ low priority | | | | | and high rate | AF3 | | | | | | | | |_______ low priority | | | | and low rate | AF4 | | | | | +---------+-------------------------------+----------+ | BE | Best | BE | | | Effort | | +---------+-------------------------------+----------+ Table 2: IntServ-DiffServ mapping Mancuso, at al. Informational ¡ Expires January 2005 25 Implicit Signaling over Stateless Networks July 2004 In order to do it, RSVP PATH messages has to be mapped on a specific DiffServ class. In fact, Implicit Signaling probing has to be performed solely in the class that is candidate to accommodate the flow, if establishes. A possible IntServ to DiffServ mapping is reported in Table 2. Furthermore, once the right DiffServ class is selected, the PATH message is accordingly labeled with a Probe DSCP, and forwarded towards the GW node, that is a satellite gateway located at the edge of a DiffServ domain. In the assumption that DVB-RCS technology is adopted, the signaling message can be forwarded to the satellite, but it is needed to map DiffServ codepoint onto DVB-RCS precedence classes. An example of such a mapping is reported in Table 3. After the satellite hop, the RSVP PATH message (which was labeled as a Probe and forwarded within a specific DVB-RCS profile class) is injected by TR (the terrestrial satellite terminal) in the following IntServ domain, and it is parsed by RSVP routers and finally by DST, that possibly generates the RESV message. DVB-RCS approach allows EF: Expedited Forwarding AFxy (x=1,2,3,4;y=1,2,3): Assured Forwarding class x precedence y BE: Best Effort +-----------------------------+-----------------------------------+ | DiffServ PHB | DVB-RCS profile classes | +-------+---------------------+-----+-----+-----+-----+-----+-----+ | Class | Precedence | 1 | 2 | 3 | 4 | 5 | 6 | +-------+---------------------+-----+-----+-----+-----+-----+-----+ | EF | --- | X | | | | | | +-------+---------------------+-----+-----+-----+-----+-----+-----+ | AF1 | AF11 -Data/Feedback | | X | | | | | | +---------------------+-----+-----+-----+-----+-----+-----+ | | AF12 -Probe | | | X | | | | | +---------------------+-----+-----+-----+-----+-----+-----+ | | AF13 | | | | X | | | +-------+---------------------+-----+-----+-----+-----+-----+-----+ | AF2 | AF21 -Data/Feedback | | | X | | | | | +---------------------+-----+-----+-----+-----+-----+-----+ | | AF22 -Probe | | | | X | | | | +---------------------+-----+-----+-----+-----+-----+-----+ | | AF23 | | | | | X | | +-------+---------------------+-----+-----+-----+-----+-----+-----+ | AF3 | AF31 -Data/Feedback | | | | X | | | | +---------------------+-----+-----+-----+-----+-----+-----+ | | AF32 -Probe | | | | | X | | | +---------------------+-----+-----+-----+-----+-----+-----+ | | AF33 | | | | | | X | +-------+---------------------+-----+-----+-----+-----+-----+-----+ | BE | --- | | | | | | X | +-------+---------------------+-----+-----+-----+-----+-----+-----+ Table 3: DiffServ-DVB-RCS mapping Mancuso, at al. Informational ¡ Expires January 2005 26 Implicit Signaling over Stateless Networks July 2004 the system to use the satellite link in the reverse path, so that RESV message will be forwarded back to Domain B through the return satellite link, where a RSVP->DVB-RCS mapping has to be performed. As a reference, one could consider the mapping presented in Table 4, where the IntServ Controlled load service has been decomposed in four different services, in accordance with the traffic priority and data rate. Of course, RSVP packets are mapped accordingly to the requesting service, as reported in the Table 4, while the right DiffServ codepoint to be used when entering the Domain B, is chosen in accordance with the actual DVB-RCS profile class (which corresponds to a IntServ service) and based on the combination of mapping functions reported in Tables 3 and 4. In case of CLS services, to be mapped on AFx classes, RESV messages are labeled as AFx1, since they cross the DiffServ domain acting as Probe Feedbacks. The rest of the network operation follows the behaviour already shown in APPENDIX B, case 1. GS: Guaranteed service CLS: Controlled Load Service BE: Best Effort service +---------------------+-----------------------------------+ | | DVB-RCS profile classes | | IntServ +-----+-----+-----+-----+-----+-----+ | Classes | 1 | 2 | 3 | 4 | 5 | 6 | +---------------------+-----+-----+-----+-----+-----+-----+ | GS | X | | | | | | +-----+---------------+-----+-----+-----+-----+-----+-----+ | CLS | high priority | | X | | | | | | | high rate | | | | | | | +-----+---------------+-----+-----+-----+-----+-----+-----+ | CLS | high priority | | | X | | | | | | low rate | | | | | | | +-----+---------------+-----+-----+-----+-----+-----+-----+ | CLS | low priority | | | | X | | | | | high rate | | | | | | | +-----+---------------+-----+-----+-----+-----+-----+-----+ | CLS | low priority | | | | | X | | | | low rate | | | | | | | +-----+---------------+-----+-----+-----+-----+-----+-----+ | BE | | | | | | X | +---------------------+-----+-----+-----+-----+-----+-----+ Table 4: IntServ-DVB-RCS mapping Finally, note that these mapping strategies have to be straight managed by NSLP protocols with the support of NTLP. In fact, NTLP is in charge of preserving signaling messages while traversing the network, while NSLP locally adapts reservation procedures with priorization and QoS mechanisms resident on the local domain and on Mancuso, at al. Informational ¡ Expires January 2005 27 Implicit Signaling over Stateless Networks July 2004 the local machine too. Thus, flow priorities and status information have to be dealt with by the NTLP protocol, while NSLP has to be compliant with lower level QoS features, and drive it like in the case of DVB-RCS satellite links. 14. 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 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. Mancuso, at al. Informational ¡ Expires January 2005 28