NSIS Working Group J. Zhang Internet Draft E. Monteiro University of Coimbra Expiration Date: Septemper 06, 2006 Mar 07, 2006 InterDomain-QOSM: The NSIS QOS Model for Inter-domain Signaling to Enable End-to-End QoS Provisioning Over Heterogeneous Network Domains 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 September 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes a NSIS QoS Model for inter-domain signaling (InterDomain-QOSM) between adjacent domains to enable end-to-end QoS provisioning over heterogeneous network domains. Specifically, it assumes a distinct separation between the intra-domain control plane and the inter-domain control plane at each administrative domain and is intended to implement a common inter-domain interface that allows the QoS negotiation and setup of inter-domain traffic streams while hiding the heterogeneity of intra-domain control mechanisms in use in a chain of heterogeneous network domains. The InterDomain-QoSM in this document first describes its operation mode and then the additional QSPEC parameters for fulfilling the common inter-domain interface are specified, followed by the illustrations of how the InterDomain-QOSM interacts with some typical intra-domain QoS models Zhang, et al. Expires September 06, 2006 [Page 1] Internet-Draft InterDomain-QOSM March 2006 to achieve the end-to-end QoS provisioning over heterogeneous domains in a standardized and dynamic way. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .4 3. The Distinct Seperation of Intra-domain Control Plane and Inter-domain Control Plane . . . . . . . . . . . . . . . . . 5 3.1 The Requirements of the Inter-domain Control Plane. . . .6 4. The Overview of the NSIS InterDomain-QOSM. . . . . . . . . . 7 4.1 The operation model of the NSIS InterDomain-QOSM . . . . 7 4.2 Basic features of InterDomain-QOSM . . . . . . . . . . .10 5. InterDomain-QOSM, Detailed Description . . . . . . . . . . .10 5.1 Additional QSPEC Parameters for InterDomain-QOSM . . . .10 5.1.1 parameter . . . . . . . . . . . . . . 10 5.1.2 parameter . . . . . . . . . . . . . .11 5.1.3 parameter . . . . . 11 5.1.4 parameter . . . . . 11 5.2 Illustrations of Inter-domain Signaling Interactions . .12 5.2.1 Inter-domain signaling for the case that RMD-QOSM at domain A and Y.1541-QOSM at domain B . . . . . 12 5.2.2 Inter-domain signaling for the case that Y.1541-QOSM at domain A and RMD-QOSM at domain B..13 5.2.3 Inter-domain signaling for the case that RMD-QOSM at domain A and non-NSIS based QOSM at domain B ..13 5.2.4 Inter-domain signaling for the case that non-NSIS based QOSM at domain A and RMD-QOSM at domain B ..13 5.3 The Discovery of Peer Inter-domain Control Agent . . . .14 6. Security Consideration. . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . .14 8. Open issues. . . . . . . . . . . . . . . . . . . . . . . . .15 9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . .15 10. Normative References . . . . . . . . . . . . . . . . . . . 15 11. Informative References . . . . . . . . . . . . . . . . . . 15 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 16 13. Intellectual Property Statement . . . . . . . . . . . . . .16 Zhang, et al. Expires September 06, 2006 [Page 2] Internet-Draft InterDomain-QOSM March 2006 1. Introduction Although a number of QoS (Quality of Service) architectures (e.g., IntServ [RFC2210] and Diffserv [RFC2475, RFC2638]) has been proposed by the Internet community, there are still some barriers to overcome to realize the end-to-end QoS provisioning over heterogeneous network domains. Among them, one major barrier to the achievement of end-to-end QoS over heterogeneous environments is the lack of a standardized and dynamic approach to perform inter-domain QoS interactions between adjacent domains. To address this barrier, one consensus of the Internet community is that a distinct separation between the intra-domain control plane and the inter-domain control plane must be made and a common inter-domain control interface must be available at each administrative domain that allows the inter-domain interactions independent from the intra-domain control mechanisms and the QoS negotiation and setup of inter-domain traffic streams implemented in a standardized and dynamic way. The QoS NSIS Signaling Layer Protocol (QoS-NSLP) [QoS-NSLP] defines message types and generic QoS control information for supporting a class of QOSMs (QoS Model). A QOSM is a defined mechanism for achieving QoS-related operations (e.g., negotiation, setup, update and release of required QoS) in a manner that is consistent with either the technology in use in a network domain (intra-domain QOSM) or the specification of inter-domain interactions in use between adjacent domains (inter-domain QOSM). The RMD-QOSM [RMD-QOSM] and Y.1541-QOSM [Y.1541-QOSM] are examples of the NSIS based intra-domain QOSMs. This document describes a NSIS based inter-domain QOSM (InterDomain-QOSM) which aims to assume the concept of distinct separation between the intra-domain control plane and the inter-domain control plane at each administrative domain and to implement a common inter-domain interface between adjacent domains so that the inter-domain interactions will be fulfilled in a standardized and dynamic way to facilitate the realization of end-to-end QoS provisioning over heterogeneous network domains. Specifically, this document first describes the concept of distince separation between the intra-domain control plane and the inter-domain control plane at each administrative domain and presents the operation model of the InterDomain-QOSM which is to enable a common inter-domain control interface, independent from the intra-domain control algorithms. The additional QSPEC parameters for implementing the common inter-domain interface are then specified, followed by the illustrations of how the InterDomain-QOSM will interact with some typical intra-domain QOSMs to realize the end-to-end QoS provisioning over heterogeneous domains. 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 [RFC2119]. Zhang, et al. Expires September 06, 2006 [Page 3] Internet-Draft InterDomain-QOSM March 2006 The terminology defined by GIST [GIST] and QoS-NSLP [QoS-NSLP] applies to this draft. In addition, the following terms are used: Edge node: an node on the boundary of an administrative domain. Ingress node: An edge node that handles the traffic as it enters the domain. Egress node: An edge node that handles the traffic as it leaves the domain. Inter-domain control agent: A domain-wide centralized agent at an administrative domain, which implements a common inter-domain control interface and is responsible for the inter-domain interactions between adjacent domains via the common inter-domain interface. Intra-domain control agent: An abstract entity which is responsible for performing all intra-domain control mechanisms in a manner appropriate to the specific network technology in use at an administrative domain. Note that it can be implemented in a centralized or distributed mode, i.e., a single domain-wide intra-domain control agent (centralized mode) or a set of local intra-domain control agents (distributed mode). Customer: a customer denotes an entity which has the ability to subscribe to the services offered by providers. Provider: a provider denotes a business entity which owns an administrative domain and is responsible for its operation and the provision of Internet connectivity aspects. Service Level Agreement (SLA): a SLA is concluded between a customer and a provider, where the customer can be a end-user or a peer provider. A SLA providers a guarantee that traffic offered by a Customer that meets certain stated conditions, will receive one or more particular service levels. The guarantees may be hard or soft, may carry certain tariffs, and may also carry certain monetary or legal consequences if they not met. Service Level Specification (SLS): a SLS contains the technical details of the agreement specified by a SLA. A SLS has, as its scope, the acceptance and treatment of traffic meeting certain conditions and arriving from a end-user or a peer provider. Customer SLS (cSLS): the type of SLS established between end-users and providers. Peer SLS (pSLS): the type of SLS established between peer domains, presumably (logically) adjacent, where one domain is the service provider and the other domain is the customer. Zhang, et al. Expires September 06, 2006 [Page 4] Internet-Draft InterDomain-QOSM March 2006 3. The Distinct Seperation of Intra-domain Control Plane and Inter-domain Control Plane To facilitate the realization of end-to-end QoS provisioning over heterogeneous network domains, one consensus of the Internet community is that a distinct separation between the intra-domain control plane and the inter-domain control plane must be made and a common inter-domain control interface must be available at each administrative domain that allows the inter-domain interactions independent from the intra-domain control mechanisms and the QoS negotiation and setup of inter-domain traffic streams implemented in a standardized and dynamic way [DCPEL-requirements]. Figure 1 shows a high-level view of such distinct seperation made at two adjacent domains. More sepecific, at each administrative domain, the intra-domain control agent is responsible for performing all intra-domain control mechanisms in a manner appropriate to the network technology in use at the domain and the inter-domain control agent implements a common inter-domain control interface and is responsible for the inter-domain interactions with its peer via the common inter-domain interface. Note that the intra-domain control agent shown in Figure 1 is an abstract entity, which can be implemented in a centralized or distributed mode, i.e., via a single domain-wide intra-domain control agent (centralized mode) or a set of local intra-domain control agents (distributed mode). Whereas, the inter-domain control agent is normally (or always) implemented in a centralized mode, i.e., a network-wide centralized inter-domain control agent exists at each domain, which is well-known to the intra-domain control agent(s) at its domain. +----------------------------+ +----------------------------+ |Domain A | |Domain B | | | | | | | | | | +-------+ +-------+ | | +-------+ +-------+ | | |Intra- | |Inter- | | | |Inter- | |Intra- | | | |domain |<<<>>>|domain |<--|---------|-->|domain |<<<>>>|domain | | | |control| |control| |Common | |control| |control| | | |agent | |agent | |inter- | |agent | |agent | | | +-------+ +-------+ |domain | +-------+ +-------+ | | (centralized (centralized)|control | (centralized) (centralized | | or |interface| or | | distributed) | | distributed)| +----------------------------+ +----------------------------+ <<<>>> = interactions between the intra-domain control agent and the inter-domain control agent at a domain <----> = common inter-domain interface between peer inter-domain control agents at adjacent domains Figure 1: The high-level view of the inter-domain interactions between two adjacent domains where the distinct seperation between the intra-domain and inter-domain control planes is made and a common inter-domain control interface exists. Zhang, et al. Expires September 06, 2006 [Page 5] Internet-Draft InterDomain-QOSM March 2006 3.1. The Requirements of the Inter-domain Control Plane The requirements of the inter-domain control plane (i.e., the functions provided by the inter-domain control agent in Figure 1) which is required to implement a common inter-domain control interface to facilitate the support of end-to-end QoS provisioning over heterogeneous network domains are summarized below. Note that they are derived closely based on the ones outlined by the proposed Diffserv Control Plane Elements (DCPEL) BOF in its document [DCPEL-requirements]. The Requirements of the Inter-domain Control Plane: o A common inter-domain control interface, which allows the QoS negotiation and set-up of inter-domain traffic streams while hiding intra-domain characteristics from inter-domain interactions (i.e., independent from the specifics of the intra-domain control plane), must be implemented by the inter-domain control plane. o Signaling Communications over the common inter-domain interface must be made based on a well-understood information model for SLSs. This model should allow the definition of different degrees of SLSs, from per-flow, more suitable for end-hosts or small networks, to per-aggregate, more suitable for large networks. It should also allow the identification of the SLS validity and a set of time periods over each the SLS must be available (activated), besides the information about the QoS characteristics. o The inter-domain control plane at each domain must be able to keep established and/or available/offered pSLSs. The pSLS is associated with the identity of the network domain offering or requesting the SLS. o The inter-domain control plane must allow network domains negotiate and set up pSLSs between adjacent domains. Policy information specific to the requester, or other general policies must be checked to determine if the requested SLS can the accepted. o The inter-domain control plane at each domain must be able to ensure that the traffic streams its domain sends are in conformity with the established agreement. Packets might need to be re-marked from one internal traffic class identifier to the inter-domain SLS identifier, which then might need to be re-marked from the inter-domain SLS identifier to another internal traffic class identifier used at its adjacent domain. o The inter-domain control plane should be able to support the QoS query, request, response and monitor operations in a chain of heterogeneous network domains on a per-flow or per-aggregate basis via the common inter-domain control interface. Zhang, et al. Expires September 06, 2006 [Page 6] Internet-Draft InterDomain-QOSM March 2006 o The inter-domain control plane should be able to support the automatic inter-domain adjustment in the scenario of mobile end customers. 4. The Overview of the NSIS InterDomain-QOSM The InterDomain-QOSM described in this document assumes the distinct separation between the intra-domain control plane and the inter-domain control plane at each administrative domain and then tries to fulfill the above requirements of the inter-domain control plane by implementing the inter-domain control agent (see Figure 1) through specifying a NSIS QOSM. The operation model and the basic features of the InterDomain-QOSM are presented below, respectively. 4.1 The operation model of the NSIS InterDomain-QOSM The operation model of the InterDomain-QOSM is illustrated in Figure 2, where at each administrative domain, the domain-wide centralized inter-domain control agent implements the NSIS InterDomain-QOSM and the intra-domain control agent is an abstract entity which can deploy any intra-domain QoS model (e.g., centralized or distributed, NSIS based or non-NSIS based). Moreover, the inter-domain control agent is located at a well-known QNE at its domain where the QoS-NSLP is stateful and the path-coupled or path-decoupled NTLP are both possible to be used to discover its peers at the adjacent domains. The expanation of the operation model is presented below. Note that the InterDomain-QOSM assumes that the pSLSs between the adjacent domains have been established or discovered by some other protocols (e.g., QoS-aware BGP protocol) and those pSLSs are maintained at the inter-domain control agent. Source Domain | Transit Domain | Sink Domain | | Inter- | Inter- | domain | domain | control | control | agent | agent | QoS Trigger +------+ 3| +------+ 6 | +------+ | ^ | |--|->| |-------------|->| | 1| |12 |Inter |10| |Inter | 9 | |Inter | V | |Domain|<-|--|Domain|<------------|--|Domain| +-------+ 2 |QOSM | | |QOSM | 4 +-------+ | |QOSM | 7 +-------+ |intra- |-->| | | | |-->|intra- | | | |-->|intra- | |domain | 11| | | | | 5 |domain | | | | 8 |domain | |QOSM1 |<--| | | | |<--|QOSM2 | | | |<--|QOSM3 | | | |------| | |------| | | | |------| | | |Intra- | | QoS- | | | QoS- | |Intra- | | | QoS- | |Intra- | |domain | | NSLP | | | NSLP | |domain | | | NSLP | |domain | |control| |------| | |------| |control| | |------| |control| |agent | | NTLP*| | | NTLP*| |agent | | | NTLP*| |agent | +-------+ +------+ | +------+ +-------+ | +------+ +-------+ NTLP*: path-coupled or path-decoupled NTLP Figure 2: The operation model of the InterDomain-QOSM Zhang, et al. Expires September 06, 2006 [Page 7] Internet-Draft InterDomain-QOSM March 2006 When a QoS request or query with its SLS parameters is received by the intra-domain control agent at the source domain (step 1), the intra-domain control agent first need to authenticate the request or query is from an authorized QoS trigger and then make the intra-domain QoS operations to determine the result of the QoS request or query at the source domain. In case of positive decisions, the intra-domain control agent will forward to the well-known inter-domain control agent at its domain the QoS request or query with the SLS parameters as well as the egress node of the source domain to which the request or query is assigned and the ingress node of the transit domain from which the request or query will be accepted (step 2). The inter-domain control agent at the source domain then need to check whether the received SLS parameters fit in the pSLS established between the egress node of the source domain and the ingress node of the transmit domain assigned to the request or query. If there is the positive outcome of the above check, the inter-domain control agent will maintain the IP interfaces of the egress and ingress nodes for the QoS request or query, contruct a new QoS-NSLP RESERVE or QUERY message with the QSPEC object containing all received SLS, egress and ingress node parameters as well as the POLICY_DATA object containing its ID and authentication information, and send the message to its peer at the transit domain (step 3). When the inter-domain control agent at the transit domain receives a QoS-NSLP RESERVE or QUERY message from its peer, it will take the following actions: a. Authenticate that the RESERVE or QUERY message is indeed from a peer by using the information containing in the POLICY_DATA object of the received message. b. Check that the SLS parameters containing in the QSPEC object of the received message fall within the pSLS established between the egress and ingress nodes in the QSPEC object. c. Determine whether the QoS request or query may be accepted according to the policies of the domain. In case that all the decisions have positive outputs, the inter-domain control agent at the transit domain will also maintain the IP interfaces of the egress and ingress nodes for the QoS request or query, and then send the SLS parameters and the IP interface of the ingress node from which the request or query will be admitted into the transit domain to the intra-domain control agent of its domain (step 4). After the intra-domain control agent confirms that the request or query is from an authorized QoS trigger (in this case, the inter-domain control agent), it will apply its intra-domain control mechanisms to the QoS request or query. In case of positive outcome, the intra-domain control agent should send the SLS parameters, the IP interface of the egress node of the transit domain to which the QoS request or query is assigned and the IP interface of the ingress node of the sink domain from which the QoS request or query will be accepted to the inter-domain control agent (step 5), which will first determine if the SLS parameters fall within the pSLS established between the assigned egress node of the transit domain and the assigned ingress node of the sink domain. Zhang, et al. Expires September 06, 2006 [Page 8] Internet-Draft InterDomain-QOSM March 2006 In case of positive decision, the inter-domain control agent at the transit domain need to maintain the IP addresses of the above two egress and ingress nodes (the information about the IP interfaces maintained at each inter-domain control agent is summarized in Table 1), then to construct a new QoS-NSLP RESERVE or QUERY message with the QSPEC object containing the SLS parameters and the IP addresses of the above egress and ingress nodes as well as the POLICY_DATA object containing its ID and authentication information, and send the message to the its peer at the sink domain (step 6). --------------+------------------------------------------------------ |- IP interface of its egress node assigned to the QoS Source Domain | request or query |- IP interface of the ingress node from which the QoS | request or query is admitted into the transit domain --------------+------------------------------------------------------ |- IP interface of the egress node of the source domain Transit Domain| assigned to the QoS request or query |- IP interface of its ingress node from which the QoS | request or query is admitted into the transit domain |- IP interface of its egress node assigned to the QoS | request or query |- IP interface of the ingress node from which the QoS | request or query is admitted into the sink domain --------------+------------------------------------------------------ |- IP interface of the egress node of the transit Sink Domain | domain assigned to the QoS request or query |- IP interface of its ingress node from which the QoS | request or query is admitted into the sink domain --------------+------------------------------------------------------ Table 1: The IP interfaces of the egress and ingress nodes maintained at each inter-domain control agent. The inter-domain control agent at the sink domain will also need to check if the SLS parameters in the RESERVE or QUERY message fall within the pSLS between the egress node of the transit domain and its ingress node contained in the InterDomain-QOSM QSPEC of the RESERVE or QUERY message and maintain their IP interfaces (see Table 1) when the check result is positive. Then, the SLS parameters and the IP interface of the ingress node will be sent to the intra-domain control agent at the sink domain (step 7), which takes care of the intra-domain treatment of the QoS request or query and then send back its response (step 8). In case of positive response, it will be propagated directly between the inter-domain control agents via the QoS-NSLP RESPONSE message (steps 9 and 10). In case of negative result of QoS request from adjacent domain, the inter-domain control agent should also inform it to its intra-domain control agent so that the reserved resources at this domain can be teared down (this step is not reflected in Figure 2 due to limited space). When the RESPONSE message reaches the inter-domain control agent at source domain, its content will be sent to the intra-domain control agent at the domain (step 11), which will further forward it to the initial QoS trigger ( step 12). Zhang, et al. Expires September 06, 2006 [Page 9] Internet-Draft InterDomain-QOSM March 2006 4.2 Basic features of InterDomain-QOSM The basic features of the InterDomain-QOSM described in this document include: o The SLS parameters and QoS control information required for the inter-domain QoS interactions are specified by using/extending the QSPEC template in [NSIS-QSPEC]. o The InterDomain-QOSM resides on top of the QoS-NSLP [QoS-NSLP] and NTLP, which means that it uses the messages, objects and procedures defined by the QoS-NSLP for signaling exchanges with other QNEs and depends on the NTLP to discover the peer inter-domain control agents at the adjacent domains. o The InterDomain-QOSM makes no assumptions about the implementation mechanisms of intra-domain control agent. That is to say that the intra-domain control agent might be centralized or distributed, NSIS based or non-NSIS based. o The InterDomain-QOSM makes no assumption about the method that the underlying NTLP might use to discover the peer inter-domain control agents at adjacent domains. 5. InterDomain-QOSM, Detailed Description 5.1 Additional QSPEC Parameters for InterDomain-QOSM First of all, two new QoS control parameters and need to be added to the QSPEC Control Information of the InterDomain-QOSM, which describes the IP interfaces of the egress and ingress nodes to which the signaled traffic stream is assigned respectively. Secondly, to describe the time periods over which a SLS will be available or requested, the following