HyPath February 2006 NSIS Working Group L. Cordeiro Internet Draft M. Curado Expires: August 2006 E. Monteiro University of Coimbra F. Racaru M. Diaz C. Chassot LAAS February 2006 Hybrid on-path off-path approach for end-to end signalling accross NSIS domains (HyPath) draft-cordeiro-nsis-hypath-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 August 5, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Cordeiro Expires - August 2006 [Page 1] HyPath February 2006 In a multi-domain Internet that offers QoS guaranties for applications, there is the need of signalling among the domain entities that are responsible for the management of QoS. Because different domains have different network protocols and topologies, the HyPath approach uses the NSIS protocol and interactions with the local routing protocols to have an off path signalling in hybrid environments. Table of Contents 1. Introduction...................................................2 1.1 Terminology and Abbreviations..............................3 2. Off-path signalling state of the art...........................3 2.1 Off-path signalling proposals..............................4 2.1.1 SIBBS (Simple Inter-domain Bandwidth Broker Protocol)...4 2.1.2 COPS-SLS................................................6 3. HyPath.........................................................7 3.1 The new signaling..........................................9 3.2 Non-NSIS domains..........................................11 3.3 Usage of external routing protocols.......................12 3.4 Heterogeneous solution....................................14 3.5 HyPath architecture.......................................15 3.5.1 HyPath in the RM.......................................15 3.5.2 HyPath in the border router............................16 3.5.3 HyPath payload.........................................17 4. Security Considerations.......................................17 5. Conclusion....................................................17 6. Open issues...................................................17 7. References....................................................18 8. Author's Addresses............................................19 9. Intellectual Property Statement...............................20 10. Disclaimer of Validity.......................................20 11. Copyright Statement..........................................20 1. Introduction In the past years, we assisted at a common rise of new technologies in the telecommunication and computer science field. This evolution led to the emergence of new types of applications involving multimedia, like VoIP, VoD, tele-engineering, telemedicine, etc.. These applications have new constraints and requirements concerning parameters such as delay and jitter. Therefore, new services are required besides those given by the actual Internet. Nowadays, all packets in the Internet receive the same treatment. As presented before, some data flows need special processing in order to satisfy the application requirements, and thus it is necessary to address QoS (Quality of Service) issues. The internet is an interconnection of networks, comprising different domains, Cordeiro Expires - August 2006 [Page 2] HyPath February 2006 called Autonomous Systems (AS), managed independently, especially in what concerns QoS strategies. In order to support QoS for communications over several domains, intra and inter-domain QoS signalling appears to be inevitable. Our work aims at a context of a multi-domain Internet that offers QoS guaranties for applications. Inside a domain, the QoS is managed through central entities, that are in charge of installing and handling QoS based on internal rules. This concept was introduced in the DiffServ domains, and is associated with Bandwidth Brokers [6]. At the present, a new requirement appears: signalling must take place, not only among devices strictly on the data path, but also among these central entities, that we call hereafter Resource Manager (RM). Several signalling protocols have been proposed, especially in the IETF NSIS working group. The goal of the NSIS protocol is to manipulate the network state related to data flows with the constraint that the signalling protocol will be processed on the nodes which also handle the data flows themselves ("path-coupled signalling"). This document discusses a NSIS multi-domain, multi- service, RM based Internet that allows an off-path signalling. The main issue addressed in this document is the inter-operability between NSIS and non-NSIS domains. 1.1 Terminology and Abbreviations 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 [10]. This document uses a number of terms defined in [5]. The following additional terms are used: * QoS: Quality of Service * RM: Resource Manager, central entity of a domain in charge of the QoS management. * NSIS domain: an administrative domain where the RM and at least all border routers are NSIS aware. * Non-NSIS domain: an administrative domain where only the RM is NSIS aware. * E2E: end-to-end 2. Off-path signalling state of the art In the off-path approach, entities participating in the signalling process are not bound to the path followed by the data flows. The most common example is when particular entities inside a domain, Cordeiro Expires - August 2006 [Page 3] HyPath February 2006 which have special responsibilities (QoS, policy control, servers, etc.) must be signalled. These devices are not strictly on the data path; nevertheless the signalling protocol must arrive to interact with these devices. Off-path signalling has advantages, as presented in [4] and [5]: * independence between the signalling plane and the forwarding plane * introduction of flexibility allowing entities such as proxies to be signalled even if they are not on the data path; * functioning with new routing protocols or traffic engineering mechanisms (QoS routing, q-BGP, etc.); * better adapted for mobility. On the other hand, off-path signalling must answer new challenges such as discovering the next hop and synchronisation with IGP (Interior Gateway Protocol) and EGP (Exterior Gateway Protocol) routing protocols. 2.1 Off-path signalling proposals Several protocols have been proposed for the off-path signalling in a bandwidth broker-based multi-domain DiffServ model. 2.1.1 SIBBS (Simple Inter-domain Bandwidth Broker Protocol) The SIBBS protocol has been defined by the QBone Signaling Workgroup and it aims to be used on DiffServ bandwidth broker-based domains. In the QBone testbed, each network is a differentiated service (DiffServ) domain supporting one or more globally well known forwarding services built from fundamental DiffServ blocks. SIBBS is a very simple protocol to be used between bandwidth borkers. It contains two principal PDU: o RAR (Resource Allocation Request) o RAA (Resource Allocation Answer) Cordeiro Expires - August 2006 [Page 4] HyPath February 2006 ***************** ******************* ******************* * +------+ * * +------+ * * +------+ * * | |-.-.-.-.-.-.-.-.->| |-.-.-.-.-.-.-.-.->| | * * | BB | * * | BB | * * | BB | * * | |<-.-.-.-.-.-.-.-.-| |<-.-.-.-.-.-.-.-.-| | * * +-- ---+ * * +------+ * * +------+ * * / * * * * * * / +--+ +--+ +--+ +--+ * * +---+ |BR|'''|BR| |BR|'''|BR| * * | C | +--+ +--+ +--+ +--+ * * +---+ * * * * * ***************** ******************* ******************* <-.-.-.-.-> = signalling message betwwen BB ----------- = message between client and BB C = client BB = Bandwidth Broker BR = Border Router Figure 1 - SIBBS protocol The RAR message includes a globally well-known service ID, information related to the QoS request (class of services and bandwidth) and a destination IP address, a source IP address, an authentication field, and the other parameters of the service. The sender can be the client host, a BB or a proxy. The RAA message contains the answer to a RAR PDU. The communication between BB is supposed to be reliable, i.e. using TCP. Receiving a RAR message, a BB: o Authenticates that the request is indeed from a peer bandwidth broker; o Determines the egress router (interface) from its (inter- domain) routing tables; o Checks that the requested resources fall within the SLS; o Ensures that there are sufficient resources within the domain to support the flow from the ingress border router; o Determines whether the flow may be accepted according to the policies of the domain. If the required resources are available, the request is propagated recursively through the inter-domain path to the last BB. This last BB returns a RAA message to its immediately upstream BB and the process is continued until the originating BB. This is concluded with an admission of the QoS request. Resources are confirmed by means of refresh messages, sent periodically. Cordeiro Expires - August 2006 [Page 5] HyPath February 2006 In order to perform the configuration of the border routers, the BB must have access to this one. SIBBS does not specify a particular protocol, but some examples are COPS, DIAMETER, SNMP, etc.. 2.1.2 COPS-SLS COPS-SLS [7, 8] is an extension of the COPS (Common Open Policy Service) protocol [9] for SLS management in a multi-domain environment. COPS is a client/server protocol designed for the management of policy based networks. The basic model of COPS is presented below: +----------------+ | | | Network Node | Policy Server | | | +-----+ | COPS +-----+ | | PEP |<-----|-------------->| PDP | | +-----+ | +-----+ | ^ | | | | | \-->+-----+ | | | LPDP| | | +-----+ | | | +----------------+ Figure 2 - COPS protocol The PDP (Policy Decision Point) is the central entity in charge of making the decisions (for itself or for other elements of the network). The PEP (Policy Enforcement Point) is the point where the policies are applied, such as a router. The optional Local Policy Decision Point (LPDP) can be used by the device to make local policy decisions in the absence of a PDP. COPS is a request/response protocol that allows a PEP (router) to interrogate its PDP about the action to perform once an event has occurred (for instance, if a signalling message arrived). COPS-PR is an extension of COPS with the goal to force the application of a policy in the PEP without any prior request. COPS-SLS has the same behaviour as SIBBS: a request is propagated from one BB to the other in each domain of the data path. Each BB has a double role: * PDP for the upstream domain, BB which sends the request, and * PEP for the next BB domain. Cordeiro Expires - August 2006 [Page 6] HyPath February 2006 Compared to SIBBS, COPS-SLS adds some features to the protocol, as renegotiation of classes of service in case of failure of admission control. The communication between BB and border routers is assured by the COPS-PR protocol. COPS-SLS does not provide any specification on the discovery of the next BB discovering or on the identification of border routers. 3. HyPath The requirements for a hybrid on-path/off-path approach for e2e signalling across NSIS and non-NSIS domains are not fully solved by the NSIS protocol as it is being defined currently in the IETF NSIS working group. There is the need to have network signalling between specific entities in domains (not only the routers in the data path like the normal on-path solution). This is the case of QoS network signalling when there are resource manager entities in the domains responsible for the domain QoS. In these situations the entities to be signalled are the RM entities and not only the network equipment (routers). An example of the normal NSIS signalling from a source RM to a destination RM is shown in Figure 3. The normal way of work of the NSIS protocol [1], not only does not signal the RM servers in the data path, but also does not force the signalling to follow the same path as the user data (because the source and destination are different and the domains can have different routing policies based on local source IP addresses). As presented in Figure 3, the signalling message could not follow the same inter-domain path from the sender domain to the receiver domain. Therefore the resource reservation will not be properly done on the data path. Cordeiro Expires - August 2006 [Page 7] HyPath February 2006 ********************** * +----------+ * * | | * * | RM | * * | | * * +----------+ * +--+ +--+ ...........|BR|................|BR|........ : +--+ +--+ : : ********************** : +--+ +--+ *********|BR|********* *********|BR|********* * +--+ * * +--+ * * +----------+ * * +----------+ * * | | * * | | * * | RM | * * | RM | * * | | * * | | * * +----------+ * * +----------+ * * +---+ * * * * | C |----| * * * * +---+ | * * * * +--+ * * +--+ * *********|BR|********* *********|BR|********* +--+ +--+ | ********************** | | * +----------+ * | | * | | * | | * | RM | * | | * | | * | | * +----------+ * | | +--+ +--+ | |----------|BR|----------------|BR|-------| +--+ +--+ ********************** -------------------- signalling started by the client .................... signalling started by the RM C = client, RM = Resource Manager, BR = Border Router Figure 3 - Normal NSIS signalling The major requirements to achieve e2e (end-to-end) network signalling are the following: * Signalling messages must follow the same path as the user data; * All the RMs in the data path must be signalled. Cordeiro Expires - August 2006 [Page 8] HyPath February 2006 The NSIS protocol as it is being defined in the IETF can not solve these two major requirements simultaneously. In order to fulfil the above requirements, a middle layer between the two NSIS layers was conceived. This layer is named HyPath (Hybrid Path). To be able to connect the HyPath with the NTLP layer [2] and the NSLP layer [3] without altering their specifications, the HyPath needs to be a middle layer between the NTLP layer and the NSLP layer (the already defined interfaces must not be changed). Figure 4 describes an example of the NSIS protocol architecture including the HyPath. +-----------------------------------------------------+ | Resource Manager (RM) | +-----------------------------------------------------+ | ^ +-----------------|----------------|------------------+ | NSIS v | | | +--------------------------------------+ | | | NSLP | | | +--------------------------------------+ | | | ^ | | v | | | +------+ +----------------------+ | | | BGP |<-------| | | | |proc. |------->| HyPATH | | | +------+ +-- -------------------+ | | | ^ | | v | | | +-------------------------------------+ | <------------| GIST |------------> | +----------------------- -------------+ | +-----------------------------------------------------+ HyPath on the NSIS architecture BGP proc = BGP processing + external functions Figure 4 - HyPath in the NSIS architecture Therefore, the HyPath interface with the NTLP layer must be the same as the NSLP layer interface already defined. Likewise the interface with the NSLP layer must be the same as the defined NTLP layer interface. 3.1 The new signaling The operation of NSIS with the additional HyPath in the border routers and RMs in all domains is illustrated in Figure 5. Cordeiro Expires - August 2006 [Page 9] HyPath February 2006 ***************** ******************* ******************* * +------+ * * +------+ * * +------+ * * | | * * | | * * | | * * | RM | * * "| RM | * * "| RM | * * | |. * * " | | * * " | | * * +------+ \ * * " +------+ * * " +------+ * * . * * " * * " * * \+--+ +--+ +--+ +--+ * * +---+ |-.|-.-|.-|-.-.-.-.-.-.-.|-.|-.-|-.| +---+ * * | S |========|BR|===|BR|==============|BR|===|BR|=========| R | * * +---+ +--+ +--+ +--+ +--+ +---+ * ***************** ******************* ******************* -.-.-.-.-.- NSIS signalling path =========== Data path """"""""""" AS local NSIS signalling S = sender, R = receiver BR = Border Router Figure 5 - NSIS signalling with HyPath When a user makes a QoS request to the local QoS system, NSIS signalling must occur in order to signal all on path RM. This signalling must follow the same path as the data. Therefore, in the first domain, the HyPath in the local RM uses an external function (described in Section 3.3) to discover the local egress border router of the data. Afterwards, the HyPath asks the NSIS transport layer to send a NSIS message to the egress border router. This message contains the NSLP payload and some additional HyPath information (described in Section 3.5). Once in the egress border router, the NSIS signalling message is sent to the end user. In this scenario, all border routers intercept NSIS messages, and are HyPath aware. Therefore, in the following domain the NSIS signalling message is intercepted by the ingress border router. In this router the message is redirected to the local RM server to make the local RM signalling. After processing the received message, the RM server continues the signalling sending a message back to the ingress border router. The signalling is restarted in the ingress border router and the NSIS message continues to the next domain. Cordeiro Expires - August 2006 [Page 10] HyPath February 2006 These procedures continue in all domains until the last domain is reached and the signalling stops in the RM server. With this architecture all the requirements to achieve e2e network signalling are met and no changes are needed in the definitions of the NTLP and NSLP layers. Specifically, in the first domain egress border router the data path and the signalling path meet. From that point on, if the NSIS signalling message is always sent to the end user, the message will follow the data path (the routing roles will be the same). 3.2 Non-NSIS domains The drawback of the approach described in Section 3.1 is that all border routers of all domains must be NSIS aware. Even though in theory this is a reasonable assumption, in practice we can not guarantee that this happens. For this reason we define a heterogeneous solution that works when border routers are not NSIS aware (non-NSIS domains) and the only information available is provided by the routing protocol of the domain. Not being able to rely on NSIS interception in the border router, the solution is to rely on the routing protocol. In non-NSIS domains, when the RM intends to send a signalling message, the HyPath uses an external function (described in Section 3.3) to discover the local egress border router of the data path and the next RM IP address. With this information, a NSIS message with the NSLP payload and some additional HyPath information (described in Section 3.5) is sent directly to the RM of the next domain. Using again the external function to discover the local egress border router of the data path and the next RM IP address, the NSIS signalling message is sent to the RM of the next domain. The procedure described is repeated until the last domain is reached. In this approach, the signaling messages do not follow the data path, but they follow all the RMs in the data path. The inconvenience with this approach is the extensive usage of the external functions. Since these functions are used in all non-NSIS domains, this approach would have an impact on the processing time and on the amount of resources used. Cordeiro Expires - August 2006 [Page 11] HyPath February 2006 3.3 Usage of external routing protocols In the beginning of this document the motivation for off-path signaling was described. If the signaling is decoupled from the data path (but still path-related signaling) two general problems need to be solved: o The Resource Manager must discover the ingress and egress points through which the data path will pass in its domain; this information is needed in order to continue the NSIS signaling and to perform an admission control between the ingress and the egress border routers and on the inter-domain link. o In non-NSIS domains, the Resource Manager in the next domain must be identified in order to propagate the request. The RM has access to the BGP tables of the border routers of its domain, and is able to interrogate the BGP tables. This interrogation is implemented as a request/response protocol via telnet or ssh. The main information in the BGP routing table after rejecting unacceptable routes is: o Accessible destination network list (IP prefixes); o For each prefix: o next router address (next-hop) in the adjacent domain; this information is carried up in the messages inside the AS (i- BGP session); o List of Autonomous Systems successively traversed (AS path), from adjacent domains to the AS destination domain for the destination network; o For each border router: address of neighbor routers with whom it has established BGP session (neighbor) which are either border router or Router Reflectors - RFC 2796. The approach to discover ingress and egress border routers is the following: a) Discover the ingress border router: i) If we deal with a NSIS domain and the upstream domain is also a NSIS domain, the ingress router is easy to retrieve. As described in the HyPath signaling (Section 3.1), it is the border router that intercepts the NSIS message and redirects it to the RM. ii) If we deal with a NSIS domain, and the upstream domain is a non-NSIS domain the ingress router is retrieved from the message received by the RM. In this case, the upstream RM sent the message directly to the local RM as explained in Section 3.2. Cordeiro Expires - August 2006 [Page 12] HyPath February 2006 This upstream RM interrogates the BGP table of its ingress border router and retrieves the next-hop IP address. The goal for the RM of the AS2 is to retrieve the ingress border router in the next domain. In the upstream AS2 domain the BGP R21 tables contains: Network Next-Hop Path *>ip form AS3 R31 i AS3 The RM of the AS2 interrogates this table and retrieves the next- hop address of R31. This operation is done only with adjacent non NSIS domains. Then, it passes this address in the signalling message to the RM of AS3. A particular case is when the IP address of the next-hop is not distributed through the internal routing protocol (a private IP for instance), and thus, the new request must be addressed to the egress border router. The procedure to discover this router is presented in the next section. When this RM receives the message, it has already the IP address of the ingress border router. If this address is not a public address (a private IP address for instance), it can obtain this public address from local BGP and topology configuration. iii) If we deal with a non-NSIS domain, the procedure is similar to the one presented in point ii) b) Discover the egress border router: i) Inside an AS, all border routers communicate in the i-BGP session. The egress border router is discovered using the BGP table of the ingress border router. If we deal with a full mesh iBGP (all border routers are connected on iBGP), then the egress border router is a neighbour. ii) As an alternative, if the domain uses Route Reflectors, either the attribute ORIGINATOR_ID, or the domain topology can be used to find the egress border router for the data path. For non-transit traffic (i.e. traffic originating inside the domain) the Resource Manager can use a database (similar to TED for the PCE Element [11] [12]) where it is stored cartography of the domain (network topology). In the next paragraph we explain how a Resource Manager can obtain the IP address of a peer Resource Manager in an adjacent domain. Cordeiro Expires - August 2006 [Page 13] HyPath February 2006 The RM is configured by the administrator of the domain. One solution is to consider that the SLA (Server Level Agreement) between two adjacent domains contains also the PI address of the RM present in the domain. As the administrator is aware of the SLAs, it can configure the RM with all peer RM addresses. Another solution follows the SIBBS proposal [3] that suggests to retrieve the bandwidth broker address via a DNS mechanism (the BB for each domain is to be named bb. and put it in a CNAME record in the DNS). We propose to have a similar approach. However, instead of using the domain name, we propose to associate the AS number to an RM IP address. When a RM needs to obtain the next RM IP address, it checks the BGP table to find the AS path to the destination. In the AS path, it finds the next AS number and, based on one of the mechanisms presented before, it does the correspondence AS number <-> RM IP address. In this section we described some mechanisms that allow for the solution of major issues of the off-path signalling path, namely to discover the next hop to signal and how to interact with external routing protocols such as BGP. 3.4 - Heterogeneous solution The NSIS and the non-NSIS solutions presented are able to work but, as discussed in the previous sections, have disadvantages. On one hand, in the NSIS solution it is mandatory to use NSIS and HyPath aware routers. On the other hand, in the non-NSIS solution it is needed an intensive usage of external functions that extensively access the routing protocol. A new solution is to integrate the two solutions presented. Particularly, with this approach, in NSIS domains it is used the NSIS solution and in non-NSIS domains it is used the non-NSIS solution. The difficulty of this hybrid approach is the interaction between domains that have different solutions implemented. When sending signalling messages from one NSIS domain to a non-NSIS domain, the information issued by the ingress border router is not sent within the signalling message and therefore cannot be retrieved locally. To solve this problem, the NSIS domain must check the type of the next domain before sending any signalling message. This information is obtained from the normal AS association procedure. If the next domain is a non-NSIS domain, the message must be sent as described in Section 3.2, otherwise it is sent as described in Section 3.1. Cordeiro Expires - August 2006 [Page 14] HyPath February 2006 This approach implies that NSIS domains connected with non-NSIS domains need to determine the type of the next domain, increasing not only the response time but also the complexity of the solution. If a NSIS domain is only connected to other NSIS domains the solution is very simple and light weight. 3.5 HyPath architecture As described in the previous sections, the additional functionalities for the Hybrid on-path/off-path approach for e2e signalling across NSIS and non-NSIS domains implies the usage of HyPath in the RMs and in the border routers. The main HyPath functionalities are the following: * In the Resource Manager - Discovery of the egress border router of the first domain - Discovery of the ingress border router after a non-NSIS domain - RM signalling - Message reception and decoding - Sending messages * In the egress border router - Start RM signalling in the first domain * In the ingress border router - Message interception and sending them to the local RM - Reception of the local RM response message and continuation of RM signalling These functionalities are described in more detail in the next subsections. 3.5.1 HyPath in the RM The HyPath in the RMs is responsible for changing the destination of the signalling message so the right RM is signalled. In the first domain (the domain where the network signalling starts) the HyPath starts by discovering the egress border router of the data path using an external function. If the next domain (discovered using the external function) is a NSIS domain, the message is sent to the egress border router. Otherwise, the ingress border router and the IP address of the RM of the next domain in the data path must be discovered using again an external function. Afterwards, the message is sent directly to the IP address of the next domain RM. If a domain is not the first domain, it means that a HyPath message has already been received and there is state stored in the HyPath database. If the next domain and the current domain are NSIS Cordeiro Expires - August 2006 [Page 15] HyPath February 2006 domains, the message is sent to the ingress border router (IP address in the database) to be forwarded through the same path as the data. If the next domain is a non-NSIS domain, then again, an external function must be used to discover the ingress border router and the IP address of the RM of the next domain in the data path. Afterwards, the message is sent directly to the IP address of the next domain RM. The messages to be sent upstream first need to query the HyPath database for the upstream RM IP address (state stored when a downstream message is received) and then are sent directly to the RM. When a message is received from GIST, the HyPath information in the message must be recorded in the database and the NSLP layer payload must be sent to the NSLP. 3.5.2 HyPath in the border router In the border routers the NSLP layer is not needed, so the HyPath acts as a normal NSLP. Figure 6 shows the NSIS architecture in a border router with HyPath. +------------------+ |NSIS | | +--------------+ | | | HyPath | | | +--------------+ | <--|-|- GIST -|-|--> | +--------------+ | +------------------+ Figure 6 - HyPath architecture in the border routers The HyPath module in the border router has two different functionalities depending if it is an egress or ingress border router. In the first domain, the border router acts as the egress router where the signalling merges with the data path. From this point forward, if the message is always sent to the end user, the signalling path will follow the same path as the data path. In the other domains, the border router acts as an ingress border router where HyPath NSIS messages are intercepted. In the border router, if the messages are received from the local RM, they are forwarded to the end user with the IP Router Alert Option flag. If the messages are intercepted, they are forwarded to the local RM. Cordeiro Expires - August 2006 [Page 16] HyPath February 2006 3.5.3 HyPath payload The HyPath needs to manage several states in the RM and border routers to be able to handle accordingly all messages. Therefore it needs to send specific information together with the network signalling message. The HyPath payload can have two types of content: * rm: indicates that the message is received from an RM; * br: indicates that the message is received from a border router. For each type of message the additional information in the payload changes. 4. Security Considerations This section describes the security considerations related to the HyPath and this will be discussed and clarified later. 5. Conclusion This draft presented architecture in the context of a NSIS multi domain Internet that aims an off-path signalling when a hybrid solution is required (fir instance NSIS is not implemented in all domains). Currently, increasing number applications claim special treatment for their packets in order to satisfy new requirements in term of delay, loss, jitter, etc. Inside an AS, the QoS management is often delegated to e central entity which has a global view of network topology. This entity is also aware of QoS availability inside and on the inter domain links of the domain. In order to signal these entities, which are not on the data-path, this draft proposed a solution to involve the central entities on the signalling in the NSIS context, solution called Hybrid Path. This work, a Hybrid on-path off-path approach for e2e signalling across NSIS and non-NSIS domains, aims specifically at the EuQoS project (http://www.euqos.org), but also for all network signalling that needs to signal specific entities in all domains in the data path. 6. Open issues This section describes the open issues related to the HyPath and this will be discussed and clarified later. Cordeiro Expires - August 2006 [Page 17] HyPath February 2006 7. References [1] Hancock, R., Karagiannis, G., Loughney, J., and S. Van de Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005. [2] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signaling Transport", draft-ietf-nsis-ntlp-09, September 2005. [3] Bosch, S., "NSLP for Quality-of-Service signalling", draft-ietf-nsis-qos-nslp-09, October 2005. [4] Hancock, R., Kappler, C., Quittek, J., Stiemerling, J., "A Problem Statement for Partly-Decoupled Signalling in NSIS", draft- hancock-nsis-pds-problem-02.txt, October 2005. [5] Schelen, O., Couturier, A., Bless, R., Geib, R., Dugeon, O., "Path-coupled and Path-decoupled Signaling for NSIS", draft- schelen-nsis-opopsig-01.txt, November 2002 [6] Blake, S;, Black, D., Carlson, M., Davies, E., Wang, Z., Weiss, W. "An Architecture for Differentiated Services", RFC 2475, December, 1998 [7] Trang Nguyen TM, Boukhatem N., Doudane, Y.G., Pujolle, G. "COPS-SLS - a service level negotiation protocol fort he internet", IEEE Communication Magazine, vol. 40, n°5, May 2002 [8] Trang Nguyen TM, Boukhatem N., Doudane, Y.G., Pujolle, G, "COPS-SLS usage for dynamic policy-based QoS management over heterogeneous IP networks", IEEE Communication Magazine, vol. 17, n°3, May-June 2003 [9] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., Sastry, A. "The COPS (Common Open Policy Service) Protocol" - RFC 2748, January 2002 [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [11] Path Computation Element (PCE) Charter, http://www.ietf.org/html.charters/pce-charter.html, 2005. [12] Farrel, A., Vasseur, J-F., Ash, J., "A Path Computation Element (PCE) Based Architecture", draft-ietf-pce-architecture- 04.txt, January 2006 [13] QBone Design Signaling Team. Final Report Cordeiro Expires - August 2006 [Page 18] HyPath February 2006 8. Author's Addresses Luís Cordeiro Dept. of Informatics Engineering Univ. of Coimbra Polo II - Pinhal de Marrocos 3030-290 Coimbra, Portugal Email: cordeiro@dei.uc.pt Marilia Curado Dept. of Informatics Engineering Univ. of Coimbra Polo II - Pinhal de Marrocos 3030-290 Coimbra, Portugal Email: marilia@dei.uc.pt Edmundo Monteiro Dept. of Informatics Engineering Univ. of Coimbra Polo II - Pinhal de Marrocos 3030-290 Coimbra, Portugal Email: edmundo@dei.uc.pt Florin Racaru Laboratory for Analysis and Architecture of Systems Avenue du Colonel Roche 31077 Toulouse France Email: fracaru@laas.fr Michel Diaz Laboratory for Analysis and Architecture of Systems Avenue du Colonel Roche 31077 Toulouse France Email: diaz@laas.fr Christophe Chassot Laboratory for Analysis and Architecture of Systems Avenue du Colonel Roche 31077 Toulouse France Email: chassot@laas.fr Cordeiro Expires - August 2006 [Page 19] HyPath February 2006 9. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 10. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 11. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Cordeiro Expires - August 2006 [Page 20]