NSIS Working Group J. Zhang Internet Draft E. Monteiro University of Coimbra Expiration Date: August 20, 2006 February 19, 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 August 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 of an 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 fulfulling the common inter-domain interface are specified, followed by the illustrations of how the InterDomain-QOSM cooperates with some typical intra-domain QOSMs. Zhang, et al. Expires August 20, 2006 [Page 1] Internet-Draft InterDomain-QOSM February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .4 3. Summary of Inter-domain Signaling Requirements for end-to-end QoS Provisioning Over Heterogeneous Network Domains . . . . .5 3.1 Inter-domain Control. . . . . . . . . . . . . . . . . . .5 3.2 Inter-domain Signaling Requirements . . . . . . . . . . 6 3.3 Basic Features of InterDomain-QOSM . . . . . . . . . . . 6 3.3.1 Basic features of InterDomain-QOSM . . . . . . . . 6 3.3.2 The operation model of the InterDomain-QOSM . . . .7 4. InterDomain-QOSM, Detailed Description . . . . . . . . . . . 9 4.1 Additional QSPEC Parameters for InterDomain-QOSM . . . . 9 4.1.1 parameter . . . . . . . . .9 4.1.2 parameter . . . . . 10 4.1.3 parameter . . . . . 10 4.2 Illustrations of Inter-domain Signaling Interactions . .10 4.2.1 Inter-domain signaling for the case that RMD-QOSM at domain A and Y.1541-QOSM at domain B . . . . . 10 4.2.2 Inter-domain signaling for the case that Y.1541-QOSM at domain A and RMD-QOSM at domain B..11 4.2.3 Inter-domain signaling for the case that RMD-QOSM at domain A and non NSIS domain at B . . . . . . .12 4.2.4 Inter-domain signaling for the case that non NSIS domain at domain A and RMD-QOSM at domain B . . . 12 4.3 The Discovery of Peer Inter-domain Control Agent . . . .13 5. Security Consideration. . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . .13 7. Open issues. . . . . . . . . . . . . . . . . . . . . . . . .14 8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . .14 9. Normative References . . . . . . . . . . . . . . . . . . . .14 10. Informative References . . . . . . . . . . . . . . . . . . 15 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 15 12. Intellectual Property Statement . . . . . . . . . . . . . .15 Zhang, et al. Expires August 20, 2006 [Page 2] Internet-Draft InterDomain-QOSM February 2006 1. Introduction This document describes a Next Steps In Signaling (NSIS) QoS Model for inter-domain signaling (InterDomain-QOSM) which aims at implementing a common inter-domain interface between adjacent domains so that the inter-domain interactions for provisioning end-to-end QoS over heterogeneous network domains can be realized automatically and dynamically while hiding the heterogeneity of the specific network technology in use at each domain. Nowadays, it is generally believed in the networking community that, to support end-to-end QoS provisioning over heterogeneous network domains, a distinct separation between intra-domain control plane and inter-domain control plane must be made and a common inter-domain control interface must be available at each domain that allows the QoS negotiation and setup of inter-domain traffic streams while hiding the intra-domain operations from the inter-domain interactions. The Quality of Service NSIS Signaling Layer Protocol (QoS-NSLP) [QoS-NSLP] defines message types and generic QoS control information for supporting a class of QOSMs. 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 inside a network domain (intra-domain QOSM) or the inter-domain interaction defination in use between adjacent domains (inter-domain QOSM). The IntServ [RFC2210], RMD-QOSM [RMD-QOSM] and Y.1541-QOSM [Y.1541-QOSM] are examples of intra-domain QOSMs. Figure 1 shows a high-level view of inter-domain interactions between two adjacent domains for supporting end-to-end QoS provisioning over heterogeneous network domains. Specifically, at each domain, there exists a single well-known inter-domain control agent, which is responsible particularly for the inter-domain interactions with its peer in adjacent domains via a common inter-domain interface. Note that, the intra-domain control may be implemented by a single domain-wide agent, or by a group of local agents. The distribution of intra-domain control over a set of local-agents and the specific intra-domain control mechanisms will depend on the network technology in use at each domain. However, the interface between the peer inter-domain control agent can be standardized to hide the heterogeneity of the intra-domain control mechanisms and make the inter-domain control function independent from the intra-domain one. The InterDomain-QoSM described in this draft is the example of inter-domain QOSM, which aims at implementing the common inter-domain interface (see Figure 1) to facilitate the support of end-to-end QoS provisioning over heterogeneous network domains. Specifically, it first describes its operation mode for inter-domain interactions and then the additional QSPEC parameters for fulfulling the common inter-domain interface are specified, followed by the illustrations of how the InterDomain-QOSM cooperates with some typical intra-domain QOSMs. Zhang, et al. Expires August 20, 2006 [Page 3] Internet-Draft InterDomain-QOSM February 2006 +----------------------------+ +----------------------------+ |Domain A | |Domain B | | | | | | | | | | +-------+ +-------+ | | +-------+ +-------+ | | |Intra- | |Inter- | |Common | |Inter- | |Intra- | | | |domain |<<<>>>|domain |<--|---------|-->|domain |<<<>>>|domain | | | |control| |control| |Inter- | |control| |control| | | |agent | |agent | |domain | |agent | |agent | | | +-------+ +-------+ |Interface| +-------+ +-------+ | | (centralized (centralized)| | (centralized) (centralized | | or | | or | | distributed) | | distributed)| +----------------------------+ +----------------------------+ <<<>>> = interactions between the intra-domain control agent and inter-domain control agent inside each domain <----> = common inter-domain interface between peer inter-domain control agents at adjacent domains Figure 1: The high-level view of inter-domain interactions between two adjacent domains for supporting end-to-end QoS provisioning over heterogeneous network 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]. The terminology defined by GIST [GIST] and QoS-NSLP [QoS-NSLP] applies to this draft. In addition, the following terms are used: Inter-domain control agent: a domain-wide (NSIS-capable) node inside an administrative domain, which is responsible for the inter-domain interactions between adjacent domains. Intra-domain control agent: a domain-wide node (centralized mode) or a set of local nodes (distributed mode) at an administrative domain, responsible for all the intra-domain related QoS operations appropriate to the specific network technology in use at the domain. Zhang, et al. Expires August 20, 2006 [Page 4] Internet-Draft InterDomain-QOSM February 2006 Service Level Specification (SLS): is a set of parameters and their values which together define the service offered to a traffic flow or a class of service by an administrative domain. 3. Summary of Inter-domain Signaling Requirements for End-to-end QoS Provisioning Over Heterogeneous Network Domains 3.1. Inter-domain Control Although a number of QoS architecture (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. One of them is the lack of an automatic and dynamic approach to control QoS agreements between network domains. To confront this barrier, it is generally believed that a distinct separation between intra-domain control plane and inter-domain control plane must be made and a common inter-domain control interface must be available at each domain that allows the standardized QoS negotiation and setup of inter-domain traffic streams while hiding the heterogeneity of the intra-domain control mechanisms. The preliminary requirements for the inter-domain control plane to support end-to-end QoS provisioning over heterogeneous network domains are presented below, which are derived closely based on the ones outlined by the proposed Diffserv Control Plane Elements (DCPEL) BOF in its document [DCPEL-requirements]. o A common inter-domain control interface must be available, allowing the QoS set-up of inter-domain traffic streams while hiding intra-domain characteristics from inter-network operations. o The inter-domain control interface should be independent from the specifics of the intra-domain control plane. o Communication over a 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 Each domain must have a set of policies to coordinate its activities as provider, customer, or customer-provider of SLSs, and must keep information about established and available/offered agreements. This information may be associated with the identity of the user or network offering or requesting SLSs. Zhang, et al. Expires August 20, 2006 [Page 5] Internet-Draft InterDomain-QOSM February 2006 o The inter-domain interface must allow network domains to offer, request/negotiate and monitor agreements/SLSs. Policy information specific to the requester, or other general policies must be checked to determine if the requested agreement can the accepted. o Each domain must ensure that the data packets it sends are in conformity with the established agreement or risk of having packets dropped. Packets should be re-marked from the internal traffic class identifier to the inter-domain SLS identifier if needed. At the provider side, packets may be re-marked from the SLS identifier to its internal traffic class identifier. o A network domain or end-host should be able to receive information about the nature of QoS assurances available to a specific destination network from the attached access network, either upon attachment or through queries. o End-to-end signaling may be used to check the available QoS guarantees in a chain of heterogeneous network domains on a per-flow or per-aggregate basis. o Should support mobile end-hosts and networks, which requires automatic adjustment of inter-domain agreements. 3.2. Inter-domain Signaling Requirements To fulfill the above requirements for inter-domain control plane, the initial requirements for the inter-domain signaling between peer inter-domain control agents (see Figure 1) are summarized below: o A set of SLS parameters related to the inter-domain interections while hiding the specific intra-domain control mechanisms must be well specified. Besides the information about the QoS characteristics, the parameters describing the time periods over which the SLS will be available or activated should also be included. o The support of signaling operations which perform the QoS query, request, monitor and response between adjacent domains on a per-flow or per-aggregate basis. o The support of signaling operations which perform the end-to-end QoS query, request, monitor and response across a chain of heterogeneous domains on a per-flow or per-aggregate basis. o The support of signaling operations for automatic adjustment of inter-domain QoS agreements in the case of mobile end-hosts. 3.3. Basic features of InterDomain-QOSM 3.3.1 Basic features of InterDomain-QOSM The basic features of the InterDomain-QOSM described in this document include: Zhang, et al. Expires August 20, 2006 [Page 6] Internet-Draft InterDomain-QOSM February 2006 o The SLS parameters required for the inter-domain interactions are specified by using/extending the QSPEC model in [NSIS-QSPEC]. o The signaling operations requested by the inter-domain signaling requirements in section 3.2 are illustrated by using the QoS-NSLP messages in [QoS-NSLP]. o The InterDomain-QOSM makes no assumptions about the intra-domain QoS operations of the intra-domain control agent. The intra-domain control agent can be centralized or distributed, NSIS-capable or NSIS-incapable, etc. o The InterDomain-QOSM makes no assumption about the message routing method the NTLP might use to discover the peer inter-domain control agent at the adjacent domain, i.e., it might use a path-coupled or path-decoupled NTLP. 3.3.2 The operation model of the InterDomain-QOSM The operation model of the InterDomain-QOSM is illustrated in Figure 2, where the intra-domain control agent of two adjacent administrative domains deploys the local QOSM1 and QOSM2 respectively and we make no assumptions about their implementation mechanisms (e.g., centralized or distributed, NSIS-aware or NSIS-unaware). Moreover, the inter-domain control agent at each domain is located at a well-known QNE where the QoS-NSLP is stateful and we make no assumptions about how the inter-domain control agent will discover its peer at the adjacent domain. Furthermore, the inter-domain control agent is dedicated to performing all inter-domain related interactions, the intra-domain control agent is dedicated to dealing with all intra-domain related operations and a distinct separation is made between intra-domain and inter-domain controls. +-----------------------------+ +---------------------------+ |Domain A Inter- | | Inter- Domain B| | domain | | domain | | control | | control | | agent | | agent | |To adjacent peer +------+ | | +------+ To adjacent peer| <-|------------------>|Inter |<-|----|->|Inter |<----------------|-> | |Domain| | | |Domain| | |intra- +-------+ |QOSM | | | |QOSM | +-------+ | |domain |local |<->| | | | | |<->|local | | |trigger|QOSM1 | | | | | | | |QOSM2 | | | ----->| | |------| | | |------| | | | | |Intra- | |QoS- | | | |QoS- | |Intra- | | | |domain | |NSLP | | | |NSLP | |domain | | | |control| |------| | | |------| |control| | | |agent | |NTLP* |<-|.-.-|.>|NTLP* | |agent | | | +-------+ +------+ | | +------+ +-------+ | | | | | +-----------------------------+ +---------------------------+ NTLP*: path-decoupled or path-coupled NTLP Figure 2: Operation model of InterDomain-QOSM Zhang, et al. Expires August 20, 2006 [Page 7] Internet-Draft InterDomain-QOSM February 2006 In addition, the basic signaling exchanges for describing the operation mode of InterDomain-QOSM are shown in Figure 3. First of all, when a QoS request is created by a trigger inside domain A, the intra-domain control agent at domain A handles it and then will send an inter-domain QoS request with the appropriate SLS parameters to the inter-domain control agent if the initial request needs the inter-domain interactions with domain B. In that case, the inter-domain control agent at domain A need construct a RESERVE message with the InterDomain QSPEC and send it to the peer at domain B. After receiving the RESERVE message, the inter-domain control agent at domain B might first check the requested SLSs against the inter-domain agreements existed between domain A and domain B and then extract the requested SLS parameters from the RESERVE message and forward them to the intra-domain control agent at domain B for processing. In the case that domain B is the destination domain, the intra-domain control agent at domain B will create and send its response to the previous QoS request to the inter-domain control agent at its domain, which will construct and send a RESPONSE message to the inter-domain peer at domain A. The inter-domain control agent at domain A then forwards the response to the intra-domain control agent at its domain, which will finally propagate the response to the sender of the initial QoS request by using the appropriate mechanisms in use at the domain. QNE QNE QNE Intra-domain Inter-domain Inter-domain Intra-domain control agent control agent control agent control agent at Domain A at Domain A at Domain B at Domain B | | inter-domain | | inter-domain interactions | | interactions <------------------------>| |<---------------------> | | QoS request| | | | ---------->| | | | from intra-| inter-domain | | | domain +-------------->| | | trigger | QoS request | RESERVE | | | +-------------->| | | | | intra-domain | | | +------------->| | | | QoS request | | | | | | | | response | | |<-------------+ | | RESPONSE | | | |<--------------+ | | response | | | |<--------------+ | | response | | | | <---------+ | | | | | | | Figure 3: Sender-initiated reservation with inter-domain interactions between two adjacent domains Zhang, et al. Expires August 20, 2006 [Page 8] Internet-Draft InterDomain-QOSM February 2006 It can be seen from Figure 3 that all the inter-domain interactions must be proceeded via the inter-domain control agent and the intra-domain agent deals with only the intra-domain operations. In addition, except for the inter-domain control agent, we make no assumption about the implementation mechanisms of both intra-domain control agent and QoS triggers. For the case that the intra-domain control agent is implemented via a NSIS intra-domain QOSM (e.g., RMD-QOSM or Y.1541-QOSM), the inter-domain control agent will forward its processed QoS-NSLP messages to the intra-domain control agent for the intra-domain processing; thus, the intra-domain control agent need also to support the InterDomain-QOSM besides its own intra-domain QOSM. For the case that the intra-domain control agent is implemented via other mechanisms, the inter-domain control agent might extract the SLS parameters from the InterDomain QSPEC and forward these parameters to the intra-domain control agent for further intra-domain related processing. Several inter-domain interaction scenarios are illustrated in Section 4. 4. InterDomain-QOSM, Detailed Description 4.1 Additional QSPEC Parameters for InterDomain-QOSM First of all, one new parameter named is added to the QSPEC Control Information of InterDomain-QOSM, which contains the IP interface of the ingress border router from which the signaled traffic stream will be admitted into the adjacent next domain. Secondly, to describing the time periods over which the SLS will be available or activated, the following