NSIS Working Group J. Zhang Internet-Draft Queen Mary, Univ. of London Expires: September 2007 E. Monteiro University of Coimbra P. Mendes DoCoMo Euro-Labs G. Karagiannis University of Twente J. Andres-Colas Telefonica I+D InterDomain-QOSM: The NSIS QOS Model to Fulfill the E2E QoS Control in the ITU-T RACF Functional Architecture 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 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Zhang, et al. Expires September 2007 [Page 1] Internet-Draft InterDomain-QOSM March 2007 Abstract This document has three goals. First of all, it presents our analysis of how to use the NSIS signaling (inter-domain QOSM and intra-domain QOSM) to fulfill the QoS control in accord with the ITU-T RACF functional architecture. For this goal, we discuss how the ITU-T RACF entities in the ITU-T RACF functional architecture can be mapped to the NSIS entities and how the RACF reference points can be implemented by using the NSIS protocol suites and QOSMs. Secondly, we aim at specifying an NSIS Inter-domain QOSM for E2E QoS control across heterogeneous IP networks and applying this Inter-domain QOSM to the e2e QoS control in the ITU-T RACF functional architecture based on the above ITU-T RACF analysis. The detailed description of the NSIS Inter-domain QOSM are given and the e2e QoS control scenarios in the ITU-T RACF architecture (including RACF Push and Pull resource control modes), which will be covered by the NSIS Inter-domain QOSM are described and implemented. Thirdly, we specify and implement those QSPECs that will be used by the Inter-domain QOSM for the e2e QoS control in the ITU-T RACF architecture. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview and Requirements of Inter-domain Signaling for End-to-End QoS Control . . . . . . . . . . . . . . . . . . . 7 3.1 The Requirements of the Inter-domain Control Plane . . . 8 3.2 The Aims and Scope of this Draft . . . . . . . . . . . .11 4. The Analysis of Applying the NSIS Signaling to QoS Control in the ITU-T RACF Functional Architecture . . . . . . . . 12 4.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . 12 4.2 The Analysis of Applying the NSIS Intra-domain QOSM for Intra-domain QoS Control in the ITU-T RACF . . . . .15 Functional Architecture . . . . . . . . . . . . . . . . 15 4.2.1 The ITU-T RACF functional entities . . . . . . . .15 4.2.1.1 Service control functions . . . . . . . . 15 4.2.1.2 Network Attachment Control Functions (NACF) . . . . . . . . . . . . . . . . . .16 4.2.1.3 Policy decision functional entity (PD-FE) . . . . . . . . . . . . . . . . . 16 4.2.1.4 Transport Resource Control Functional Entity (TRC-FE) . . . . . . . . . . . . . 18 4.2.1.5 Policy Enforcement Functional Entity (PE-FE) . . . . . . . . . . . . . 20 4.2.1.6 Transport resource enforcement functional Entity (TRE-FE) . . . . . . . . . . . . . 21 4.2.1.7 Customer Premises Equipment (CPE) . . . . 21 4.2.1.8 Comparison between NSIS intra-domain QOSM Features and Features supported by the ITU-T RACF functional entities . . . . . .21 Zhang, et al. Expires September 2007 [Page 2] Internet-Draft InterDomain-QOSM March 2007 4.3 The Analysis of Applying the NSIS Inter-domain QOSM for Inter-domain QoS control in the ITU-T RACF Functional Architecture . . . . . . . . . . . . . . . . 22 4.4 The mapping between ITU-T RACF Entities and NSIS Entities . . . . . . . . . . . . . . . . . . . . . . . .26 5. The Basic Features of InterDomain-QOSM . . . . . . . . . . 27 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . 28 5.2 The Assumptions for the Interdomain-QOSM. . . . . . . . 28 5.2.1 GIST Analysis . . . . . . . . . . . . . . . . . . 29 5.2.2 QoS-NSLP Analysis . . . . . . . . . . . . . . . . 32 5.3 The support of ITU-T RACF end-to-end QoS control via the InterDomain-QOSM . . . . . . . . . . . . . . . .32 6. InterDomain-QOSM, Detailed Description . . . . . . . . . . 33 6.1 Additional QSPEC Parameters for End-to-End QoS Control By the InterDomain-QOSM . . . . . . . . . . . . . . . . 33 6.2 The Operation Modes of InterDomain-QOSM . . . . . . . . 33 6.2.1 Operation mode 1: fully centralized . . . . . . . 33 6.2.2 Operation mode 2: fully distributed . . . . . . . 34 6.2.3 Operation mode 3: hybrid. . . . . . . . . . . . . 35 6.3 Message Format. . . . . . . . . . . . . . . . . . . . . 35 6.4 InterDomain-QOSM Node State Management. . . . . . . . . 36 6.5 InterDomain-QOSM Operations and Sequences of Events . . 36 6.5.1 Basic unidirectional operation. . . . . . . . . . 36 6.5.1.1 Successful reservation. . . . . . . . . . 36 6.5.1.2 Unsuccessful reservation. . . . . . . . . 36 6.5.1.3 Refresh reservation . . . . . . . . . . . 36 6.5.1.4 Modification of reservation . . . . . . . 36 6.5.1.5 InterDomain release procedure . . . . . . 36 6.6 Inter-domain QNE Discovery and Transport of InterDomain-QOSM Messages . . . . . . . . . . . . . . . 36 6.6.1 Requirements of InterDomain-QOSM to the Underlying Path-coupled NTLP. . . . . . . . . 36 6.6.2 Requirements of InterDomain-QOSM to the Underlying path-decoupled NTLP. . . . . . . . 36 6.7 Handling of Additional Errors . . . . . . . . . . . . . 36 7. Security Consideration. . . . . . . . . . . . . . . . . . . 37 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 37 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 37 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 38 11. References . . . . . . . . . . . . . . . . . . . . . . . . 38 11.1 Normative References . . . . . . . . . . . . . . . . 38 11.2 Informative References . . . . . . . . . . . . . . . 38 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 39 Intellectual Property Statement . . . . . . . . . . . . . . . 40 1. Introduction Although lots of efforts (e.g., IntServ [RFC2210] and Diffserv [RFC2475], [RFC2638]) had been made by the Internet community to address efficient Quality-of-Service (QoS) support in IP networks, there are still some barriers to overcome before the end-to-end QoS Zhang, et al. Expires September 2007 [Page 3] Internet-Draft InterDomain-QOSM March 2007 provisioning can be truly enabled over heterogeneous IP networks across different operators' ASs (Autonomous System). Among them, one major barrier to the achievement of end-to-end QoS over heterogeneous environments is the lack of a standardized and automatic approach to perform inter-operator-domain QoS interactions between adjacent ASs while hiding the heterogeneities of the intra-domain QoS control mechanisms in use at each operator domain. To fully address this barrier, we believe that a distinct separation between the intra-domain QoS control plane and the inter-domain QoS control plane within each AS must be made, an interface between the intra-domain and inter-domain QoS control planes at the AS must be clarified and standardized, and an interface between the peer inter-domain QoS control planes at adjacent ASs must be standardized and implemented in a way that the network operator's internal confidentials don't need to be exposed. With the above separation and interfaces, the automatic QoS negotiation and setup of inter-domain traffic streams over a chain of heterogeneous network domains will be enabled in a standardized and dynamic way, fully independent from the intra-domain QoS mechanisms in use at each AS. Recently, the ITU-T has been working on the standardization of the Next Generation Network (NGN) by proposing its definitions of the functional architecture, reference points and procedures of NGN across the service control, resource control and transport stratums. Among them, the ITU-T Y.RACF [Y.RACF] presents the requirements of QoS control over heterogeneous networks and defines the resource and admission control functional architecture and reference points for QoS control across end-to-end path. However, the implementation of the functional architecture and those reference points is untouched in the ITU-T Y.RACF document. Meanwhile, the IETF Next Steps in Signaling (NSIS) Working Group proposed a flexible IP signaling solution [RFC4080] for the Internet, where the NSIS protocol suite is structured in two layers: a generic (lower) layer, termed NSIS Transport Layer Protocol (NTLP), which is responsible for moving upper-layer signaling messages between NSIS entities and is independent of any particular signaling applications on top of it; and an upper layer, termed NSIS Signaling Layer Protocol (NSLP), which contains functionality such as upper-layer message formats and sequences, specific to a particular signaling application. Currently, the General Internet Signaling Transport (GIST) protocol [GIST] provides a concrete solution for the NTLP. Moreover, the QoS NSIS Signaling Layer Protocol (QoS-NSLP) [QoS-NSLP] defines message types and generic QoS control information for supporting the QoS signaling application together with a class of QoS Models (QOSM). A QOSM defines the detailed QoS-related procedures and operations (e.g., negotiation, setup, update and release of network resources) to achieve the requested QoS target in a manner that is consistent with either the QoS control mechanism used at a network domain (intra-domain QOSM) or between adjacent operator 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. Zhang, et al. Expires September 2007 [Page 4] Internet-Draft InterDomain-QOSM March 2007 This document has three goals. First of all, it aims at analyzing how to use the NSIS signaling protocol suites to realize the end-to-end QoS control across heterogeneous network domains in accord with the ITU-T RACF functional architecture. For this purpose, we study how the RACF entities in the ITU-T RACF functional architecture can be mapped to the NSIS entities and how the RACF reference points can be implemented by using the NSIS protocols. Furthermore, we propose to seperate the inter-domain QoS control clearly from the intra-domain QoS control and apply different NSIS QOSMs (NSIS inter-domain and intra-domain QOSMs) to them. With this approach, the QoS negotiation and setup of inter-domain traffic streams over a chain of heterogeneous operator domains can be fulfilled in a standardized and transparent way, fully independent from the intra-domain QoS mechanisms at each AS. By transparent, we mean that operators do not have to reveal any details about the internal function of their networks, including the used QoS signalling protocols. Secondly, this document aims at specifying the above NSIS Inter-domain QOSM and applying it to the e2e QoS control in the ITU-T RACF functional architecture. The detailed descriptions of how the NSIS Inter-domain QOSM will support the e2e QoS control under the ITU-T RACF Push and Pull resource control modes are presented along with its interactions with different intra-domain QOSMs. The NSIS QSPEC objects that will be used to carry the necessary information elements between the ITU-T RACF reference points are also defined. The structure of this specification is as follows. Section 2 defines terminology, and Section 3 gives an overview of inter-domain signaling requirements for end-to-end QoS control and then describes the aims and scopes of this draft document. Section 4 presents the analysis of applying the NSIS signaling to QoS control in the ITU-T RACF functional architecture and the basic features of our proposed InterDomain-QOSM are summarized in Section 5. The detailed descriptions of the InterDomain-QOSM, such as the QSPEC [NSIS-QSPEC] parameters, the operation modes and the signaling procedures and operations for fulfilling the e2e QoS control, etc, are presented in Section 6. In addition, Section 7 discusses the security consideration raised by the InterDomain-QOSM and the IANA considerations are given in Section 8. Finally, we discuss some open issues related to the mapping between the ITU-T RACF entities and the NSIS entities and some details of the InterDomain-QOSM in Section 9. 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], QoS-NSLP [QoS-NSLP] and ITU-T Y.RACF [Y.RACF] applies to this draft. Zhang, et al. Expires September 2007 [Page 5] Internet-Draft InterDomain-QOSM March 2007 In addition, the following terms are used: Edge node: Node on the boundary of an administrative domain. Ingress node: Edge node that handles the traffic as it enters the domain. Egress node: Edge node that handles the traffic as it leaves the domain. Inter-domain QoS controller: Abstract entity which is responsible for the inter-domain control mechanisms within its administrative domain, in cooperation with its logically adjacent domains via a common inter-domain interface. Depending on the kind of domain (size, network technology, method used to assure the intra-domain QOS, etc.), the inter-domain QoS controller can be implemented in a fully centralized, fully distributed or hybrid (i.e. an intermediate approach between fully centralized and fully distributed) mode. Please refer to Section 4.1 for the details of the implementation modes. Intra-domain QoS controller: 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. As happens with the inter-domain control agent, it can be implemented in a centralized, decentralized or hybrid mode. Customer: Business entity which has the ability to subscribe to the services offered by providers. Provider: Business entity which owns an administrative domain and is responsible for its operation, especially for the provision of Internet connectivity. Service Level Agreement (SLA): Contract between a customer, which can be an end-user or an administrative domain, and an administrative domain, which acts as a provider, where the provider guarantees that traffic offered by a customer meeting 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 are not met. Service Level Specification (SLS): 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 certain customer. Zhang, et al. Expires September 2007 [Page 6] Internet-Draft InterDomain-QOSM March 2007 3. Overview and Requirements of Inter-domain Signaling for End-to-End QoS Control There are scenarios that can increase their data forwarding performance by separating the control plane heavy processing from the data forwarding processing. Such scenarios are for example, described in [draft-hancock-nsis-pds-problem-03], which achieve this separation by implementing outsourcing. The outsourcing takes place when nodes located on the data forwarding give over either the complete or a part of their control plane responsibilities, such as resource management, to one or more central controlling entities. Such scenarios are able to use signaling that can propagate off path towards the central controlling entities. Several off path signaling scenarios can be distinguished, but in this draft we mainly concentrate on the path decoupled type of signaling, where signaling messages can travel on path but they might also be transferred to nodes off the data path. Off path signaling can be realized by using GIST, which can support path decoupled signaling, see [draft-hancock-nsis-pds-problem-03] and an inter-domain QOSM that in combination with the QoS-NSLP realizes a distinct separation between the intra-domain control plane and the inter-domain control plane at each administrative domain. Furthermore, the inter-domain QOSM can specify, by using a QSPEC, 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. Figure 1 shows a high-level view of such distinct separation made at two adjacent domains. More specific, at each administrative domain, the intra-domain QoS controller 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 QoS controller 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 both the intra-domain and inter-domain QoS controllers shown in Figure 1 are the abstract entity, which can be implemented in a centralized or distributed mode (see Section 5.1). Moreover, the interface between the intra-domain and inter-domain QoS controller within a domain is standardized in this document. Zhang, et al. Expires September 2007 [Page 7] Internet-Draft InterDomain-QOSM March 2007 +----------------------------+ +----------------------------+ |Domain A | |Domain B | | | | | | | | | | +-------+ +-------+ | | +-------+ +-------+ | | |Intra- | |Inter- | | | |Inter- | |Intra- | | | |domain |<<<>>>|domain |<--|---------|-->|domain |<<<>>>|domain | | | |QoS | |QoS | |inter- | |QoS | |QoS | | | |control| |control| |domain | |control| |control| | | +-------+ +-------+ |control | +-------+ +-------+ | | (centralized (centralized)|interface| (centralized) (centralized | | or or | | or or | | distributed) distributed | | distributed distributed)| +----------------------------+ +----------------------------+ <<<>>> = standardized interface between the intra-domain and inter-domain QoS controller within an administrative domain <----> = common inter-domain interface between peer inter-domain QoS controllers at adjacent domains Figure 1: The high-level view of the inter-domain interactions between two adjacent domains where the distinct separation between the intra-domain and inter-domain control planes is made and a common inter-domain control interface exists. 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] and from some of the requirements provided in [Y.RACF]. Before listing the Inter-domain Control Plane requirements we will list a number of high level requirements when the overall NSIS signaling has to be used in supporting the ITU-T Y.RACF [Y.RACF] functional architecture. Some of these requirements are copied/taken from [Y.RACF] and are: * Control the QoS-related transport resources within NSIS aware networks and at the network boundaries in accordance with their capabilities; * Support CPE's differing intelligence and capabilities; * Support resource and admission control within a single administrative domain and between administrative domains; Zhang, et al. Expires September 2007 [Page 8] Internet-Draft InterDomain-QOSM March 2007 * Support both relative QoS control and absolute QoS-control; * Verify resource availability on an end-to-end basis; * Support QoS differentiation over various categories of packet traffic including packet-type flows and user policies; * Support QoS signaling * Authorize requests for QoS and operate only on the authorised requests for QoS; * Support distributed and centralized transport resource control architectures. The resource and admission control functional architecture should meet the following optional high-level requirements: * Support methods for resource-based admission control * Have access to and make use of information provided by network management on performance monitoring to assist in making resource-based admission decisions; * Have access to and make use of the network status information provided by the underlying network infrastructure in support of end-to-end QoS when transport functions detect and report a failure; * Make use of the service priority information for priority handling (e.g., admission control based on service priority information). This includes passing of service information between entities where applicable; * Support path selection (using NSIS discovery mechanism) between ingress and egress points within a single domain to satisfy QoS resource requirements. The Requirements of the Inter-domain Control Plane are: 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 Zhang, et al. Expires September 2007 [Page 9] Internet-Draft InterDomain-QOSM March 2007 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 SLSs. The SLS 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 SLSs 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; * support the automatic inter-domain adjustment in the scenario of mobile end customers; * support both relative QoS control and absolute QoS control; * verify resource availability within its purview; * support QoS differentiation over various categories of packet traffic including flows and user designations; * operate only on authorized requests for QoS; * make use of the service priority information for priority handling; * have access to make and use of information provided network management and performance management related to resource control; Zhang, et al. Expires September 2007 [Page 10] Internet-Draft InterDomain-QOSM March 2007 * support path selection (using NSIS discovery mechanism) between ingress and egress points within a single domain. * support distributed and centralised resource control architectures; * support the following QoS resource control modes: a) Push mode: the policy and resource management decisions are pushed towards the intra-domain control plane b) Pull mode: the policy and resource management decisions are requested by the intra-domain control plane upon receiving path coupled signaling. * QoS resource control should meet the following operational requirements: * support methods for resource usage and/or QoS treatments * have access to make and use of information provided network management and performance management related to resource control * support path selection (using NSIS discovery mechanism) between ingress and egress points within a single domain. o The inter-domain QoS resource control process should consists of three logical states: * Authorization: QoS resource is authorized based on operator specific policy rules * Reservation: QoS resource is reserved based on authorized resource and resource availability * Commitment: QoS resource is committed for the requested real time flows 3.2 The Aims and Scope of this draft First of all, an analysis will be done on how to use NSIS signaling, in combination with inter-domain QOSMs and intra-domain QOSMs to realise the QOS control in accordance with the ITU-T RACF functional architecture, see [Y.RACF]. This can be accomplished by analysing how the Y.RACF entities in the ITU-T Y.RACF functional architecture can be mapped to NSIS aware entities and how the ITU-T RACF reference points can be implemented by using the NSIS protocol suites. Zhang, et al. Expires September 2007 [Page 11] Internet-Draft InterDomain-QOSM March 2007 Secondly, it is aimed to specify an NSIS Inter-domain QOSM for end-to-end QOS control across heterogeneous IP networks and apply this Inter-domain QOSM to the end-to-end QoS control in the ITU-T Y.RACF functional architecture according to the above described ITU-T RACF analysis. This can be accomplished by presenting the detailed description of the NSIS Inter-domain QOSM and the end-to-end QoS control scenarios used in the ITU-T RACF functional architecture which are supported by the NSIS Inter-domain QOSM should be specified in detail. Furthermore, this draft aims to specify those QSPEC objects that can be used by the Inter-domain QOSM for the end-to-end QoS control in the ITU-T Y.RACF architecture. This can be accomplished by specifying the QSPEC objects that will be used to carry the informational elements to implement the necessary interfaces of the Inter-domain QOSM. The scope of the draft covers the definition of the interface between the intra-domain and inter-domain QoS control planes within a domain and the definition and implementation of the inter-domain interface between peer inter-domain QoS control planes at adjacent domains by specifying the InterDomain-QOSM. Note that both these interfaces are mapped from the similar interfaces used in the ITU-T RACF architecture. For the case that non-NSIS solutions are used as the intra-domain QoS control mechanism, the implementation of RACF Rd reference point for the interactions between the intra-domain and inter-domain QoS control planes within an AS has to be specified by that non-NSIS solution, which is left to other drafts to address. 4. The Analysis of Applying the NSIS Signaling to QoS Control in the ITU-T RACF Functional Architecture 4.1 Overview The ITU-T RACF document [Y.RACF] defines the functional architecture and reference points for the resource and admission control functions at each AS (see Figure 2, which is copied from Figure 5 of [Y.RACF]), which includes the SCF (Service Control Functions), PD-FE (Policy Decision Functional Entity), TRC-FE (Transport Resource Control Functional Entity), TRE-FE (Transport Resource Enforcement Functional Entity), PE-FE (Policy Enforcement Functional Entity) and NACF (Network Attachment Control Functions). The CPE/CPN (Customer Premises Equipment/Customer premises Equipment) may be connected to the PE-FE in access network domains and the PE-FE can reside at the Zhang, et al. Expires September 2007 [Page 12] Internet-Draft InterDomain-QOSM March 2007 +-------------------------+ +--------+ |Service Control Functions| | | | |-----| | Service Stratum +---------------------^---+ | | --------------------------------------------------|---------| | Transport Stratum Rs| | | +-----------------------|----+ | Other | | RACF +-+ | | | NGNs | +------------+ | Rd| | | | | | | Network | | +-+-v-v-+ | | | | Attachment | |Ru | |Ri| | | | Control <-----------------------> PD-FE <-------> | | Functions | | +---------> | | | | | | | |Rt | | | | | +------------+ | +---v--+ +---^---+ | | | | | +---+ | | | | | |TRC-FE| |Rp | | | | | | <---+ | | | | | +-^-^--+ | | | | | Rn| |Rc |Rw | | | +-----|-|-------------|------+ | | | | | | | +---------|-v-------------|------+ | | | | | | | | | +---v--+ +---v---+ | | | | |TRE-FE| | PE-FE |-------| | | | | | | | | | | +------+ +-------+ | | | | Transport Functions | | | +--------------------------------+ +--------+ Figure 2: ITU-T RACF functional architecture network boundary to interconnect with other NGNs. Other NGNs may include access networks only or core networks only or both them. The transport functions could also apply to access networks and core networks. The ITU-T RACF consists of two types of resource and admission control functional entities: the PD-FE and the TRC-FE. The PD-FE provides a single contact point to the SCF and hides the details of transport network to the SCF. The PD-FE makes the final decision regarding network resource and admission control based on network policy rules, SLAs, service information provided by the SCF, transport subscription information provided by the NACF in access networks, and resource-based admission decision results provided by TRC-FE. The PD-FE controls the gates in the PE-FEs at per flow level. Note that the PD-FE consists of transport technology-independent resource control functions and is independent of the SCF as well. The policy rules used by PD-FE are service-based and are assumed to be provided by the network operators. Zhang, et al. Expires September 2007 [Page 13] Internet-Draft InterDomain-QOSM March 2007 The TRC-FE deals with the diversity of underlying transport technologies and provide the resource-based admission control decision results to PD-FE. The TRC-FE is service-independent and consists of transport technology-dependent resource control functions. The PD-FE requests the TRC-FE instances in the involved transport networks through the Rt reference point to detect and determine the requested QoS resource along the media flow path. The TRC-FE may collect and maintain the transport network topology and the transport resource status information and authorize resource admission control of a transport network based on network information such as topology and/or connectivity, network and element resource availability, as well as the transport subscription information in access networks. Moreover, in the ITU-T RACF functional architecture, the implementation and physical configuration of the PD-FE and TRC-FE are flexible: they can be distributed or centralized, and may be a stand-alone device or part of an integrated device; the PD-FE may contact only one designated TRC-FE instance, and then TRC-FE instances communicate with each other through the Rp reference point to detect and determine the requested QoS resource from edge to dege in the involved network, or the PD-FE may contact multiple TRC-FE instances and determine the requested QoS resource from edge to edge. In addition, in the ITU-T RACF functional architecture, the SCF represents an abstract notion of the functional entities in the service stratum of NGN that request the QoS resource and admission control for media flows of a given service via the Rs reference point; the NACF includes a collection of functional entities that provide a variety of functions for user access network management and configuration based on the user profiles; the PE-FE in the transport stratum is a packet-to-packet gateway at the boundary of different packet networks and/or between the CPE and access network; the TRE-FE in the transport stratum enforces the transport resource policy rules instructed by the TRC-FE at the technology-depedent aggregate level. Currently, the scope and functions of the TRE-FE and the Rn reference point in [Y.RACF] are for further study. Furthermore, an inter-domain reference point Ri is designated to support inter-operator domain PD-FE communication for e2e QoS control when the QoS requirements for a given service can not be passed over the end-to-end path through application layer signaling. However, there are no any details of Ri in [Y.RACF], which are still for further studies. As we can see from the ITU-T RACF document, it defines only the RACF functional architecture and reference points to ensure the inter-operability of the QoS and resource control within heterogeneous network environments but leaves the implementations of them untouched deliberately. Meanwhile, the IETF NSIS Working Group proposed a flexible IP signaling architecture [RFC4080] for IP networks, where different NSIS QOSMs can be defined to realize heterogeneous QoS control mechanisms used at underlying network Zhang, et al. Expires September 2007 [Page 14] Internet-Draft InterDomain-QOSM March 2007 domains. This section presents an analysis of how to fulfill the e2e QoS control in accord with the definitions of the ITU-T RACF functional architecture and reference points by using the NSIS protocol suites. More importantly, we adopt the idea of distinct separation between the intra-domain and inter-domain QoS control planes at each AS to realize the standardized and transparent inter-operator-domain QoS interactions while hiding the heterogeneities of the intra-domain QoS control mechanisms. By transparent, we mean that operators do not have to reveal any details about the internal function of their networks, including the used QoS signalling protocols. The analyses of applying the NSIS inter-domain QOSM for the inter-domain QoS control and applying the NSIS intra-domain QOSM for the intra-domain QoS control in the ITU-T RACF functional architecture are discussed in this section, respectively. Finally, the mapping between the ITU-T RACF entities and the NSIS entities is given based on the analyses. 4.2. The Analysis of Applying the NSIS Intra-domain QOSM for Intra-domain QoS Control in the ITU-T RACF Functional Architecture In order to analyse how the NSIS Intra-domain QOSM concept can be applied and used by the ITU-T RACF architecture, a list with the ITU-T RACF functional entities and their features is given in subsections 4.2.1.1 to 4.2.1.6. Section 4.2.1.7 presents the QoS features that can be supported by the CPE. Subsequently, in Section 4.2.1.8, the typical NSIS intra-domain QOSM features will be compared with the features supported by the ITU-T RACF functional entities. 4.2.1 The ITU-T RACF functional entities As mentioned in Section 4.1, the RACF functional entities specified in [Y.RACF] include: Service Control Function (SCF), Network Attachment Control Functions (NACF), Policy Decision Functional Entity (PD-FE), Transport Resource Control Functional Entity (TRC-FE), Policy Enforcement Functional Entity (PE-FE), Transport Resource Enforcement Functional Entity (TRE-FE). The texts given in the subsections 4.2.1.1 to 4.2.1.7 are copied from [Y.RACF]. 4.2.1.1 Service control functions The following texts are copied from [Y.RACF]. "The SCF in different domains can interact with PD-FE via the Rs reference point. The SCF makes requests for transport resources and may receive notifications when resources are reserved and released. * The SCF shall provide information to the PD-FE to identify media flows and their required QoS characteristics (e.g., service class, bandwidth). Zhang, et al. Expires September 2007 [Page 15] Internet-Draft InterDomain-QOSM March 2007 * The SCF may provide service priority information to the PD-FE to facilitate appropriate priority handling (e.g., priority processing of the resource request, resource pre-emption if needed). * The SCF may request resource usage information through the PD-FE for charging or other usage metering. * The SCF may provide service information to the PD-FE to facilitate appropriate dynamic firewall working mode selection. * The SCF shall indicate when the resource is to be committed (i.e. opening gate and allocating bandwidth). A resource may either be committed immediately or just reserved for a later commitment. * When a NAPT function is required, the SCF shall request address binding (mapping) information and perform required modifications in signalling messages. This includes any address information modifications that may be required for binding. * When the pull mode along with a path-coupled resource reservation mechanism is used, the SCF shall indicate to the PD-FE whether it should be notified when resources are reserved, modified and released. * When an authorisation token mechanism is used, the PD-FE may provide the SCF one or multiple authorisation tokens, which shall be included in a signalling message to CPE.", from [Y.RACF] 4.2.1.2 Network Attachment Control Functions (NACF) The following texts are copied from [Y.RACF]. "Network attachment control functions (NACF) provide the following: * Dynamic provision of IP address and other user equipment configuration parameters. * Authentication of user access network, prior or during the IP address allocation procedure. * Authorisation of user access network, based on user profiles (e.g., access transport subscription). * Access network configuration, based on user profiles. * Location management. The PD-FE in the access network interacts with the NACF via the Ru reference point to obtain the transport subscription information and the binding information of the logical/physical port address to an assigned IP address.", from [Y.RACF] 4.2.1.3 Policy decision functional entity (PD-FE) The following text is copied from [Y.RACF]. "The PD-FE handles the QoS resource requests received from the SCF via the Rs reference point or from PE-FE via the Rw reference point. The PD-FE contains the following functions: Zhang, et al. Expires September 2007 [Page 16] Internet-Draft InterDomain-QOSM March 2007 * Final decision point (FDP): This function first checks the QoS resource request based on service information, network policy rules and transport subscription information, and then interacts with the TRC-FE via the Rt reference point to detect and determine the requested QoS resource within the involved access and/or core transport networks. * The FDP makes the final admission decision for media flows of a given service based on network policy rules, service information, transport subscription information, and decision on resource availability. * The FDP indicates the loss of connectivity: It informs the SCF that the transport resource previously granted is lost. The SCF may request PD-FE to relinquish all resources associated with the session. * QoS mapping - Technology independent (QMTI): This function maps the service QoS parameters and priority received from the SCF via the Rs reference point to network QoS parameters (e.g., Y.1541 class) and priority based on the network policy rules. * Gate control (GC): This function controls PE-FE to install and enforce the final admission decisions via the Rw reference point (e.g., opening or closing the gate). The action to pass or drop IP packets is based on a set of IP gates (packet classifiers, e.g., IP 5-tuple) and transport interface identification information (e.g., VLAN/VPN ID) as needed. * IP packet marking control (IPMC): This function takes decisions on packet marking and remarking of flows. The marking may consider the priority of the flow and traffic engineering parameters. * NAPT control and NAT traversal (NAPTC): This function interacts with PE-FE and SCF to provide the address binding information for NAPT control and NAT traversal as needed. * Rate limiting control (RLC): This function makes decisions on the bandwidth limits of flows (e.g., for policing). * Firewall working mode selection (FWMS): This function selects the working mode of the firewall based on the service information. Four packet inspection modes could be identified (static packet filtering, dynamic packet filtering, stateful inspection, deep packet inspection). * Core network path selection (CNPS): This function chooses the core network ingress and/or egress path for a media flow based on the service information and technology independent policy rules at the involved PD-FE. * Network selection (NS): This function locates core networks that are involved to offer the requested QoS resource. It locates the PE-FE instances that are involved to enforce the final admission decisions. The PD-FE shall make the final policy decisions based on the service information (e.g., service type, flow description, bandwidth, priority), transport network information (e.g., resource admission Zhang, et al. Expires September 2007 [Page 17] Internet-Draft InterDomain-QOSM March 2007 result, network policy rules) and transport subscription information (e.g., maximum upstream/downstream capacity). The policy decision shall provide sufficient information to make the PE-FE perform the resource control operation e.g., gate opening/closing, bandwidth allocation/rate limiting, packet marking, traffic policing/shaping, NAPT and address latching. The policy decisions may be composed of flow ID, IP addresses, bandwidth, gate status, time/volume limit, traffic descriptor etc. The PD-FE can be stateful or stateless depending on the complexity of the specific network environment, application characteristics and deployment architecture. * The stateless PD-FE only maintains the transaction state information, e.g., state held for the duration of a request-response operation. In order to be stateless, the PD-FE shall generate the resource control session information for each resource control request from the SCF, which can be stored in the SCF, TRC-FE or PE-FE and used to retrieve the state information together with pertinent information flows. * The stateful PD-FE may maintain a variety of resource control session information within PD-FE, such as the session duration, the resource control session information (e.g., the association between SCF and PD-FE, PD-FE and TRC-FE, PD-FE and PE-FE), the resource reservation limit (e.g., time limit/volume limit), resource reservation status (i.e. authorized, reserved, or committed) and physical/logical connection ID.", from [Y.RACF] 4.2.1.4 Transport Resource Control Functional Entity (TRC-FE) The following text is copied from [Y.RACF]. "TRC-FE is responsible for transport technology dependent resource control as follows: * Resource status monitoring and network information collection The TRC-FE collects and maintains the network information and resource status information. The resource status information may be specific to the resource based admission control scheme being used by TRC-FE, i.e., whether it is accounting, out-of-band measurements, in-band measurements, or reservation-based. * Resource based admission control On receipt of the resource request from PD-FE, the TRC-FE shall perform resource based admission control based on the QoS and priority requirements received from the PD-FE (e.g., bandwidth and Y.1541 class), in conjunction with the resource utilization information and transport dependent policy rules, and shall update the resource status and return the result to PD-FE. * Transport dependent policy control Zhang, et al. Expires September 2007 [Page 18] Internet-Draft InterDomain-QOSM March 2007 Transport dependent policy rules are a set of rules specific to a transport sub-network and technology. The TRC-FE ensures that a request from the PD-FE matches the transport specific policy rules (e.g., access link policy rules, core transport network policy rules), as multiple PD-FEs can request resources from the same TRC-FE. The TRC-FE shall coordinate the resource requests from PD-FEs and take into account transport dependent policy rules to decide if the resource requests can be supported (e.g., usage/constraints of particular transport QoS class and total capacity). The TRC-FE provides the following basic functions: * QoS mapping - Technology dependent (QMTD): This function maps the network QoS parameters and classes received from the PD-FE via the Rt reference point to transport (technology dependent) QoS parameters and classes based on specific transport policy rules, and accommodating the diversity of transport technologies. * When mapping network QoS parameters to transport (technology dependent) QoS parameters, TRC-FE considers the underlying transport technology. A set of network QoS parameters may be mapped to different sets of transport (technology dependent) QoS parameters based on transport technologies. The TRC-FE has knowledge of the QoS related features of the underlying transport network and map the network QoS parameters to the best matching transport (technology dependent) QoS parameters for given transport technology. The mapping policy rules need to be provided by network operators. * Technology dependent decision point (TDDP): This function receives and responds to the QoS resource request from PD-FE via the Rt reference point. This function detects and determines the availability of requested QoS resource based on the network topology and resource status information, as well the transport subscription information in access networks. It may make path selection between ingress and egress points within its purview of a sub-domain to satisfy the QoS resource requirements. If the requested resource is available, this function updates the resource status to include the new application request and responds PD-FE with a positive answer (e.g., resource available), otherwise, it responds PD-FE with a negative answer (e.g., resource unavailable). * Network topology maintenance (NTM): This function collects and maintains the transport network topology information via the Rc reference point. Note that the Rc reference point can be connected to any transport functions including PE-FE, TRE-FE and other entities defined in [Y.2012] to obtain the relevant resource information. * Network resource maintenance (NRM): This function collects and maintains the transport resource status information via the Rc reference point. * Element resource control (ERC): This function controls the QoS-related resources in the intermediate transport elements at the aggregate level (e.g., VLAN, VPN, LSP). Note that the ERC is for further study. Zhang, et al. Expires September 2007 [Page 19] Internet-Draft InterDomain-QOSM March 2007 The implementation of the TRC-FE in various access networks may be different according to access transport technologies and corresponding QoS mechanisms in the data plane. The implementation of the TRC-FE may be different in various core networks according to core transport technologies and corresponding QoS mechanisms in the data plane. ", from [Y.RACF]. 4.2.1.5 Policy Enforcement Functional Entity (PE-FE) The following text is copied from [Y.RACF]. "The PE-FE enforces the network policy rules instructed by the PD-FE on a per-subscriber and per-IP flow basis. It should be able to perform the following functions based on flow information such as classifier (e.g., IPv4 5-tuple) and flow direction, as well as transport interface identification information (e.g., VLAN/VPN ID, LSP Label) as needed. The functions of the PE-FE include: * Opening and closing gate: enabling or disabling packet filtering for an IP media flow. A gate is unidirectional, associated with a media flow in either the upstream or downstream direction. When a gate is open, all of the packets associated the flow are allowed to pass through; when a gate is closed, all of the packets associated with the flow are blocked and dropped. * Rate limiting and bandwidth allocation * Traffic classification and marking * Traffic policing and shaping * Mapping of IP-layer QoS information onto link layer QoS information based on pre-defined static policy rules (e.g., setting 802.1p priority values) * Network address and port translation * Media relay (i.e. address latching) for NAT traversal * Collecting and reporting resource usage information (e.g., start-time, end-time, octets of sent data) * Packet-filtering-based firewall: inspecting and dropping packets based on pre-defined static security policy rules and gates installed by PD-FE. There are four packet inspection modes for packet-filtering-based firewall: * Static packet filtering: inspecting packet header information and dropping packets based on static security policy rules. This is the default packet inspection mode applied for all flows. * Dynamic packet filtering: inspecting packet header information and dropping packets based on static security policy rules and dynamic gate status. * Stateful inspection: inspecting packet header information as well as TCP/UDP connection state information and dropping packets based on static security policy rules and dynamic gate status. Zhang, et al. Expires September 2007 [Page 20] Internet-Draft InterDomain-QOSM March 2007 * Deep packet inspection: inspecting packet header information, TCP/UDP connection state information and the content of payload together, and dropping packets based on static security policy rules and dynamic gate status.", from [Y.RACF]. 4.2.1.6 Transport resource enforcement functional entity (TRE-FE) The following text is copied from [Y.RACF]. "The TRE-FE enforces the transport resource policy rules instructed by the TRC-FE at the technology-dependent aggregate level (e.g., VLAN, VPN and MPLS). It should be able to perform the functions based only on transport link information (e.g., VLAN/VPN ID, and LSP Label). For example a TRE-FE may be used to modify the bandwidth associated with an LSP, or to set ATM traffic management parameters such as cell rate or burst size. Note that the scope and functions of the TRE-FE are for further study.", from [Y.RACF]. 4.2.1.7 Customer Premises Equipment (CPE) The following text is copied from [Y.RACF]. "According to the capability of QoS negotiation, the CPE can be categorised as follows: * Type 1-CPE without QoS negotiation capability (e.g., vanilla soft phone, gaming consoles) The CPE does not have any QoS negotiation capability at either the transport or the service stratum. It can communicate with the SCF for service initiation and negotiation, but cannot request QoS resources directly. * Type 2-CPE with QoS negotiation capability at the service stratum (e.g., SIP phone with SDP/SIP QoS extensions). The CPE can perform service QoS negotiation (such as bandwidth through service signalling but is unaware of attributes specific to the transport. The service QoS concerns characteristics pertinent to the application. * Type 3-CPE with QoS negotiation capability at the transport stratum (e.g., UMTS UE). The CPE support RSVP-like or other transport signalling (e.g., GPRS session management signalling, ATM PNNI/Q.931). it is able to directly perform transport QoS negotiation throughout the transport facilities (e.g., DSLAM, CMTS, SGSN/GGSN). Note that the SCF shall be able to invoke the resource control process for all types of CPE.", from [Y.RACF]. 4.2.1.8 Comparison between NSIS intra-domain QOSM features and features supported by the ITU-T RACF functional entities Zhang, et al. Expires September 2007 [Page 21] Internet-Draft InterDomain-QOSM March 2007 This draft consideres an Intra-domain QOSM as a QOSM that can be used within one administrative domain and that supports either a centralised or distributed QoS management approach. The centralised approach mainly uses one Intra-domain QoS controller that is usually located off-path. However, more than one Inter-domain QoS controllers can be used within one administrative domain. In this situation the centralised Intra-domain QoS controller(s) is (are) considered to be the entitie(s) that provide the Policy Decision Point (PDP). In addition to these entitie(s), the centralised Intra-domain QOSM consists of entities that can be managed by the centralised Intra-domain QOS controllers. These entities are located on path and can be considered as Policy Enforcement Points (PEP). The distrbuted approach uses more than one Intra-domain QoS controllers that are usually located on path and can be either located on the boundary of the administrative domain or on each on path node within the administrative domain. However, it is possible that the distributed Intra-domain QoS controllers located at the boundaries of the administrative domain can provide more features than the ones located within the domian and are not boundary nodes. In the distributed QoS management approach it is considered that the distributed Intra-domain QoS controllers are PDP and PEP. By analysing Sections 4.2.1.1 to 4.2.1.6 it can be observed that the PD-FE, TRC-FC and SCF and NACF are mainly used by the control plane, while the functional entities PE-FE and TRE-FE are mainly used by the data plane. However, the latter two functional entities could also perform a limited number of control functions, such as bandwidth availability control and bandwidth modification. The PD-FE and TRC-FC are considered to be PDPs while the PE-FE and TE-FE are considered to be PEPs. All these functional entities can be used for both the push and pull modes of QoS resource control scenarios. This means that the PD-FE, TRC-FE, PE-FE, TRE-FE can be considered as NSIS PDP and/or PEP Intra-domain QOS controllers. The Type 1-CPE and Type 2-CPE cannot perform on-path QoS negotiations and therefore, it is considered that the CPE is used for the Push mode QoS resource control scenario. In this case it is considered that the CPE is not NSIS aware. The Type 3-CPE can perform on-path QoS negotiations and therefore, it is considered that the CPE is used for the Pull mode QoS resource control scenario. In this case it is considered that the CPE is NSIS aware. 4.3 The Analysis of Applying the NSIS Inter-domain QOSM for Inter-domain QoS control in the ITU-T RACF Functional Architecture Zhang, et al. Expires September 2007 [Page 22] Internet-Draft InterDomain-QOSM March 2007 The inter-operator-domain communications for e2e QoS control in the ITU-T functional architecture are discussed in section 10 of [Y.RACF], where two ways of passing the QoS requirements for a given service over e2e paths. For the RACF Push resource control mode, the QoS requirements for a given service are proposed to be passed over the e2e path through the application layer signaling or through the Ri reference point; whereas, for the RACF Pull resource control mode, the QoS requirements for a given service are proposed to be passed over the e2e path through path-coupled QoS signaling (e.g., NSIS). However, due to the fact that the current NSIS intra-domain QOSMs (e.g., RMD-QOSM [RMD-QOSM] and Y.1541-QOSM [Y.1541-QOSM]) are all dedicated to a specific QoS control mechanism but the RACF PD-FE entity is located at the technology-independent control layer, we argue that the QoS-NSLP messages carrying those intra-domain QOSM QSPECs will not be understood by the RACF PD-FE when the on-path NSIS entities trigger the QoS request to the PD-FE and a NSIS inter-domain QOSM, which should also be independent from the underlying intra-domain QoS mechanisms, is needed to fulfill the e2e QoS control in the ITU-T RACF architecture. Moreover, in the RACF model the procedures for QoS control are focused on how the service control function requests QoS (authorization and reservation) to the PD-FE, and how the later pushs the admission control decisions into the network nodes. So, all described procedures in [Y.RACF] are local to one operator network. The InterDomain-QoSM, provides the RACF model with the PD-FE/PD-FE communication needed for transparent end-to-end QoS control. By transparent, we mean that operators do not have to reveal any details about the internal function of their networks, including the used QoS signalling protocols. Below we provide an analysis how the major issues that need to be consider to apply the InterDomain-QoSM to the ITU-T RACF model for inter-domain QoS control. Starting from the CPE, the InterDomain-QoSM follows the same RACF assumptions about the QoS capabilities of the CPE. According to the capability of QoS negotiation, the CPEs can be categorized as follows (see further in Section 4.2.1.7): * Type 1: CPE without QoS negotiation capability. The CPE does not have any QoS negotiation capability at either transport or service stratum. It can communicate with Service Control Functions for service initiation and negotiation, but cannot request QoS resources directly. So, in this case it is up the the access network to set the most usefull SLSs based on the type of previous CPE service negotiations and by using the capability provided by the InterDomain-QoSM. * Type 2: CPE with QoS negotiation capability at the service stratum (e.g. SIP CPE). The CPE can perform service QoS negotiation (such as bandwidth) through service layer signalling, but is unaware of QoS attributes specific to the transport. When the CPE is initiating communication sessions that span beyond its access network, this CPE QoS requests are passed to the InterDomain-QoSM. Zhang, et al. Expires September 2007 [Page 23] Internet-Draft InterDomain-QOSM March 2007 * Type 3: CPE with QoS negotiation capability at the transport stratum (e.g. UMTS CPE). The CPE supports RSVP-like or other transport layer signalling. It is able to directly perform transport QoS negotiation throughout the transport facilities. In this case the RSVP-like signalling is used to configure network devices in the access network, being control passed to the InterDomain-QoSM to pass network border. In each network the control can be passed from the InterDomain-QoSM back to the RSVP-like protocol. In order to support the end-to-end communication of different type of CPEs, the InterDomain-QoSM support the two QoS resource control modes described in the RACF: * Push Mode: In this case the CPE (of type 2) communicates with the RACF Service Control Function (SCF), and the later issue a request to the RACF for QoS resource authorization and reservation. The RACF pushes the decisions to transport functions for policy and resource enforcement. This mode can be also used for CPE of type 1, in which case, the SCFs determine the QoS requirements of the requested service on behalf of CPEs, and based on inter-domain information that may be provided by the InterDomain-QoSM. * Pull Mode: The SCFs issue a request to RACF for QoS resource authorization, and QoS resource reservation and the decisions are requested by Transport Functions upon receiving transport-layer QoS signalling messages. In mode is suitable for CPEs of type three, which can explicitly request the QoS resource reservation through transport-layer QoS signalling. In what concerns the three resource control state described by RACF (Authentication, Reservation and Commitment), the InterDomain-QoSM does not cover the committed state. That is to say, the InterDomain-QoSM describes a mechanism to reserve resources (SLSs) for different types of traffic, but does not say anything about how/when the SLSs are committed. The commitment state can be included by considering the validity of the SLSs negotiated by the InterDomain-QoSM. From the architecture point of view, an NSIS entity named Inter-domain QNE implements the NSIS Inter-domain QoSM and in charge of the inter-operator-domain interactions at each AS. Moreover, the Inter-domain QNE can be implemented in three possible ways: i) Fully centralized, which means that the Inter-domain QNE functionality is implemented in an interior network node. ii) Fully distributed, which means that the Inter-domain QNE functionality is implemented in all edge network nodes. Zhang, et al. Expires September 2007 [Page 24] Internet-Draft InterDomain-QOSM March 2007 iii) A hybrid approach of i) and ii), in which the Inter-domain QNE is co-located with interior network nodes close to edge devices. This is while in option ii) we have one inter-domain QNE implemented in each edge router (which does not separate data and control plane), in this option we have one Inter-domain QNE controlling a subset of edge devices and we separated the data from the control plane. Each of these approaches has advantages and disadvantages. For instance: - The centralized option does not need the synchronization between several Inter-domain QNEs in the same network, but has scalability and resilience problems. In terms of signaling, it needs an off-path NSIS QoS signaling to fulfill the ITU-T RACF Ri reference point. - The fully distributed option presents the highest scalability and resilience properties, but it incorporates the constraint that the signaling will be processed on the nodes which also handle the data flows themselves. From the signaling point of view, there is no need for a new off-path QoS signaling and the Ri reference point can be implemented by using the on-path NSIS QoS signaling, since the signaling can be done by using QoS-NSLP in two steps, inter-domain and intra-domain. - The hybrid option seems to provide a good compromise between the de-coupling of signaling and data and the needed scalability and resilience. In terms of signaling, it needs an off-path inter-domain QoS signaling to implement the Ri reference point. In addition, it may also need an off-path NSLP intra-domain signaling to implement the Rd reference point to synchronize the set of Inter-domain QNEs (i.e., the inter-domain PD-FEs). If fact, the most suitable solution (fully centralized, fully distributed or hybrid) will strongly depend on the characteristics of the domain, such size, network technology, and method used to assure QoS. These operation modes of the inter-domain QNE are an add-on to the RACF, since the RACF specificiation does not mention this issue. In what concerns the RACF entities, we propose to slip the PD-FE functions into the inter-domain PD-FE for inter-domain QoS control and the intra-domain PD-FE for intra-domain QoS control and map the Inter-domain QNE to the inter-domain PD-FE. thus, for the case that more than one InterDomain-QNEs exist at an operator AS, they can interact with each other via the RACF Rd reference point. Here we focus our analysis on the inter-domain PD-FE, which interacts with the intra-domain PD-FE and PE-FE. Furthermore, the InterDomain-QoSM will be used to fulfill the Ri reference point between peer inter-domain PD-FE at adjacent operator domains. This Zhang, et al. Expires September 2007 [Page 25] Internet-Draft InterDomain-QOSM March 2007 inter-domain QoS control can be done based on two scenarios: in one scenario (push mode), the CPE requests QoS to the SCF or it is the SCF that handle QoS requests on behalf of the CPEs. In another scenario (pull mode), the CPE requests QoS via a path-coupled QoS signalling in the transport stratum. In any case the inter-domain QoS control is due by the InterDomain-QoSM via the NSIS path-decoupled message association created over the Ri reference point of the PD-FE (see section 5.2.1 - GIST analysis). In other words, the path-coupled signaling is only used between CPEs and the access network and inside each network being the inter-domain signaling done by InterDomain-QoSM via Ri reference point. This usage of the path-coupled signalling, means that each network can use a different path-coupled signaling implementation, since that signalling is never used end-to-end. 4.4 The mapping between ITU-T RACF Entities and NSIS Entities Based on the results of the analysis done in Sections 4.2 and 4.3, it can be observed that the ITU-T RACF PD-FE, TRC-FE functional entities can be considered as NSIS PDP Intra-domain and Inter-domain QOS controllers, while the ITU-T RACF PE-FE and TRC-FE functional entities can be considered as NSIS PDP and/or PEP Intra-domain QoS controllers. In addition to the analysis given in Sections 4.2 and 4.3, it should be observed that all functional entities support, in addition to QoS features, also NAT and network management features. In this draft we will only consider the QoS features without analysing the rest of the features. The NACF function is mainly used for network attachment, e.g., authentication, authorization, dynamic provisioning of IP addresses and mobility support. Therefore, this functional entity and its interactions will not be considered in the mapping process of the RACF entities to NSIS entities. The SCF function can be considered to be a functional entity that can be managed by non NSIS aware signaling. Therefore, also this functional entity is not considered in the mapping process. The ITU-T CPE functional entity can be considered as a NSIS QNI or QNR when used in association with the pulled mode of QOS resource control. Based on the above, we provide the following mapping between the ITU-T RACF functional entities to the NSIS entities. * (Inter-domain) RACF TRC-FE is mapped to TRC-FE (NSIS) Interdomain QoS controller * (Inter-domain) RACF PD-FE is mapped to PD-FE (NSIS) Interdomain QoS controller Zhang, et al. Expires September 2007 [Page 26] Internet-Draft InterDomain-QOSM March 2007 * (Intra-domain) RACF TRC-FE is mapped to TRC-FE (NSIS) Intra-domain QoS controller * (Intra-domain) RACF PD-FE is mapped to PD-FE (NSIS) Intra-domain QoS controller * (Intra-domain) RACF PE-FE is mapped to PE-FE (NSIS) Intra-domain QoS controller * (Intra-domain) RACF TRE-FE is mapped to TRE-FE (NSIS) Intra-domain QoS controller Additional observations that can be made are the following. The TRC-FE and TRE-FE are technology dependent functional entities. This draft will mainly focus on technology independent features and therefore these two functions and their interactions will not be further considered in the mapping process from the RACF entities to NSIS entities. The intercommunication between the NSIS entities is accomplished using the NSIS protocol suites and is specified in the following way: * between NSIS PD-FE Inter-domain QoS controllers is done using a QSPEC that carries the Rd++ information elements. Rd++ is the interface that equals to Rd, but that will have to be extended in the future to fulfil the Ri interface. The Ri interface is a logical interface that will be supported by using the NSIS protocol suite. The Ri informational elements, specified in [Y.RACF], are carried by a NSIS QSPEC, that we denote in this draft as Ri_QSpec. * between the PD-FE (NSIS) inter-domain QoS controller and the PD-FE (NSIS) intra-domain QoS controller is accomplished using a QSPEC, denoted as Rd_QSpec, that carries the Rd informational elements specified in [Y.RACF]. * between the PD-FE (NSIS) intra-domain QoS controller and another PD-FE (NSIS) intra-domain QoS controller is accomplished using the same Rd_QSpec as above. Note that the intercommunication between these entities could also be performed using other types of Intra-domain QOSMs. * between the PD-FE (NSIS) inter-domain QoS controller and the PE-FE (NSIS) intra-domain QoS controller is accomplised using the Rw_QSpec, which carries the Rw informational elements specified in [Y.RACF]. * between the PD-FE (NSIS) intra-domain QoS controller and the PE-FE (NSIS) intra-domain QoS controller is accomplised using the same Rw_QSpec as above. 5. The Basic Features of Interdomain-QOSM Zhang, et al. Expires September 2007 [Page 27] Internet-Draft InterDomain-QOSM March 2007 The rest of this document specifies the NSIS Inter-domain QOSM which can be applied to the ITU-T RACF functional architecture for for e2e QoS control across heterogeneous operator domains. The basic features of the Interdomain-QOSM are described here. 5.1 Overview The NSIS Interdomain-QOSM aims at realizing the inter-operator-domain QoS interactions between adjacent operator ASs in a standarized way while hiding the heterogeneities of the intra-domain QoS control mechanisms in use at each domain. As mentioned above, the Inter-domain QNE that will implement the Interdomain-QOSM should support three possible operation mode: fully centralized, fully distributed and hybrid, and it should also be able to interact with different intra-domain QOSMs deployed at each operator domain. To achieve the above objectives of the Interdomain-QOSM, a set of supports from the underlying NSIS GIST and QoS-NSLP protocols are needed, especially for the Inter-domain QNE discovery and the transport of InterDomain-QOSM messages. Moreover, to successfully apply the Interdomain-QOSM to the e2e QoS control in the ITU-T RACF functional architecture, the impact of the Interdomain-QOSM on the RACF architecture should also be analyzed. Finally, we discuss the e2e QoS control scenarios the Interdomain-QOSM can support for the ITU-T RACF architecture. 5.2 The Assumptions for the Interdomain-QOSM This part provides the first analysis of how to include the InterDomain-QoSM in the NSIS protocol stack, by describing a set of assumptions about NSIS that are central to the development of the proposed QOSM. It introduces section 6.6, which allows us to go back to NSIS with some proposals for adjustments in order to fulfill all the requirements of the described InterDomain-QoSM. This section analysis the potential requirements of the InterDomain-QOSM on the GIST [GIST] and QoS-NSLP [QoS-NSLP]: i) We analyze the possible impact of the InterDomain-QoSM on GIST, namely its support for message association between edge devices and the inter-domain QoS controller, between the inter-domain QoS controller and the edge devices, and between two inter-domain QoS controllers (in the case of a distributed operation mode of the InterDomain-QoSM. ii) We analyze until what extend can QoS-NSLP signaling and the defined QSpec be re-used. Furthermore, regarding to the functional architecture and entities defined in the ITU-T RACF document [Y.RACF], we consider only the technology independent QoS control features and thus, the RACF TRC-FE and TRE-FE entities are not covered by our analysis and mapping in this document. Zhang, et al. Expires September 2007 [Page 28] Internet-Draft InterDomain-QOSM March 2007 5.2.1 GIST Analysis The NSIS working group is currently developing a protocol suite in which the signaling messages will be processed on the nodes which also handle the data flows themselves ("path-coupled signaling"). Complementary to this method, a complementary routing method partially decoupled from the data path is being analyzed. This new off-path Message Routing Method (MRM) allows the signaling and data paths to be partially decoupled, without sacrificing the integration with routing. The major assumption that the InterDomain-QoSM makes of NSIS is the support of an off-path MRM. The current proposal for an off-path MRM [draft-hancock-nsis-pds-problem-03] defines two discovery mechanisms, one starting in one off-path node and finishing in one on-path node, and another starting in one on-path node and finishing in one off-path node. Figure 3 illustrates these two methods. +----------+ | NSLP | Messaging association +----------+ ##########################>>| GIST | # ....................| C/D-mode | # . GIST-Response +----------+ +----------+ # . ^ * | NSLP | # . . * +----------+ # . . * | |<<########## . . V | GIST | . +-.--------+ | C/D-mode |<................... GIST-Query | . GIST | | |.......................................... D-mode| +----------+ +----------+ +----------+ +----------+ | | |RAO bypass| |RAO bypass| | | | IP | | IP | | IP | | IP | |Forwarding| |Forwarding| |Forwarding| |Forwarding| --------------------------------------------------------------------> +----------+ +----------+ +----------+ +----------+ Zhang, et al. Expires September 2007 [Page 29] Internet-Draft InterDomain-QOSM March 2007 +----------+ | NSLP | +----------+ Messaging Association | GIST |<<########################## | C/D-mode | # +----------+ # * . ^ # * . . # +----------+ * . . # |Signalling| V . . # | Appl. | +-------.-.+ # +----------+ | . .| GIST-Response ##########>>| | | GIST . .........................................| GIST | |D-mode . | GIST-Query | C/D-mode | | ...|......................................>| | +----------+ +----------+ +----------+ +----------+ | | |RAO bypass| |RAO bypass| | | | IP | | IP | | IP | | IP | |Forwarding| |Forwarding| |Forwarding| |Forwarding| --------------------------------------------------------------------> +----------+ +----------+ +----------+ +----------+ ---------> = Data flow (and direction) .........> = GIST D-mode messages (and direction) <<######>> = GIST C-mode messages (bidirectional) *********> = Control (off-path node to router) Figure 3: discovering a downstream off-path node from a on-path node (top figure) and discovering a downstream on-path node from an off-path node (bottom figure). These two methods are of use to discover a inter-domain QNE from an edge device by which flows enter a domain (ingress device), and for an inter-domain QNE to discover an edge device by which flows exit a domain (egress device). However, these two discovery mechanism do not support the discovery of one QoS controller by its peers. This is a kind of off-path to off-path discovery mechanism. The off-path MRM proposal mention "Off-path 'server' discovery from another off-path node" in section 3.1, but does not describe that mechanism. Nevertheless, this off-path to off-path discovery mechanism may be build by using the two methods (on-path to off-path discovery and vice-versa) described in the off-path MRM proposal by allowing the configuration of an on-path node for selecting a specific off-path device. This is one downstream on-path node (i.e., the edge routers in the case of the InterDomain-QoSM) should be configured to select an off-path QoS controller to which its received GIST-QUERY message should be forwarded. Zhang, et al. Expires September 2007 [Page 30] Internet-Draft InterDomain-QOSM March 2007 Figure 4 illustrates the setup of an association between two off-path inter-domain QNEs located in two different domains. After the edge QNE1 at Domain A processes the QoS-NSLP message from its upstream interior QNE, it will connect to the inter-domain QNE1 in its domain which is configured to serve it (via GIST D-mode or C-mode depending on the configuration or requirement). Next, the inter-domain QNE1 sends a GIST-Query message, which is forwarded by the Edge QNE1 in its domain and intercepted by the Edge QNE3 in Domain B. Then, this intercepted Query message is forwarded to the inter-domain QNE2 in Domain B, which is configured to serve Edge QNE3. To this end, the inter-domain QNE2 at Domain B knows the necessary info of its peer at Domain A and can send the GIST-Response message directly to its peer (here, i.e., inter-domain QNE1 at Domain A). Finally, a message association is set up between them. Domain A Domain B Inter-domain QNE1 Inter-domain QNE2 +----------+ +----------+ |Inter-QOSM| Message Association |Inter-QOSM| +----------+<<############################>>+----------+ | GIST |<...............................| GIST | | C/D-mode |<.-. GIST-Response | C/D-mode | +----------+ | +----------+ . . ^ . | . +-----.----+ . +-----.----+ |Intra.QOSM| | |Intra.QOSM| +-----.----+ . +-----.----+ | . | | |GIST . | |GIST . |-.-. |C/D- . | |C/D- . | |mode . | |mode .....|....................................... | +----------+ GIST-Query +----------+ | IP | | IP | |Forwarding| Data path |Forwarding| --------------------------------------------------------------> +----------+ +----------+ Edge QNE1 Edge QNE3 ---------> = Data flow (and direction) .........> = GIST D-mode messages (and direction) <<######>> = GIST C-mode messages (bidirectional) Zhang, et al. Expires September 2007 [Page 31] Internet-Draft InterDomain-QOSM March 2007 Figure 4: discovering a downstream off-path node from an upstream off-path node. This off-path discovery mechanism can be applied to discover peer off-path devices in different networks, as illustrated in Figure 4, and to discover peer off-path devices inside the same network. The later may be used in a scenario in which a domain uses distributed inter-domain QNEs -- a set of inter-domain QNEs each controlling a subset of edge nodes. 5.2.2 QoS-NSLP Analysis In the example illustrated in Section 5.2.1, the inter-domain QNEs implement the InterDomain-QoSM by signaling QoS between domains, while QoS-NSLP [QoS-NSLP] is used to support an IntraDomain-QoSM. This is, the inter-domain QNE may trigger a specific ingress device, which may use QoS-NSLP to signal the needed QoS among all QoS-NSLP aware routers inside the domain from the triggered ingress device until the indicated egress device. However, the use of QoS-NSLP to signal between ingress and egress devices is not mandatory for the InterDomain-QoSM. Actually, the InterDomain-QOSM makes no assumptions about the implementation mechanisms of the IntraDomain-QoSM. That is to say intra-domain resources may be controlled in a centralized or distributed way, based on NSIS protocols or not. Nevertheless, a distributed implementation of the IntraDomain-QoSM based on QoS-NSLP signalling over several intra-domain QNEs is more close to the work being done in NSIS (independent from if the intra-domain signalling is done on-path or off-path based on the use of a new off-path MRM also inside a domain). In any case, the InterDomain-QoSM makes use of the messages, objects and procedures defined by QoS-NSLP for signaling exchanges between inter-domain QNEs. However, the InterDomain-QoSM depends on the GIST to discover the peer inter-domain QNEs in adjacent domains. This means that QoS-NSLP is used to signal between inter-domain QNEs, over a set of NSIS message associations, as described in section 5.1. Moreover, 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]. 5.3 The support of ITU-T RACF end-to-end QoS control via the InterDomain-QOSM The inter-operator-domain communications for e2e QoS control in the ITU-T functional architecture are discussed in section 10 of [Y.RACF], where two ways of passing the QoS requirements for a given Zhang, et al. Expires September 2007 [Page 32] Internet-Draft InterDomain-QOSM March 2007 service over e2e paths. For the RACF Push resource control mode, the QoS requirements for a given service are proposed to be passed over the e2e path through the application layer signaling or through the Ri reference point; whereas, for the RACF Pull resource control mode, the QoS requirements for a given service are proposed to be passed over the e2e path through path-coupled QoS signaling (e.g., NSIS). The InterDomain-QoSM will be used to fulfill the Ri reference point between peer inter-domain PD-FE at adjacent operator domains. This inter-domain QoS control can be done based on two scenarios: for the RACF Push mode, when the application layer signaling is not available or incapable to carry the e2e QoS requirements, the CPE requests QoS to the SCF or it is the SCF that handle QoS requests on behalf of the CPEs and, then the e2e QoS requirements are forwarded to the inter-domain PD-FE. In another scenario (the RACF Pull mode), the CPE requests QoS via a path-coupled QoS signalling in the transport stratum. In any case the inter-domain QoS control is due by the InterDomain-QoSM via the NSIS path-decoupled message association created over the Ri reference point of the PD-FE (see section 5.2.1 - GIST analysis). That is to say, the path-coupled signaling is only used between CPEs and the access network and inside each network being the inter-domain signaling done by InterDomain-QoSM via Ri reference point. This usage of the path-coupled signalling, means that each network can use a different path-coupled signaling implementation and different NSIS intra-domain QOSM(s), since that signalling is never used end-to-end. 6. InterDomain-QOSM, Detailed Description 6.1 Additional QSPEC Parameters for End-to-End QoS Control By the InterDomain-QOSM TBD 6.2 The Operation Modes of the InterDomain-QOSM To address the scalability issue for deploying the InterDomain-QOSM in real IP network domains, three possible ways to implement the Inter-domain QNE (see Section 4.3) are provided: fully centralized, fully distributed and hybrid. Moreover, there are two resource control scenarios in the ITU-T RACF functional architecure: RACF Push and Pull resource control modes in [Y.RACF]. Thus, to apply the Interdomain-QOSM to fully fulfill the e2e QoS control in the ITU-T RACF architecture, the Interdomain-QOSM will have to support 6 possible operation combinations: fully centralized, fully distributed and hybrid under the RACF Push and Pull modes, respectively. 6.2.1 Operation mode 1: fully centralized Zhang, et al. Expires September 2007 [Page 33] Internet-Draft InterDomain-QOSM March 2007 In this operation mode, a single off-path NSIS inter-domain PD-FE will exist at an AS that deploys the InterDomain-QOSM to take care of all the inter-domain QoS interaction requests from/to the domain (see Figures 1 and 4 at http://www.dcs.qmul.ac.uk/~jianzhang/Interdomain-QOSM%20Mapping.pdf). Moreover, a centralized or distributed intra-domain PD-FE will also exist at each AS and be responsible for the intra-domain QoS control at the AS. The intra-domain PD-FE can be implemented by a NSIS intra-domain QOSM (for RACF Pull mode) or any intra-domain QoS control mechanisms (for RACF Push mode) and it will interact with the inter-domain PD-FE via the ITU-T RACF Rd reference point. The off-path NSIS inter-domain PD-FE has to support the NSIS protocol suites and implement the Interdomain-QOSM and the PE-FE at the boundary of each AS must also support the GIST off-path Message Routing Method (MRM) to help the discovery of the peer NSIS inter-domain PD-FE at adjacent operator domains and transport the Interdomain-QOSM messages (i.e, implementing the ITU-T RACF Ri reference point). Under the RACF Push mode, the CPE is non-NSIS aware and the QoS requests will be triggered by the SCF to the PD-FE(s) at the source domain; at the subsequent operator domains, the QoS requests will be triggered by the inter-domain QoS interactions. Whereas, under the RACF Pull mode, the CPE is NSIS aware and acts as the QNI to trigger the QoS request at the source domain; at the subsequent operator domains, the QoS requests will first be triggered by the inter-domain QoS interactions and then the on-path NSIS aware nodes will send their requests to the intra-domain QOSM(s) for the intra-domain QoS control. 6.2.2 Operation mode 2: fully distributed In this operation mode, the NSIS inter-domain PD-FE will exist at each edge node of an AS that deploys the InterDomain-QOSM to take care of the inter-domain QoS interaction requests from/to the domain via the edge node (see Figures 2 and 5 at http://www.dcs.qmul.ac.uk/~jianzhang/Interdomain-QOSM%20Mapping.pdf). Moreover, a centralized or distributed intra-domain PD-FE will also exist at each AS and be responsible for the intra-domain QoS control at the AS. The intra-domain PD-FE can be implemented by a NSIS intra-domain QOSM (for RACF Pull mode) or any intra-domain QoS control mechanisms (for RACF Push mode). For the case that the intra-domain PD-FE is also distributed at each edge node of the AS, the inter-domain and intra-domain PD-FEs will interact via the RACF Rd interface implemented internally, otherwise, it will interact with the inter-domain PD-FE via the external RACF Rd interface. Each edge node at the AS will have to implement the Interdomain-QOSM to take care of the inter-domain QoS interactions at its edge node. Under the RACF Push mode, the CPE is non-NSIS aware and the QoS requests will be triggered by the SCF to the PD-FE(s) at the source domain; at the subsequent operator domains, the QoS requests will be triggered by the inter-domain QoS interactions. Whereas, under the Zhang, et al. Expires September 2007 [Page 34] Internet-Draft InterDomain-QOSM March 2007 RACF Pull mode, the CPE is NSIS aware and acts as the QNI to trigger the QoS request at the source domain; at the subsequent operator domains, the QoS requests will first be triggered by the inter-domain QoS interactions and then the on-path NSIS aware nodes will send their requests to the intra-domain QOSM(s) for the intra-domain QoS control. 6.2.3 Operation mode 3: hybrid In this operation mode, a number of off-path NSIS inter-domain PD-FEs will exist at an AS, and each of them will deploy the InterDomain-QOSM and be responsible for handling the inter-domain QoS interaction requests from/to a set of edge QNEs (see Figs 3 and 6 at http://www.dcs.qmul.ac.uk/~jianzhang/Interdomain-QOSM%20Mapping.pdf). Normally the set of edge QNEs assigned to different inter-domain PD-FEs should be disjoint to reduce the synchronization requirement between different NSIS inter-domain PD-FEs. Moreover, a centralized or distributed intra-domain PD-FE will also exist at each AS and be responsible for the intra-domain QoS control at the AS. The intra-domain PD-FE can be implemented by a NSIS intra-domain QOSM (for RACF Pull mode) or any intra-domain QoS control mechanisms (for RACF Push mode). For the case that the intra-domain and inter-domain PD-FEs are located at the same node of the AS, they will interact via the RACF Rd interface implemented internally, otherwise, they will interact with the external RACF Rd interface. Every off-path NSIS inter-domain PD-FE should support the NSIS protocol suites and implement the Interdomain-QOSM and the edge PE-FE at the AS must also support the GIST off-path Message Routing Method (MRM) to help the discovery of the peer NSIS inter-domain PD-FE at adjacent operator domains and transport the Interdomain-QOSM messages (i.e, implementing the ITU-T RACF Ri reference point). Furthermore, the off-path NSIS inter-domain PD-FEs within the AS can interact with each other via the RACF Rd reference point. Under the RACF Push mode, the CPE is non-NSIS aware and the QoS requests will be triggered by the SCF to the PD-FE(s) at the source domain; at the subsequent operator domains, the QoS requests will be triggered by the inter-domain QoS interactions. Whereas, under the RACF Pull mode, the CPE is NSIS aware and acts as the QNI to trigger the QoS request at the source domain; at the subsequent operator domains, the QoS requests will first be triggered by the inter-domain QoS interactions and then the on-path NSIS aware nodes will send their requests to the intra-domain QOSM(s) for the intra-domain QoS control. 6.3 Message Format TBD Zhang, et al. Expires September 2007 [Page 35] Internet-Draft InterDomain-QOSM March 2007 6.4 InterDomain-QOSM Node State Management TBD 6.5 InterDomain-QOSM Operations and Sequences of Events TBD 6.5.1 Basic unidirectional operation TBD 6.5.1.1 Successful reservation TBD 6.5.1.2 Unsuccessful reservation TBD 6.5.1.3 Refresh reservation TBD 6.5.1.4 Modification of reservation TBD 6.5.1.5 InterDomain release procedure TBD 6.6 Inter-domain QNE Discovery and Transport of InterDomain-QOSM Messages TBD 6.6.1 Requirements of InterDomain-QOSM to the Underlying Path-coupled NTLP TBD 6.6.2 Requirements of InterDomain-QOSM to the Underlying path-decoupled NTLP TBD 6.7 Handling of Additional Errors TBD Zhang, et al. Expires September 2007 [Page 36] Internet-Draft InterDomain-QOSM March 2007 7. Security Consideration The operation mode of the InterDomain-QOSM might produce some security concerns and this will be discussed and clarified later. 8. IANA Considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the QSPEC template, in accordance with BCP 26 RFC 2434 [RFC2434]. The InterDomain-QOSM requires a new IANA registry. In addition, the new QSPEC parameters which will be defined in the next version of this document, need to be assigned the QSPEC Parameter ID for them. 9. Open Issues This section includes the issues that we will do or we think should be analysed in the next version of the draft. Currently, the open issues include: o All the missing subsections in Section 6 will be done in the next version of the draft. o The detailed analyses of implementing the relevant ITU-T RACF reference points to support e2e QoS control by using NSIS will be given in the next version of the draft. The QSPEC parameters necessary for the implementation will also be given in the next version. o The analyses for how to adapt the NSIS QOSMs to apply to the ITU-T RACF functional architecture in this document could be moved to a new draft for further comprehensive studies so that the current NSIS QOSM drafts, such as [RMD-QOSM] and [Y.1541-QOSM], need not do the same analysis again. o The mapping between the ITU-T RACF entities and the NSIS entities for e2e QoS control need more stuides and discussion with the ITU-T and NSIS people and could be refined in the next version. o The application of the Interdomain-QOSM to the e2e QoS control in the ITU-T RACF functional architecture also needs more studies and discussions. o The support of the automatic inter-domain adjustment in the scenario of mobile end customers. Zhang, et al. Expires September 2007 [Page 37] Internet-Draft InterDomain-QOSM March 2007 10. Acknowledgments The authors would like to thank John Loughney and Robert Hancock for the helpful suggestions on this InterDomain-QOSM work. 11. References 11.1 Normative References [GIST] Schulzrinne, H., and Hancock, R., "GIST: General Internet Signaling Transport", work in progress. [QoS-NSLP] Manner, J., Karagiannis, G., McDonald, A. and Bosch, S., "NSLP for Quality-of-Service signaling", work in progress. [RMD-QOSM] Bader, A., et. al., "RMD-QOSM - The Resource Management in Diffserv QOS Model," work in progress. [NSIS-QSPEC] Ash, J., et. al., "QoS-NSLP QSPEC Template," work in progress. 11.2 Informative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services," RFC 2210, September 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC2638] Nichols K., Jacobson V., Zhang L. "A Two-bit Differentiated Services Architecture for the Internet", RFC 2638, July 1999. [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005. [DCPEL-requirements] Mendes, P., and Nichols, K., "Requirements for DiffServ Control Plane Elements", draft-mendes-dcpel-requirements-00 (work in progress), January 2006. Zhang, et al. Expires September 2007 [Page 38] Internet-Draft InterDomain-QOSM March 2007 [draft-hancock-nsis-pds-problem-03] Hancok, R., Kappler, C., Quittek, J., Stiemerling, M., "A Problem Statement for Partly-Decoupled Signalling in NSIS", draft-hancock-nsis-pds-problem-03, (work in progress), February 2006. [Y.RACF] ITU-T Recommendation Y.2111, "Resource and admission control functions in Next Generation Networks", 2006. [Y.2012] ITU-T Recommendation Y.2012, "Functional requirements and architecture of the NGN". [Y.1541-QOSM] Ash, J., et. al., "Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes," work in progress. 12. Authors' Addresses Jian Zhang Dept. of Computer Science Queen Mary, Univ. of London Mile End, London E1 4NS UK Email: jian.zhang@dcs.qmul.ac.uk Edmundo Monteiro Dept. of Informatics Engineering Univ. of Coimbra Polo II - Pinhal de Marrocos 3030-290 Coimbra, Portugal Email: edmundo@dei.uc.pt Paulo Mendes Future Networking Laboratory NTT DoCoMo Euro-Labs Landsbergerstr 312 80687 Munich Germany Phone: +49 89 56824 226 Email: mendes@docomolab-euro.com URI: http://www.docomolab-euro.com/ Georgios Karagiannis University of Twente P.O. Box 217 7500 AE Enschede, The Netherlands Email: g.karagiannis@ewi.utwente.nl Jorge Andres-Colas Advanced Networks Planning Telefonica I+D Emilio Vargas, 6 28043 Madrid, Spain Email: jorgeac@tid.es Zhang, et al. Expires September 2007 [Page 39] Internet-Draft InterDomain-QOSM March 2007 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. Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Zhang, et al. Expires September 2007 [Page 40]