idnits 2.17.1 draft-zhang-nsis-interdomain-qosm-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1977. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1948. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1955. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1961. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 356 has weird spacing: '...ributed dist...' == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'GIST' -- Possible downref: Non-RFC (?) normative reference: ref. 'QoS-NSLP' -- Possible downref: Non-RFC (?) normative reference: ref. 'RMD-QOSM' -- Possible downref: Non-RFC (?) normative reference: ref. 'NSIS-QSPEC' -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NSIS Working Group J. Zhang 2 Internet-Draft Queen Mary, Univ. of London 3 Expires: September 2007 E. Monteiro 4 University of Coimbra 5 P. Mendes 6 DoCoMo Euro-Labs 7 G. Karagiannis 8 University of Twente 9 J. Andres-Colas 10 Telefonica I+D 12 InterDomain-QOSM: The NSIS QOS Model to Fulfill the E2E QoS Control 13 in the ITU-T RACF Functional Architecture 14 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on September 2007. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 This document has three goals. First of all, it presents our analysis 48 of how to use the NSIS signaling (inter-domain QOSM and intra-domain 49 QOSM) to fulfill the QoS control in accord with the ITU-T RACF 50 functional architecture. For this goal, we discuss how the ITU-T RACF 51 entities in the ITU-T RACF functional architecture can be mapped to 52 the NSIS entities and how the RACF reference points can be 53 implemented by using the NSIS protocol suites and QOSMs. Secondly, we 54 aim at specifying an NSIS Inter-domain QOSM for E2E QoS control 55 across heterogeneous IP networks and applying this Inter-domain QOSM 56 to the e2e QoS control in the ITU-T RACF functional architecture 57 based on the above ITU-T RACF analysis. The detailed description of 58 the NSIS Inter-domain QOSM are given and the e2e QoS control 59 scenarios in the ITU-T RACF architecture (including RACF Push and 60 Pull resource control modes), which will be covered by the NSIS 61 Inter-domain QOSM are described and implemented. Thirdly, we specify 62 and implement those QSPECs that will be used by the Inter-domain QOSM 63 for the e2e QoS control in the ITU-T RACF architecture. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Overview and Requirements of Inter-domain Signaling for 70 End-to-End QoS Control . . . . . . . . . . . . . . . . . . . 7 71 3.1 The Requirements of the Inter-domain Control Plane . . . 8 72 3.2 The Aims and Scope of this Draft . . . . . . . . . . . .11 73 4. The Analysis of Applying the NSIS Signaling to QoS Control 74 in the ITU-T RACF Functional Architecture . . . . . . . . 12 75 4.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . 12 76 4.2 The Analysis of Applying the NSIS Intra-domain QOSM 77 for Intra-domain QoS Control in the ITU-T RACF . . . . .15 78 Functional Architecture . . . . . . . . . . . . . . . . 15 79 4.2.1 The ITU-T RACF functional entities . . . . . . . .15 80 4.2.1.1 Service control functions . . . . . . . . 15 81 4.2.1.2 Network Attachment Control Functions 82 (NACF) . . . . . . . . . . . . . . . . . .16 83 4.2.1.3 Policy decision functional entity 84 (PD-FE) . . . . . . . . . . . . . . . . . 16 85 4.2.1.4 Transport Resource Control Functional 86 Entity (TRC-FE) . . . . . . . . . . . . . 18 87 4.2.1.5 Policy Enforcement Functional 88 Entity (PE-FE) . . . . . . . . . . . . . 20 89 4.2.1.6 Transport resource enforcement functional 90 Entity (TRE-FE) . . . . . . . . . . . . . 21 91 4.2.1.7 Customer Premises Equipment (CPE) . . . . 21 92 4.2.1.8 Comparison between NSIS intra-domain QOSM 93 Features and Features supported by the 94 ITU-T RACF functional entities . . . . . .21 96 4.3 The Analysis of Applying the NSIS Inter-domain QOSM 97 for Inter-domain QoS control in the ITU-T RACF 98 Functional Architecture . . . . . . . . . . . . . . . . 22 99 4.4 The mapping between ITU-T RACF Entities and NSIS 100 Entities . . . . . . . . . . . . . . . . . . . . . . . .26 101 5. The Basic Features of InterDomain-QOSM . . . . . . . . . . 27 102 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . 28 103 5.2 The Assumptions for the Interdomain-QOSM. . . . . . . . 28 104 5.2.1 GIST Analysis . . . . . . . . . . . . . . . . . . 29 105 5.2.2 QoS-NSLP Analysis . . . . . . . . . . . . . . . . 32 106 5.3 The support of ITU-T RACF end-to-end QoS control 107 via the InterDomain-QOSM . . . . . . . . . . . . . . . .32 108 6. InterDomain-QOSM, Detailed Description . . . . . . . . . . 33 109 6.1 Additional QSPEC Parameters for End-to-End QoS Control 110 By the InterDomain-QOSM . . . . . . . . . . . . . . . . 33 111 6.2 The Operation Modes of InterDomain-QOSM . . . . . . . . 33 112 6.2.1 Operation mode 1: fully centralized . . . . . . . 33 113 6.2.2 Operation mode 2: fully distributed . . . . . . . 34 114 6.2.3 Operation mode 3: hybrid. . . . . . . . . . . . . 35 115 6.3 Message Format. . . . . . . . . . . . . . . . . . . . . 35 116 6.4 InterDomain-QOSM Node State Management. . . . . . . . . 36 117 6.5 InterDomain-QOSM Operations and Sequences of Events . . 36 118 6.5.1 Basic unidirectional operation. . . . . . . . . . 36 119 6.5.1.1 Successful reservation. . . . . . . . . . 36 120 6.5.1.2 Unsuccessful reservation. . . . . . . . . 36 121 6.5.1.3 Refresh reservation . . . . . . . . . . . 36 122 6.5.1.4 Modification of reservation . . . . . . . 36 123 6.5.1.5 InterDomain release procedure . . . . . . 36 124 6.6 Inter-domain QNE Discovery and Transport of 125 InterDomain-QOSM Messages . . . . . . . . . . . . . . . 36 126 6.6.1 Requirements of InterDomain-QOSM to 127 the Underlying Path-coupled NTLP. . . . . . . . . 36 128 6.6.2 Requirements of InterDomain-QOSM to 129 the Underlying path-decoupled NTLP. . . . . . . . 36 130 6.7 Handling of Additional Errors . . . . . . . . . . . . . 36 131 7. Security Consideration. . . . . . . . . . . . . . . . . . . 37 132 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 37 133 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 37 134 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 38 135 11. References . . . . . . . . . . . . . . . . . . . . . . . . 38 136 11.1 Normative References . . . . . . . . . . . . . . . . 38 137 11.2 Informative References . . . . . . . . . . . . . . . 38 138 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 39 139 Intellectual Property Statement . . . . . . . . . . . . . . . 40 141 1. Introduction 143 Although lots of efforts (e.g., IntServ [RFC2210] and Diffserv 144 [RFC2475], [RFC2638]) had been made by the Internet community to 145 address efficient Quality-of-Service (QoS) support in IP networks, 146 there are still some barriers to overcome before the end-to-end QoS 147 provisioning can be truly enabled over heterogeneous IP networks 148 across different operators' ASs (Autonomous System). Among them, one 149 major barrier to the achievement of end-to-end QoS over heterogeneous 150 environments is the lack of a standardized and automatic approach to 151 perform inter-operator-domain QoS interactions between adjacent ASs 152 while hiding the heterogeneities of the intra-domain QoS control 153 mechanisms in use at each operator domain. To fully address this 154 barrier, we believe that a distinct separation between the 155 intra-domain QoS control plane and the inter-domain QoS control plane 156 within each AS must be made, an interface between the intra-domain 157 and inter-domain QoS control planes at the AS must be clarified and 158 standardized, and an interface between the peer inter-domain QoS 159 control planes at adjacent ASs must be standardized and implemented 160 in a way that the network operator's internal confidentials don't 161 need to be exposed. With the above separation and interfaces, the 162 automatic QoS negotiation and setup of inter-domain traffic streams 163 over a chain of heterogeneous network domains will be enabled in a 164 standardized and dynamic way, fully independent from the intra-domain 165 QoS mechanisms in use at each AS. 167 Recently, the ITU-T has been working on the standardization of the 168 Next Generation Network (NGN) by proposing its definitions of the 169 functional architecture, reference points and procedures of NGN 170 across the service control, resource control and transport stratums. 171 Among them, the ITU-T Y.RACF [Y.RACF] presents the requirements of 172 QoS control over heterogeneous networks and defines the resource and 173 admission control functional architecture and reference points for 174 QoS control across end-to-end path. However, the implementation of 175 the functional architecture and those reference points is untouched 176 in the ITU-T Y.RACF document. 178 Meanwhile, the IETF Next Steps in Signaling (NSIS) Working Group 179 proposed a flexible IP signaling solution [RFC4080] for the Internet, 180 where the NSIS protocol suite is structured in two layers: a generic 181 (lower) layer, termed NSIS Transport Layer Protocol (NTLP), which is 182 responsible for moving upper-layer signaling messages between NSIS 183 entities and is independent of any particular signaling applications 184 on top of it; and an upper layer, termed NSIS Signaling Layer 185 Protocol (NSLP), which contains functionality such as upper-layer 186 message formats and sequences, specific to a particular signaling 187 application. Currently, the General Internet Signaling Transport 188 (GIST) protocol [GIST] provides a concrete solution for the NTLP. 189 Moreover, the QoS NSIS Signaling Layer Protocol (QoS-NSLP) [QoS-NSLP] 190 defines message types and generic QoS control information for 191 supporting the QoS signaling application together with a class of QoS 192 Models (QOSM). A QOSM defines the detailed QoS-related procedures and 193 operations (e.g., negotiation, setup, update and release of network 194 resources) to achieve the requested QoS target in a manner that is 195 consistent with either the QoS control mechanism used at a network 196 domain (intra-domain QOSM) or between adjacent operator domains 197 (inter-domain QOSM). The RMD-QOSM [RMD-QOSM] and Y.1541-QOSM 198 [Y.1541-QOSM] are examples of the NSIS based intra-domain QOSMs. 200 This document has three goals. First of all, it aims at analyzing how 201 to use the NSIS signaling protocol suites to realize the end-to-end 202 QoS control across heterogeneous network domains in accord with the 203 ITU-T RACF functional architecture. For this purpose, we study how 204 the RACF entities in the ITU-T RACF functional architecture can be 205 mapped to the NSIS entities and how the RACF reference points can be 206 implemented by using the NSIS protocols. Furthermore, we propose to 207 seperate the inter-domain QoS control clearly from the intra-domain 208 QoS control and apply different NSIS QOSMs (NSIS inter-domain and 209 intra-domain QOSMs) to them. With this approach, the QoS negotiation 210 and setup of inter-domain traffic streams over a chain of 211 heterogeneous operator domains can be fulfilled in a standardized and 212 transparent way, fully independent from the intra-domain QoS 213 mechanisms at each AS. By transparent, we mean that operators do not 214 have to reveal any details about the internal function of their 215 networks, including the used QoS signalling protocols. 217 Secondly, this document aims at specifying the above NSIS 218 Inter-domain QOSM and applying it to the e2e QoS control in the ITU-T 219 RACF functional architecture. The detailed descriptions of how the 220 NSIS Inter-domain QOSM will support the e2e QoS control under the 221 ITU-T RACF Push and Pull resource control modes are presented along 222 with its interactions with different intra-domain QOSMs. The NSIS 223 QSPEC objects that will be used to carry the necessary information 224 elements between the ITU-T RACF reference points are also defined. 226 The structure of this specification is as follows. Section 2 defines 227 terminology, and Section 3 gives an overview of inter-domain 228 signaling requirements for end-to-end QoS control and then describes 229 the aims and scopes of this draft document. Section 4 presents the 230 analysis of applying the NSIS signaling to QoS control in the ITU-T 231 RACF functional architecture and the basic features of our proposed 232 InterDomain-QOSM are summarized in Section 5. The detailed 233 descriptions of the InterDomain-QOSM, such as the QSPEC [NSIS-QSPEC] 234 parameters, the operation modes and the signaling procedures and 235 operations for fulfilling the e2e QoS control, etc, are presented in 236 Section 6. In addition, Section 7 discusses the security 237 consideration raised by the InterDomain-QOSM and the IANA 238 considerations are given in Section 8. Finally, we discuss some open 239 issues related to the mapping between the ITU-T RACF entities and the 240 NSIS entities and some details of the InterDomain-QOSM in Section 9. 242 2. Terminology 244 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 245 NOT", "SHOULD, "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 246 in this document are to be interpreted as described in RFC 2119 247 [RFC2119]. 249 The terminology defined by GIST [GIST], QoS-NSLP [QoS-NSLP] and ITU-T 250 Y.RACF [Y.RACF] applies to this draft. 252 In addition, the following terms are used: 254 Edge node: Node on the boundary of an administrative domain. 256 Ingress node: Edge node that handles the traffic as it enters the 257 domain. 259 Egress node: Edge node that handles the traffic as it leaves the 260 domain. 262 Inter-domain QoS controller: Abstract entity which is responsible for 263 the inter-domain control mechanisms within its administrative domain, 264 in cooperation with its logically adjacent domains via a common 265 inter-domain interface. Depending on the kind of domain (size, 266 network technology, method used to assure the intra-domain QOS, 267 etc.), the inter-domain QoS controller can be implemented in a 268 fully centralized, fully distributed or hybrid (i.e. an intermediate 269 approach between fully centralized and fully distributed) mode. 270 Please refer to Section 4.1 for the details of the implementation 271 modes. 273 Intra-domain QoS controller: An abstract entity which is responsible 274 for performing all intra-domain control mechanisms in a manner 275 appropriate to the specific network technology in use at an 276 administrative domain. As happens with the inter-domain control 277 agent, it can be implemented in a centralized, decentralized or 278 hybrid mode. 280 Customer: Business entity which has the ability to subscribe to the 281 services offered by providers. 283 Provider: Business entity which owns an administrative domain and is 285 responsible for its operation, especially for the provision of 286 Internet connectivity. 288 Service Level Agreement (SLA): Contract between a customer, which can 289 be an end-user or an administrative domain, and an administrative 290 domain, which acts as a provider, where the provider guarantees that 291 traffic offered by a customer meeting certain stated conditions, will 292 receive one or more particular service levels. The guarantees may be 293 hard or soft, may carry certain tariffs, and may also carry certain 294 monetary or legal consequences if they are not met. 296 Service Level Specification (SLS): Technical details of the agreement 297 specified by a SLA. A SLS has, as its scope, the acceptance and 298 treatment of traffic meeting certain conditions and arriving from a 299 certain customer. 301 3. Overview and Requirements of Inter-domain Signaling for End-to-End 302 QoS Control 304 There are scenarios that can increase their data forwarding 305 performance by separating the control plane heavy processing from the 306 data forwarding processing. Such scenarios are for example, described 307 in [draft-hancock-nsis-pds-problem-03], which achieve this separation 308 by implementing outsourcing. The outsourcing takes place when nodes 309 located on the data forwarding give over either the complete or a 310 part of their control plane responsibilities, such as resource 311 management, to one or more central controlling entities. Such 312 scenarios are able to use signaling that can propagate off path 313 towards the central controlling entities. 315 Several off path signaling scenarios can be distinguished, but in 316 this draft we mainly concentrate on the path decoupled type of 317 signaling, where signaling messages can travel on path but they might 318 also be transferred to nodes off the data path. Off path signaling 319 can be realized by using GIST, which can support path decoupled 320 signaling, see [draft-hancock-nsis-pds-problem-03] and an 321 inter-domain QOSM that in combination with the QoS-NSLP realizes a 322 distinct separation between the intra-domain control plane and the 323 inter-domain control plane at each administrative domain. 324 Furthermore, the inter-domain QOSM can specify, by using a QSPEC, a 325 common inter-domain interface between adjacent domains so that the 326 inter-domain interactions will be fulfilled in a standardized and 327 dynamic way to facilitate the realization of end-to-end QoS 328 provisioning over heterogeneous network domains. 330 Figure 1 shows a high-level view of such distinct separation made at 331 two adjacent domains. More specific, at each administrative domain, 332 the intra-domain QoS controller is responsible for performing all 333 intra-domain control mechanisms in a manner appropriate to the 334 network technology in use at the domain and the inter-domain QoS 335 controller implements a common inter-domain control interface and 336 is responsible for the inter-domain interactions with its peer via 337 the common inter-domain interface. Note that both the intra-domain 338 and inter-domain QoS controllers shown in Figure 1 are the abstract 339 entity, which can be implemented in a centralized or distributed 340 mode (see Section 5.1). Moreover, the interface between the 341 intra-domain and inter-domain QoS controller within a domain is 342 standardized in this document. 344 +----------------------------+ +----------------------------+ 345 |Domain A | |Domain B | 346 | | | | 347 | | | | 348 | +-------+ +-------+ | | +-------+ +-------+ | 349 | |Intra- | |Inter- | | | |Inter- | |Intra- | | 350 | |domain |<<<>>>|domain |<--|---------|-->|domain |<<<>>>|domain | | 351 | |QoS | |QoS | |inter- | |QoS | |QoS | | 352 | |control| |control| |domain | |control| |control| | 353 | +-------+ +-------+ |control | +-------+ +-------+ | 354 | (centralized (centralized)|interface| (centralized) (centralized | 355 | or or | | or or | 356 | distributed) distributed | | distributed distributed)| 357 +----------------------------+ +----------------------------+ 359 <<<>>> = standardized interface between the intra-domain and 360 inter-domain QoS controller within an administrative domain 361 <----> = common inter-domain interface between peer inter-domain QoS 362 controllers at adjacent domains 364 Figure 1: The high-level view of the inter-domain interactions 365 between two adjacent domains where the distinct separation 366 between the intra-domain and inter-domain control planes is 367 made and a common inter-domain control interface exists. 369 3.1 The Requirements of the Inter-domain Control Plane 371 The requirements of the inter-domain control plane (i.e., the 372 functions provided by the inter-domain control agent in Figure 1) 373 which is required to implement a common inter-domain control 374 interface to facilitate the support of end-to-end QoS provisioning 375 over heterogeneous network domains are summarized below. Note that 376 they are derived closely based on the ones outlined by the proposed 377 Diffserv Control Plane Elements (DCPEL) BOF in its document 378 [DCPEL-requirements] and from some of the requirements provided in 379 [Y.RACF]. 381 Before listing the Inter-domain Control Plane requirements we will 382 list a number of high level requirements when the overall 383 NSIS signaling has to be used in supporting the ITU-T Y.RACF [Y.RACF] 384 functional architecture. 386 Some of these requirements are copied/taken from [Y.RACF] and are: 388 * Control the QoS-related transport resources within NSIS 389 aware networks and at the network boundaries in accordance 390 with their capabilities; 392 * Support CPE's differing intelligence and capabilities; 394 * Support resource and admission control within a single 395 administrative domain and between administrative domains; 397 * Support both relative QoS control and absolute QoS-control; 399 * Verify resource availability on an end-to-end basis; 401 * Support QoS differentiation over various categories of 402 packet traffic including packet-type flows and user policies; 404 * Support QoS signaling 406 * Authorize requests for QoS and operate only on the authorised 407 requests for QoS; 409 * Support distributed and centralized transport resource control 410 architectures. 412 The resource and admission control functional architecture should 413 meet the following optional high-level requirements: 415 * Support methods for resource-based admission control 417 * Have access to and make use of information provided by 418 network management on performance monitoring to assist in making 419 resource-based admission decisions; 421 * Have access to and make use of the network status information 422 provided by the underlying network infrastructure in support of 423 end-to-end QoS when transport functions detect and report a 424 failure; 426 * Make use of the service priority information for priority 427 handling (e.g., admission control based on service priority 428 information). This includes passing of service information 429 between entities where applicable; 431 * Support path selection (using NSIS discovery mechanism) between 432 ingress and egress points within a single domain to satisfy QoS 433 resource requirements. 435 The Requirements of the Inter-domain Control Plane are: 437 o A common inter-domain control interface, which allows the QoS 438 negotiation and set-up of inter-domain traffic streams while 439 hiding intra-domain characteristics from inter-domain 440 interactions (i.e., independent from the specifics of the 441 intra-domain control plane), must be implemented by the 442 inter-domain control plane. 444 o Signaling communications over the common inter-domain interface 445 must be made based on a well-understood information model for 446 SLSs. This model should allow the definition of different degrees 447 of SLSs, from per-flow, more suitable for end-hosts or small 448 networks, to per-aggregate, more suitable for large networks. It 449 should also allow the identification of the SLS validity and a set 450 of time periods over each the SLS must be available (activated), 451 besides the information about the QoS characteristics. 453 o The inter-domain control plane at each domain must be able to keep 454 established and/or available/offered SLSs. The SLS is associated 455 with the identity of the network domain offering or requesting the 456 SLS. 458 o The inter-domain control plane must allow network domains 459 negotiate and set up SLSs between adjacent domains. Policy 460 information specific to the requester, or other general policies 461 must be checked to determine if the requested SLS can the 462 accepted. 464 o The inter-domain control plane at each domain must be able to 465 ensure that the traffic streams its domain sends are in conformity 466 with the established agreement. Packets might need to be re-marked 467 from one internal traffic class identifier to the inter-domain SLS 468 identifier, which then might need to be re-marked from the 469 inter-domain SLS identifier to another internal traffic class 470 identifier used at its adjacent domain. 472 o The inter-domain control plane should be able to: 474 * support the QoS query, request, response and monitor operations 475 in a chain of heterogeneous network domains on a per-flow or 476 per-aggregate basis via the common inter-domain control 477 interface; 479 * support the automatic inter-domain adjustment in the scenario 480 of mobile end customers; 482 * support both relative QoS control and absolute QoS control; 484 * verify resource availability within its purview; 486 * support QoS differentiation over various categories of packet 487 traffic including flows and user designations; 489 * operate only on authorized requests for QoS; 491 * make use of the service priority information for priority 492 handling; 494 * have access to make and use of information provided 495 network management and performance management related to 496 resource control; 498 * support path selection (using NSIS discovery mechanism) 499 between ingress and egress points within a single domain. 501 * support distributed and centralised resource control 502 architectures; 504 * support the following QoS resource control modes: 506 a) Push mode: the policy and resource management decisions are 507 pushed towards the intra-domain control plane 509 b) Pull mode: the policy and resource management decisions are 510 requested by the intra-domain control plane upon receiving 511 path coupled signaling. 513 * QoS resource control should meet the following operational 514 requirements: 516 * support methods for resource usage and/or QoS treatments 518 * have access to make and use of information provided 519 network management and performance management related to 520 resource control 522 * support path selection (using NSIS discovery mechanism) 523 between ingress and egress points within a single domain. 525 o The inter-domain QoS resource control process should consists of 526 three logical states: 528 * Authorization: QoS resource is authorized based on operator 529 specific policy rules 531 * Reservation: QoS resource is reserved based on authorized 532 resource and resource availability 534 * Commitment: QoS resource is committed for the requested 535 real time flows 537 3.2 The Aims and Scope of this draft 539 First of all, an analysis will be done on how to use NSIS signaling, 540 in combination with inter-domain QOSMs and intra-domain QOSMs to 541 realise the QOS control in accordance with the ITU-T RACF functional 542 architecture, see [Y.RACF]. This can be accomplished by analysing how 543 the Y.RACF entities in the ITU-T Y.RACF functional architecture can 544 be mapped to NSIS aware entities and how the ITU-T RACF reference 545 points can be implemented by using the NSIS protocol suites. 547 Secondly, it is aimed to specify an NSIS Inter-domain QOSM for 548 end-to-end QOS control across heterogeneous IP networks 549 and apply this Inter-domain QOSM to the end-to-end QoS control in the 550 ITU-T Y.RACF functional architecture according to the above described 551 ITU-T RACF analysis. This can be accomplished by presenting the 552 detailed description of the NSIS Inter-domain QOSM and the end-to-end 553 QoS control scenarios used in the ITU-T RACF functional architecture 554 which are supported by the NSIS Inter-domain QOSM should be specified 555 in detail. 557 Furthermore, this draft aims to specify those QSPEC objects that 558 can be used by the Inter-domain QOSM for the end-to-end QoS control 559 in the ITU-T Y.RACF architecture. This can be accomplished by 560 specifying the QSPEC objects that will be used to carry the 561 informational elements to implement the necessary interfaces 562 of the Inter-domain QOSM. 564 The scope of the draft covers the definition of the interface between 565 the intra-domain and inter-domain QoS control planes within a domain 566 and the definition and implementation of the inter-domain interface 567 between peer inter-domain QoS control planes at adjacent domains by 568 specifying the InterDomain-QOSM. Note that both these interfaces 569 are mapped from the similar interfaces used in the ITU-T RACF 570 architecture. For the case that non-NSIS solutions are used as the 571 intra-domain QoS control mechanism, the implementation of RACF Rd 572 reference point for the interactions between the intra-domain and 573 inter-domain QoS control planes within an AS has to be specified by 574 that non-NSIS solution, which is left to other drafts to address. 576 4. The Analysis of Applying the NSIS Signaling to QoS Control in the 577 ITU-T RACF Functional Architecture 579 4.1 Overview 581 The ITU-T RACF document [Y.RACF] defines the functional architecture 582 and reference points for the resource and admission control functions 583 at each AS (see Figure 2, which is copied from Figure 5 of [Y.RACF]), 584 which includes the SCF (Service Control Functions), PD-FE (Policy 585 Decision Functional Entity), TRC-FE (Transport Resource Control 586 Functional Entity), TRE-FE (Transport Resource Enforcement Functional 587 Entity), PE-FE (Policy Enforcement Functional Entity) and NACF 588 (Network Attachment Control Functions). The CPE/CPN (Customer 589 Premises Equipment/Customer premises Equipment) may be connected to 590 the PE-FE in access network domains and the PE-FE can reside at the 591 +-------------------------+ +--------+ 592 |Service Control Functions| | | 593 | |-----| | 594 Service Stratum +---------------------^---+ | | 595 --------------------------------------------------|---------| | 596 Transport Stratum Rs| | | 597 +-----------------------|----+ | Other | 598 | RACF +-+ | | | NGNs | 599 +------------+ | Rd| | | | | | 600 | Network | | +-+-v-v-+ | | | 601 | Attachment | |Ru | |Ri| | | 602 | Control <-----------------------> PD-FE <-------> | 603 | Functions | | +---------> | | | | 604 | | | |Rt | | | | | 605 +------------+ | +---v--+ +---^---+ | | | 606 | | +---+ | | | | 607 | |TRC-FE| |Rp | | | | 608 | | <---+ | | | | 609 | +-^-^--+ | | | | 610 | Rn| |Rc |Rw | | | 611 +-----|-|-------------|------+ | | 612 | | | | | 613 +---------|-v-------------|------+ | | 614 | | | | | | 615 | +---v--+ +---v---+ | | | 616 | |TRE-FE| | PE-FE |-------| | 617 | | | | | | | | 618 | +------+ +-------+ | | | 619 | Transport Functions | | | 620 +--------------------------------+ +--------+ 622 Figure 2: ITU-T RACF functional architecture 624 network boundary to interconnect with other NGNs. Other NGNs may 625 include access networks only or core networks only or both them. The 626 transport functions could also apply to access networks and core 627 networks. The ITU-T RACF consists of two types of resource and 628 admission control functional entities: the PD-FE and the TRC-FE. The 629 PD-FE provides a single contact point to the SCF and hides the 630 details of transport network to the SCF. The PD-FE makes the final 631 decision regarding network resource and admission control based on 632 network policy rules, SLAs, service information provided by the SCF, 633 transport subscription information provided by the NACF in access 634 networks, and resource-based admission decision results provided by 635 TRC-FE. The PD-FE controls the gates in the PE-FEs at per flow level. 636 Note that the PD-FE consists of transport technology-independent 637 resource control functions and is independent of the SCF as well. The 638 policy rules used by PD-FE are service-based and are assumed to be 639 provided by the network operators. 641 The TRC-FE deals with the diversity of underlying transport 642 technologies and provide the resource-based admission control 643 decision results to PD-FE. The TRC-FE is service-independent and 644 consists of transport technology-dependent resource control 645 functions. The PD-FE requests the TRC-FE instances in the involved 646 transport networks through the Rt reference point to detect and 647 determine the requested QoS resource along the media flow path. The 648 TRC-FE may collect and maintain the transport network topology and 649 the transport resource status information and authorize resource 650 admission control of a transport network based on network information 651 such as topology and/or connectivity, network and element resource 652 availability, as well as the transport subscription information in 653 access networks. Moreover, in the ITU-T RACF functional architecture, 654 the implementation and physical configuration of the PD-FE and TRC-FE 655 are flexible: they can be distributed or centralized, and may be a 656 stand-alone device or part of an integrated device; the PD-FE may 657 contact only one designated TRC-FE instance, and then TRC-FE 658 instances communicate with each other through the Rp reference point 659 to detect and determine the requested QoS resource from edge to dege 660 in the involved network, or the PD-FE may contact multiple TRC-FE 661 instances and determine the requested QoS resource from edge to edge. 663 In addition, in the ITU-T RACF functional architecture, the SCF 664 represents an abstract notion of the functional entities in the 665 service stratum of NGN that request the QoS resource and admission 666 control for media flows of a given service via the Rs reference 667 point; the NACF includes a collection of functional entities that 668 provide a variety of functions for user access network management 669 and configuration based on the user profiles; the PE-FE in the 670 transport stratum is a packet-to-packet gateway at the boundary of 671 different packet networks and/or between the CPE and access network; 672 the TRE-FE in the transport stratum enforces the transport resource 673 policy rules instructed by the TRC-FE at the technology-depedent 674 aggregate level. Currently, the scope and functions of the TRE-FE 675 and the Rn reference point in [Y.RACF] are for further study. 676 Furthermore, an inter-domain reference point Ri is designated to 677 support inter-operator domain PD-FE communication for e2e QoS control 678 when the QoS requirements for a given service can not be passed over 679 the end-to-end path through application layer signaling. However, 680 there are no any details of Ri in [Y.RACF], which are still for 681 further studies. 683 As we can see from the ITU-T RACF document, it defines only the RACF 684 functional architecture and reference points to ensure the 685 inter-operability of the QoS and resource control within 686 heterogeneous network environments but leaves the implementations of 687 them untouched deliberately. Meanwhile, the IETF NSIS Working Group 688 proposed a flexible IP signaling architecture [RFC4080] for IP 689 networks, where different NSIS QOSMs can be defined to realize 690 heterogeneous QoS control mechanisms used at underlying network 691 domains. This section presents an analysis of how to fulfill the e2e 692 QoS control in accord with the definitions of the ITU-T RACF 693 functional architecture and reference points by using the NSIS 694 protocol suites. More importantly, we adopt the idea of distinct 695 separation between the intra-domain and inter-domain QoS control 696 planes at each AS to realize the standardized and transparent 697 inter-operator-domain QoS interactions while hiding the 698 heterogeneities of the intra-domain QoS control mechanisms. By 699 transparent, we mean that operators do not have to reveal any details 700 about the internal function of their networks, including the used QoS 701 signalling protocols. The analyses of applying the NSIS inter-domain 702 QOSM for the inter-domain QoS control and applying the NSIS 703 intra-domain QOSM for the intra-domain QoS control in the ITU-T RACF 704 functional architecture are discussed in this section, respectively. 705 Finally, the mapping between the ITU-T RACF entities and the NSIS 706 entities is given based on the analyses. 708 4.2. The Analysis of Applying the NSIS Intra-domain QOSM for 709 Intra-domain QoS Control in the ITU-T RACF Functional Architecture 711 In order to analyse how the NSIS Intra-domain QOSM concept can be 712 applied and used by the ITU-T RACF architecture, a list with the 713 ITU-T RACF functional entities and their features is given in 714 subsections 4.2.1.1 to 4.2.1.6. Section 4.2.1.7 presents the QoS 715 features that can be supported by the CPE. Subsequently, in 716 Section 4.2.1.8, the typical NSIS intra-domain QOSM features will be 717 compared with the features supported by the ITU-T RACF functional 718 entities. 720 4.2.1 The ITU-T RACF functional entities 722 As mentioned in Section 4.1, the RACF functional entities specified 723 in [Y.RACF] include: Service Control Function (SCF), Network 724 Attachment Control Functions (NACF), Policy Decision Functional 725 Entity (PD-FE), Transport Resource Control Functional Entity 726 (TRC-FE), Policy Enforcement Functional Entity (PE-FE), Transport 727 Resource Enforcement Functional Entity (TRE-FE). 729 The texts given in the subsections 4.2.1.1 to 4.2.1.7 are copied 730 from [Y.RACF]. 732 4.2.1.1 Service control functions 734 The following texts are copied from [Y.RACF]. 736 "The SCF in different domains can interact with PD-FE via the Rs 737 reference point. The SCF makes requests for transport resources and 738 may receive notifications when resources are reserved and released. 740 * The SCF shall provide information to the PD-FE to identify media 741 flows and their required QoS characteristics (e.g., service class, 742 bandwidth). 744 * The SCF may provide service priority information to the PD-FE to 745 facilitate appropriate priority handling (e.g., priority 746 processing of the resource request, resource pre-emption if 747 needed). 748 * The SCF may request resource usage information through the PD-FE 749 for charging or other usage metering. 750 * The SCF may provide service information to the PD-FE to facilitate 751 appropriate dynamic firewall working mode selection. 752 * The SCF shall indicate when the resource is to be committed (i.e. 753 opening gate and allocating bandwidth). A resource may either be 754 committed immediately or just reserved for a later commitment. 755 * When a NAPT function is required, the SCF shall request address 756 binding (mapping) information and perform required modifications 757 in signalling messages. This includes any address information 758 modifications that may be required for binding. 759 * When the pull mode along with a path-coupled resource reservation 760 mechanism is used, the SCF shall indicate to the PD-FE whether it 761 should be notified when resources are reserved, modified and 762 released. 763 * When an authorisation token mechanism is used, the PD-FE may 764 provide the SCF one or multiple authorisation tokens, which shall 765 be included in a signalling message to CPE.", from [Y.RACF] 767 4.2.1.2 Network Attachment Control Functions (NACF) 769 The following texts are copied from [Y.RACF]. 771 "Network attachment control functions (NACF) provide the following: 773 * Dynamic provision of IP address and other user equipment 774 configuration parameters. 775 * Authentication of user access network, prior or during the IP 776 address allocation procedure. 777 * Authorisation of user access network, based on user profiles 778 (e.g., access transport subscription). 779 * Access network configuration, based on user profiles. 780 * Location management. 782 The PD-FE in the access network interacts with the NACF via the Ru 783 reference point to obtain the transport subscription information and 784 the binding information of the logical/physical port address to an 785 assigned IP address.", from [Y.RACF] 787 4.2.1.3 Policy decision functional entity (PD-FE) 789 The following text is copied from [Y.RACF]. 791 "The PD-FE handles the QoS resource requests received from the SCF 792 via the Rs reference point or from PE-FE via the Rw reference point. 793 The PD-FE contains the following functions: 795 * Final decision point (FDP): This function first checks the QoS 796 resource request based on service information, network policy 797 rules and transport subscription information, and then interacts 798 with the TRC-FE via the Rt reference point to detect and determine 799 the requested QoS resource within the involved access and/or core 800 transport networks. 801 * The FDP makes the final admission decision for media flows of a 802 given service based on network policy rules, service information, 803 transport subscription information, and decision on resource 804 availability. 805 * The FDP indicates the loss of connectivity: It informs the SCF 806 that the transport resource previously granted is lost. 807 The SCF may request PD-FE to relinquish all resources associated 808 with the session. 809 * QoS mapping - Technology independent (QMTI): This function maps 810 the service QoS parameters and priority received from the SCF 811 via the Rs reference point to network QoS parameters 812 (e.g., Y.1541 class) and priority based on the network policy 813 rules. 814 * Gate control (GC): This function controls PE-FE to install and 815 enforce the final admission decisions via the Rw reference point 816 (e.g., opening or closing the gate). The action to pass or drop 817 IP packets is based on a set of IP gates (packet classifiers, 818 e.g., IP 5-tuple) and transport interface identification 819 information (e.g., VLAN/VPN ID) as needed. 820 * IP packet marking control (IPMC): This function takes decisions 821 on packet marking and remarking of flows. The marking may consider 822 the priority of the flow and traffic engineering parameters. 823 * NAPT control and NAT traversal (NAPTC): This function interacts 824 with PE-FE and SCF to provide the address binding information for 825 NAPT control and NAT traversal as needed. 826 * Rate limiting control (RLC): This function makes decisions on the 827 bandwidth limits of flows (e.g., for policing). 828 * Firewall working mode selection (FWMS): This function selects the 829 working mode of the firewall based on the service information. 830 Four packet inspection modes could be identified (static packet 831 filtering, dynamic packet filtering, stateful inspection, deep 832 packet inspection). 833 * Core network path selection (CNPS): This function chooses the core 834 network ingress and/or egress path for a media flow based on the 835 service information and technology independent policy rules at 836 the involved PD-FE. 837 * Network selection (NS): This function locates core networks that 838 are involved to offer the requested QoS resource. It locates the 839 PE-FE instances that are involved to enforce the final admission 840 decisions. 842 The PD-FE shall make the final policy decisions based on the service 843 information (e.g., service type, flow description, bandwidth, 844 priority), transport network information (e.g., resource admission 845 result, network policy rules) and transport subscription information 846 (e.g., maximum upstream/downstream capacity). The policy decision 847 shall provide sufficient information to make the PE-FE perform the 848 resource control operation e.g., gate opening/closing, bandwidth 849 allocation/rate limiting, packet marking, traffic policing/shaping, 850 NAPT and address latching. The policy decisions may be composed of 851 flow ID, IP addresses, bandwidth, gate status, time/volume limit, 852 traffic descriptor etc. 854 The PD-FE can be stateful or stateless depending on the complexity 855 of the specific network environment, application characteristics 856 and deployment architecture. 857 * The stateless PD-FE only maintains the transaction state 858 information, e.g., state held for the duration of a 859 request-response operation. In order to be stateless, the PD-FE 860 shall generate the resource control session information for each 861 resource control request from the SCF, which can be stored in the 862 SCF, TRC-FE or PE-FE and used to retrieve the state information 863 together with pertinent information flows. 864 * The stateful PD-FE may maintain a variety of resource control 865 session information within PD-FE, such as the session duration, 866 the resource control session information (e.g., the association 867 between SCF and PD-FE, PD-FE and TRC-FE, PD-FE and PE-FE), the 868 resource reservation limit (e.g., time limit/volume limit), 869 resource reservation status (i.e. authorized, reserved, or 870 committed) and physical/logical connection ID.", from [Y.RACF] 872 4.2.1.4 Transport Resource Control Functional Entity (TRC-FE) 874 The following text is copied from [Y.RACF]. 876 "TRC-FE is responsible for transport technology dependent resource 877 control as follows: 879 * Resource status monitoring and network information collection 880 The TRC-FE collects and maintains the network information and 881 resource status information. The resource status information 882 may be specific to the resource based admission control scheme 883 being used by TRC-FE, i.e., whether it is accounting, out-of-band 884 measurements, in-band measurements, or reservation-based. 885 * Resource based admission control 886 On receipt of the resource request from PD-FE, the TRC-FE shall 887 perform resource based admission control based on the QoS and 888 priority requirements received from the PD-FE (e.g., bandwidth 889 and Y.1541 class), in conjunction with the resource utilization 890 information and transport dependent policy rules, and shall 891 update the resource status and return the result to PD-FE. 892 * Transport dependent policy control 893 Transport dependent policy rules are a set of rules specific to a 894 transport sub-network and technology. The TRC-FE ensures that a 895 request from the PD-FE matches the transport specific policy rules 896 (e.g., access link policy rules, core transport network policy 897 rules), as multiple PD-FEs can request resources from the same 898 TRC-FE. The TRC-FE shall coordinate the resource requests from 899 PD-FEs and take into account transport dependent policy rules to 900 decide if the resource requests can be supported (e.g., 901 usage/constraints of particular transport QoS class and total 902 capacity). 904 The TRC-FE provides the following basic functions: 905 * QoS mapping - Technology dependent (QMTD): This function maps the 906 network QoS parameters and classes received from the PD-FE via the 907 Rt reference point to transport (technology dependent) QoS 908 parameters and classes based on specific transport policy rules, 909 and accommodating the diversity of transport technologies. 910 * When mapping network QoS parameters to transport (technology 911 dependent) QoS parameters, TRC-FE considers the underlying 912 transport technology. A set of network QoS parameters may be 913 mapped to different sets of transport (technology dependent) QoS 914 parameters based on transport technologies. The TRC-FE has 915 knowledge of the QoS related features of the underlying transport 916 network and map the network QoS parameters to the best matching 917 transport (technology dependent) QoS parameters for given 918 transport technology. The mapping policy rules need to be provided 919 by network operators. 920 * Technology dependent decision point (TDDP): This function receives 921 and responds to the QoS resource request from PD-FE via the Rt 922 reference point. This function detects and determines the 923 availability of requested QoS resource based on the network 924 topology and resource status information, as well the transport 925 subscription information in access networks. It may make path 926 selection between ingress and egress points within its purview of 927 a sub-domain to satisfy the QoS resource requirements. If the 928 requested resource is available, this function updates the 929 resource status to include the new application request and 930 responds PD-FE with a positive answer (e.g., resource available), 931 otherwise, it responds PD-FE with a negative answer (e.g., 932 resource unavailable). 933 * Network topology maintenance (NTM): This function collects and 934 maintains the transport network topology information via the Rc 935 reference point. Note that the Rc reference point can be connected 936 to any transport functions including PE-FE, TRE-FE and other 937 entities defined in [Y.2012] to obtain the relevant resource 938 information. 939 * Network resource maintenance (NRM): This function collects and 940 maintains the transport resource status information via the 941 Rc reference point. 942 * Element resource control (ERC): This function controls the 943 QoS-related resources in the intermediate transport elements at 944 the aggregate level (e.g., VLAN, VPN, LSP). Note that the ERC is 945 for further study. 947 The implementation of the TRC-FE in various access networks may be 948 different according to access transport technologies and 949 corresponding QoS mechanisms in the data plane. The implementation 950 of the TRC-FE may be different in various core networks according to 951 core transport technologies and corresponding QoS mechanisms in the 952 data plane. ", from [Y.RACF]. 954 4.2.1.5 Policy Enforcement Functional Entity (PE-FE) 956 The following text is copied from [Y.RACF]. 958 "The PE-FE enforces the network policy rules instructed by the PD-FE 959 on a per-subscriber and per-IP flow basis. It should be able to 960 perform the following functions based on flow information such as 961 classifier (e.g., IPv4 5-tuple) and flow direction, as well as 962 transport interface identification information (e.g., VLAN/VPN ID, 963 LSP Label) as needed. The functions of the PE-FE include: 965 * Opening and closing gate: enabling or disabling packet filtering 966 for an IP media flow. A gate is unidirectional, associated with a 967 media flow in either the upstream or downstream direction. When a 968 gate is open, all of the packets associated the flow are allowed 969 to pass through; when a gate is closed, all of the packets 970 associated with the flow are blocked and dropped. 971 * Rate limiting and bandwidth allocation 972 * Traffic classification and marking 973 * Traffic policing and shaping 974 * Mapping of IP-layer QoS information onto link layer QoS 975 information based on pre-defined static policy rules (e.g., 976 setting 802.1p priority values) 977 * Network address and port translation 978 * Media relay (i.e. address latching) for NAT traversal 979 * Collecting and reporting resource usage information (e.g., 980 start-time, end-time, octets of sent data) 981 * Packet-filtering-based firewall: inspecting and dropping packets 982 based on pre-defined static security policy rules and gates 983 installed by PD-FE. 985 There are four packet inspection modes for packet-filtering-based 986 firewall: 988 * Static packet filtering: inspecting packet header information 989 and dropping packets based on static security policy rules. This 990 is the default packet inspection mode applied for all flows. 991 * Dynamic packet filtering: inspecting packet header information and 992 dropping packets based on static security policy rules and dynamic 993 gate status. 994 * Stateful inspection: inspecting packet header information as well 995 as TCP/UDP connection state information and dropping packets based 996 on static security policy rules and dynamic gate status. 998 * Deep packet inspection: inspecting packet header information, 999 TCP/UDP connection state information and the content of payload 1000 together, and dropping packets based on static security policy 1001 rules and dynamic gate status.", from [Y.RACF]. 1003 4.2.1.6 Transport resource enforcement functional entity (TRE-FE) 1005 The following text is copied from [Y.RACF]. 1007 "The TRE-FE enforces the transport resource policy rules instructed 1008 by the TRC-FE at the technology-dependent aggregate level (e.g., 1009 VLAN, VPN and MPLS). It should be able to perform the functions 1010 based only on transport link information (e.g., VLAN/VPN ID, and 1011 LSP Label). For example a TRE-FE may be used to modify the bandwidth 1012 associated with an LSP, or to set ATM traffic management parameters 1013 such as cell rate or burst size. Note that the scope and functions 1014 of the TRE-FE are for further study.", from [Y.RACF]. 1016 4.2.1.7 Customer Premises Equipment (CPE) 1018 The following text is copied from [Y.RACF]. 1020 "According to the capability of QoS negotiation, the CPE can be 1021 categorised as follows: 1023 * Type 1-CPE without QoS negotiation capability (e.g., vanilla 1024 soft phone, gaming consoles) 1025 The CPE does not have any QoS negotiation capability at either 1026 the transport or the service stratum. It can communicate with 1027 the SCF for service initiation and negotiation, but cannot 1028 request QoS resources directly. 1029 * Type 2-CPE with QoS negotiation capability at the service 1030 stratum (e.g., SIP phone with SDP/SIP QoS extensions). 1031 The CPE can perform service QoS negotiation (such as bandwidth 1032 through service signalling but is unaware of attributes specific 1033 to the transport. The service QoS concerns characteristics 1034 pertinent to the application. 1035 * Type 3-CPE with QoS negotiation capability at the transport 1036 stratum (e.g., UMTS UE). 1037 The CPE support RSVP-like or other transport signalling (e.g., 1038 GPRS session management signalling, ATM PNNI/Q.931). it is 1039 able to directly perform transport QoS negotiation throughout 1040 the transport facilities (e.g., DSLAM, CMTS, SGSN/GGSN). 1042 Note that the SCF shall be able to invoke the resource control 1043 process for all types of CPE.", from [Y.RACF]. 1045 4.2.1.8 Comparison between NSIS intra-domain QOSM features and 1046 features supported by the ITU-T RACF functional entities 1048 This draft consideres an Intra-domain QOSM as a QOSM that can be used 1049 within one administrative domain and that supports either a 1050 centralised or distributed QoS management approach. 1052 The centralised approach mainly uses one Intra-domain QoS controller 1053 that is usually located off-path. However, more than one Inter-domain 1054 QoS controllers can be used within one administrative domain. In this 1055 situation the centralised Intra-domain QoS controller(s) is (are) 1056 considered to be the entitie(s) that provide the Policy Decision 1057 Point (PDP). In addition to these entitie(s), the centralised 1058 Intra-domain QOSM consists of entities that can be managed by the 1059 centralised Intra-domain QOS controllers. These entities are located 1060 on path and can be considered as Policy Enforcement Points (PEP). 1062 The distrbuted approach uses more than one Intra-domain QoS 1063 controllers that are usually located on path and can be either 1064 located on the boundary of the administrative domain or on each on 1065 path node within the administrative domain. However, it is possible 1066 that the distributed Intra-domain QoS controllers located at the 1067 boundaries of the administrative domain can provide more features 1068 than the ones located within the domian and are not boundary nodes. 1069 In the distributed QoS management approach it is considered that the 1070 distributed Intra-domain QoS controllers are PDP and PEP. 1072 By analysing Sections 4.2.1.1 to 4.2.1.6 it can be observed that 1073 the PD-FE, TRC-FC and SCF and NACF are mainly used by the control 1074 plane, while the functional entities PE-FE and TRE-FE are mainly used 1075 by the data plane. However, the latter two functional entities could 1076 also perform a limited number of control functions, such as bandwidth 1077 availability control and bandwidth modification. The PD-FE and TRC-FC 1078 are considered to be PDPs while the PE-FE and TE-FE are considered to 1079 be PEPs. All these functional entities can be used for both the push 1080 and pull modes of QoS resource control scenarios. 1082 This means that the PD-FE, TRC-FE, PE-FE, TRE-FE can be considered as 1083 NSIS PDP and/or PEP Intra-domain QOS controllers. 1085 The Type 1-CPE and Type 2-CPE cannot perform on-path QoS negotiations 1086 and therefore, it is considered that the CPE is used for the Push 1087 mode QoS resource control scenario. In this case it is considered 1088 that the CPE is not NSIS aware. The Type 3-CPE can perform on-path 1089 QoS negotiations and therefore, it is considered that the CPE is used 1090 for the Pull mode QoS resource control scenario. In this case it is 1091 considered that the CPE is NSIS aware. 1093 4.3 The Analysis of Applying the NSIS Inter-domain QOSM for Inter-domain 1094 QoS control in the ITU-T RACF Functional Architecture 1096 The inter-operator-domain communications for e2e QoS control in the 1097 ITU-T functional architecture are discussed in section 10 of 1098 [Y.RACF], where two ways of passing the QoS requirements for a given 1099 service over e2e paths. For the RACF Push resource control mode, the 1100 QoS requirements for a given service are proposed to be passed over 1101 the e2e path through the application layer signaling or through the 1102 Ri reference point; whereas, for the RACF Pull resource control mode, 1103 the QoS requirements for a given service are proposed to be passed 1104 over the e2e path through path-coupled QoS signaling (e.g., NSIS). 1105 However, due to the fact that the current NSIS intra-domain QOSMs 1106 (e.g., RMD-QOSM [RMD-QOSM] and Y.1541-QOSM [Y.1541-QOSM]) are all 1107 dedicated to a specific QoS control mechanism but the RACF PD-FE 1108 entity is located at the technology-independent control layer, we 1109 argue that the QoS-NSLP messages carrying those intra-domain QOSM 1110 QSPECs will not be understood by the RACF PD-FE when the on-path NSIS 1111 entities trigger the QoS request to the PD-FE and a NSIS inter-domain 1112 QOSM, which should also be independent from the underlying 1113 intra-domain QoS mechanisms, is needed to fulfill the e2e QoS control 1114 in the ITU-T RACF architecture. 1116 Moreover, in the RACF model the procedures for QoS control are 1117 focused on how the service control function requests QoS 1118 (authorization and reservation) to the PD-FE, and how the later pushs 1119 the admission control decisions into the network nodes. So, all 1120 described procedures in [Y.RACF] are local to one operator network. 1121 The InterDomain-QoSM, provides the RACF model with the PD-FE/PD-FE 1122 communication needed for transparent end-to-end QoS control. By 1123 transparent, we mean that operators do not have to reveal any details 1124 about the internal function of their networks, including the used QoS 1125 signalling protocols. 1127 Below we provide an analysis how the major issues that need to be 1128 consider to apply the InterDomain-QoSM to the ITU-T RACF model for 1129 inter-domain QoS control. Starting from the CPE, the InterDomain-QoSM 1130 follows the same RACF assumptions about the QoS capabilities of the 1131 CPE. According to the capability of QoS negotiation, the CPEs can be 1132 categorized as follows (see further in Section 4.2.1.7): 1134 * Type 1: CPE without QoS negotiation capability. The CPE does not 1135 have any QoS negotiation capability at either transport or service 1136 stratum. It can communicate with Service Control Functions for 1137 service initiation and negotiation, but cannot request QoS 1138 resources directly. So, in this case it is up the the access 1139 network to set the most usefull SLSs based on the type of previous 1140 CPE service negotiations and by using the capability provided by 1141 the InterDomain-QoSM. 1143 * Type 2: CPE with QoS negotiation capability at the service stratum 1144 (e.g. SIP CPE). The CPE can perform service QoS negotiation (such 1145 as bandwidth) through service layer signalling, but is unaware of 1146 QoS attributes specific to the transport. When the CPE is 1147 initiating communication sessions that span beyond its access 1148 network, this CPE QoS requests are passed to the InterDomain-QoSM. 1150 * Type 3: CPE with QoS negotiation capability at the transport 1151 stratum (e.g. UMTS CPE). The CPE supports RSVP-like or other 1152 transport layer signalling. It is able to directly perform 1153 transport QoS negotiation throughout the transport facilities. In 1154 this case the RSVP-like signalling is used to configure network 1155 devices in the access network, being control passed to the 1156 InterDomain-QoSM to pass network border. In each network the 1157 control can be passed from the InterDomain-QoSM back to the 1158 RSVP-like protocol. 1160 In order to support the end-to-end communication of different type of 1161 CPEs, the InterDomain-QoSM support the two QoS resource control modes 1162 described in the RACF: 1164 * Push Mode: In this case the CPE (of type 2) communicates with the 1165 RACF Service Control Function (SCF), and the later issue a request 1166 to the RACF for QoS resource authorization and reservation. The 1167 RACF pushes the decisions to transport functions for policy and 1168 resource enforcement. This mode can be also used for CPE of type 1, 1169 in which case, the SCFs determine the QoS requirements of the 1170 requested service on behalf of CPEs, and based on inter-domain 1171 information that may be provided by the InterDomain-QoSM. 1173 * Pull Mode: The SCFs issue a request to RACF for QoS resource 1174 authorization, and QoS resource reservation and the decisions are 1175 requested by Transport Functions upon receiving transport-layer QoS 1176 signalling messages. In mode is suitable for CPEs of type three, 1177 which can explicitly request the QoS resource reservation through 1178 transport-layer QoS signalling. 1180 In what concerns the three resource control state described by RACF 1181 (Authentication, Reservation and Commitment), the InterDomain-QoSM 1182 does not cover the committed state. That is to say, the 1183 InterDomain-QoSM describes a mechanism to reserve resources (SLSs) 1184 for different types of traffic, but does not say anything about 1185 how/when the SLSs are committed. The commitment state can be included 1186 by considering the validity of the SLSs negotiated by the 1187 InterDomain-QoSM. 1189 From the architecture point of view, an NSIS entity named 1190 Inter-domain QNE implements the NSIS Inter-domain QoSM and in charge 1191 of the inter-operator-domain interactions at each AS. Moreover, the 1192 Inter-domain QNE can be implemented in three possible ways: 1194 i) Fully centralized, which means that the Inter-domain QNE 1195 functionality is implemented in an interior network node. 1197 ii) Fully distributed, which means that the Inter-domain QNE 1198 functionality is implemented in all edge network nodes. 1200 iii) A hybrid approach of i) and ii), in which the Inter-domain QNE 1201 is co-located with interior network nodes close to edge devices. 1202 This is while in option ii) we have one inter-domain QNE 1203 implemented in each edge router (which does not separate data 1204 and control plane), in this option we have one Inter-domain QNE 1205 controlling a subset of edge devices and we separated the data 1206 from the control plane. 1208 Each of these approaches has advantages and disadvantages. For 1209 instance: 1211 - The centralized option does not need the synchronization between 1212 several Inter-domain QNEs in the same network, but has scalability 1213 and resilience problems. In terms of signaling, it needs an 1214 off-path NSIS QoS signaling to fulfill the ITU-T RACF Ri reference 1215 point. 1217 - The fully distributed option presents the highest scalability and 1218 resilience properties, but it incorporates the constraint that the 1219 signaling will be processed on the nodes which also handle the 1220 data flows themselves. From the signaling point of view, there is 1221 no need for a new off-path QoS signaling and the Ri reference 1222 point can be implemented by using the on-path NSIS QoS signaling, 1223 since the signaling can be done by using QoS-NSLP in two steps, 1224 inter-domain and intra-domain. 1226 - The hybrid option seems to provide a good compromise between the 1227 de-coupling of signaling and data and the needed scalability and 1228 resilience. In terms of signaling, it needs an off-path 1229 inter-domain QoS signaling to implement the Ri reference point. 1230 In addition, it may also need an off-path NSLP intra-domain 1231 signaling to implement the Rd reference point to synchronize the 1232 set of Inter-domain QNEs (i.e., the inter-domain PD-FEs). 1234 If fact, the most suitable solution (fully centralized, fully 1235 distributed or hybrid) will strongly depend on the characteristics of 1236 the domain, such size, network technology, and method used to assure 1237 QoS. These operation modes of the inter-domain QNE are an add-on to 1238 the RACF, since the RACF specificiation does not mention this issue. 1239 In what concerns the RACF entities, we propose to slip the PD-FE 1240 functions into the inter-domain PD-FE for inter-domain QoS control 1241 and the intra-domain PD-FE for intra-domain QoS control and map the 1242 Inter-domain QNE to the inter-domain PD-FE. thus, for the case that 1243 more than one InterDomain-QNEs exist at an operator AS, they can 1244 interact with each other via the RACF Rd reference point. 1246 Here we focus our analysis on the inter-domain PD-FE, which interacts 1247 with the intra-domain PD-FE and PE-FE. Furthermore, the 1248 InterDomain-QoSM will be used to fulfill the Ri reference point 1249 between peer inter-domain PD-FE at adjacent operator domains. This 1250 inter-domain QoS control can be done based on two scenarios: in one 1251 scenario (push mode), the CPE requests QoS to the SCF or it is the 1252 SCF that handle QoS requests on behalf of the CPEs. In another 1253 scenario (pull mode), the CPE requests QoS via a path-coupled QoS 1254 signalling in the transport stratum. In any case the inter-domain 1255 QoS control is due by the InterDomain-QoSM via the NSIS 1256 path-decoupled message association created over the Ri reference 1257 point of the PD-FE (see section 5.2.1 - GIST analysis). In other 1258 words, the path-coupled signaling is only used between CPEs and the 1259 access network and inside each network being the inter-domain 1260 signaling done by InterDomain-QoSM via Ri reference point. This usage 1261 of the path-coupled signalling, means that each network can use a 1262 different path-coupled signaling implementation, since that 1263 signalling is never used end-to-end. 1265 4.4 The mapping between ITU-T RACF Entities and NSIS Entities 1267 Based on the results of the analysis done in Sections 4.2 and 4.3, it 1268 can be observed that the ITU-T RACF PD-FE, TRC-FE functional entities 1269 can be considered as NSIS PDP Intra-domain and Inter-domain QOS 1270 controllers, while the ITU-T RACF PE-FE and TRC-FE functional 1271 entities can be considered as NSIS PDP and/or PEP Intra-domain QoS 1272 controllers. 1274 In addition to the analysis given in Sections 4.2 and 4.3, it should 1275 be observed that all functional entities support, in addition to QoS 1276 features, also NAT and network management features. In this draft we 1277 will only consider the QoS features without analysing the rest of the 1278 features. 1280 The NACF function is mainly used for network attachment, e.g., 1281 authentication, authorization, dynamic provisioning of IP addresses 1282 and mobility support. Therefore, this functional entity and its 1283 interactions will not be considered in the mapping process of the 1284 RACF entities to NSIS entities. 1286 The SCF function can be considered to be a functional entity that can 1287 be managed by non NSIS aware signaling. Therefore, also this 1288 functional entity is not considered in the mapping process. 1290 The ITU-T CPE functional entity can be considered as a NSIS QNI or 1291 QNR when used in association with the pulled mode of QOS resource 1292 control. 1294 Based on the above, we provide the following mapping between the 1295 ITU-T RACF functional entities to the NSIS entities. 1297 * (Inter-domain) RACF TRC-FE is mapped to TRC-FE (NSIS) 1298 Interdomain QoS controller 1299 * (Inter-domain) RACF PD-FE is mapped to PD-FE (NSIS) Interdomain 1300 QoS controller 1302 * (Intra-domain) RACF TRC-FE is mapped to TRC-FE (NSIS) 1303 Intra-domain QoS controller 1304 * (Intra-domain) RACF PD-FE is mapped to PD-FE (NSIS) Intra-domain 1305 QoS controller 1306 * (Intra-domain) RACF PE-FE is mapped to PE-FE (NSIS) Intra-domain 1307 QoS controller 1308 * (Intra-domain) RACF TRE-FE is mapped to TRE-FE (NSIS) 1309 Intra-domain QoS controller 1311 Additional observations that can be made are the following. The 1312 TRC-FE and TRE-FE are technology dependent functional entities. 1313 This draft will mainly focus on technology independent features and 1314 therefore these two functions and their interactions will not be 1315 further considered in the mapping process from the RACF entities to 1316 NSIS entities. 1318 The intercommunication between the NSIS entities is accomplished 1319 using the NSIS protocol suites and is specified in the following way: 1321 * between NSIS PD-FE Inter-domain QoS controllers is done using a 1322 QSPEC that carries the Rd++ information elements. 1323 Rd++ is the interface that equals to Rd, but that will have to be 1324 extended in the future to fulfil the Ri interface. 1326 The Ri interface is a logical interface that will be supported by 1327 using the NSIS protocol suite. The Ri informational elements, 1328 specified in [Y.RACF], are carried by a NSIS QSPEC, that we denote 1329 in this draft as Ri_QSpec. 1331 * between the PD-FE (NSIS) inter-domain QoS controller and the PD-FE 1332 (NSIS) intra-domain QoS controller is accomplished using a QSPEC, 1333 denoted as Rd_QSpec, that carries the Rd informational elements 1334 specified in [Y.RACF]. 1336 * between the PD-FE (NSIS) intra-domain QoS controller and another 1337 PD-FE (NSIS) intra-domain QoS controller is accomplished using the 1338 same Rd_QSpec as above. Note that the intercommunication between 1339 these entities could also be performed using other types of 1340 Intra-domain QOSMs. 1342 * between the PD-FE (NSIS) inter-domain QoS controller and the PE-FE 1343 (NSIS) intra-domain QoS controller is accomplised using the 1344 Rw_QSpec, which carries the Rw informational elements specified in 1345 [Y.RACF]. 1347 * between the PD-FE (NSIS) intra-domain QoS controller and the PE-FE 1348 (NSIS) intra-domain QoS controller is accomplised using the same 1349 Rw_QSpec as above. 1351 5. The Basic Features of Interdomain-QOSM 1352 The rest of this document specifies the NSIS Inter-domain QOSM which 1353 can be applied to the ITU-T RACF functional architecture for for e2e 1354 QoS control across heterogeneous operator domains. The basic features 1355 of the Interdomain-QOSM are described here. 1357 5.1 Overview 1359 The NSIS Interdomain-QOSM aims at realizing the inter-operator-domain 1360 QoS interactions between adjacent operator ASs in a standarized way 1361 while hiding the heterogeneities of the intra-domain QoS control 1362 mechanisms in use at each domain. As mentioned above, the 1363 Inter-domain QNE that will implement the Interdomain-QOSM should 1364 support three possible operation mode: fully centralized, fully 1365 distributed and hybrid, and it should also be able to interact with 1366 different intra-domain QOSMs deployed at each operator domain. To 1367 achieve the above objectives of the Interdomain-QOSM, a set of 1368 supports from the underlying NSIS GIST and QoS-NSLP protocols are 1369 needed, especially for the Inter-domain QNE discovery and the 1370 transport of InterDomain-QOSM messages. Moreover, to successfully 1371 apply the Interdomain-QOSM to the e2e QoS control in the ITU-T RACF 1372 functional architecture, the impact of the Interdomain-QOSM on the 1373 RACF architecture should also be analyzed. Finally, we discuss the 1374 e2e QoS control scenarios the Interdomain-QOSM can support for the 1375 ITU-T RACF architecture. 1377 5.2 The Assumptions for the Interdomain-QOSM 1379 This part provides the first analysis of how to include the 1380 InterDomain-QoSM in the NSIS protocol stack, by describing a set of 1381 assumptions about NSIS that are central to the development of the 1382 proposed QOSM. It introduces section 6.6, which allows us to go 1383 back to NSIS with some proposals for adjustments in order to fulfill 1384 all the requirements of the described InterDomain-QoSM. 1386 This section analysis the potential requirements of the 1387 InterDomain-QOSM on the GIST [GIST] and QoS-NSLP [QoS-NSLP]: 1389 i) We analyze the possible impact of the InterDomain-QoSM on GIST, 1390 namely its support for message association between edge devices 1391 and the inter-domain QoS controller, between the inter-domain QoS 1392 controller and the edge devices, and between two inter-domain QoS 1393 controllers (in the case of a distributed operation mode of the 1394 InterDomain-QoSM. 1396 ii) We analyze until what extend can QoS-NSLP signaling and the 1397 defined QSpec be re-used. 1399 Furthermore, regarding to the functional architecture and entities 1400 defined in the ITU-T RACF document [Y.RACF], we consider only the 1401 technology independent QoS control features and thus, the RACF TRC-FE 1402 and TRE-FE entities are not covered by our analysis and mapping in 1403 this document. 1405 5.2.1 GIST Analysis 1407 The NSIS working group is currently developing a protocol suite in 1408 which the signaling messages will be processed on the nodes which 1409 also handle the data flows themselves ("path-coupled signaling"). 1410 Complementary to this method, a complementary routing method 1411 partially decoupled from the data path is being analyzed. This new 1412 off-path Message Routing Method (MRM) allows the signaling and data 1413 paths to be partially decoupled, without sacrificing the integration 1414 with routing. 1416 The major assumption that the InterDomain-QoSM makes of NSIS is the 1417 support of an off-path MRM. 1419 The current proposal for an off-path MRM 1420 [draft-hancock-nsis-pds-problem-03] defines two discovery mechanisms, 1421 one starting in one off-path node and finishing in one on-path node, 1422 and another starting in one on-path node and finishing in one 1423 off-path node. Figure 3 illustrates these two methods. 1425 +----------+ 1426 | NSLP | 1427 Messaging association +----------+ 1428 ##########################>>| GIST | 1429 # ....................| C/D-mode | 1430 # . GIST-Response +----------+ 1431 +----------+ # . ^ * 1432 | NSLP | # . . * 1433 +----------+ # . . * 1434 | |<<########## . . V 1435 | GIST | . +-.--------+ 1436 | C/D-mode |<................... GIST-Query | . GIST | 1437 | |.......................................... D-mode| 1438 +----------+ +----------+ +----------+ +----------+ 1439 | | |RAO bypass| |RAO bypass| | | 1440 | IP | | IP | | IP | | IP | 1441 |Forwarding| |Forwarding| |Forwarding| |Forwarding| 1442 --------------------------------------------------------------------> 1443 +----------+ +----------+ +----------+ +----------+ 1444 +----------+ 1445 | NSLP | 1446 +----------+ Messaging Association 1447 | GIST |<<########################## 1448 | C/D-mode | # 1449 +----------+ # 1450 * . ^ # 1451 * . . # +----------+ 1452 * . . # |Signalling| 1453 V . . # | Appl. | 1454 +-------.-.+ # +----------+ 1455 | . .| GIST-Response ##########>>| | 1456 | GIST . .........................................| GIST | 1457 |D-mode . | GIST-Query | C/D-mode | 1458 | ...|......................................>| | 1459 +----------+ +----------+ +----------+ +----------+ 1460 | | |RAO bypass| |RAO bypass| | | 1461 | IP | | IP | | IP | | IP | 1462 |Forwarding| |Forwarding| |Forwarding| |Forwarding| 1463 --------------------------------------------------------------------> 1464 +----------+ +----------+ +----------+ +----------+ 1466 ---------> = Data flow (and direction) 1467 .........> = GIST D-mode messages (and direction) 1468 <<######>> = GIST C-mode messages (bidirectional) 1469 *********> = Control (off-path node to router) 1471 Figure 3: discovering a downstream off-path node from a on-path node 1472 (top figure) and discovering a downstream on-path node from 1473 an off-path node (bottom figure). 1475 These two methods are of use to discover a inter-domain QNE from an 1476 edge device by which flows enter a domain (ingress device), and for 1477 an inter-domain QNE to discover an edge device by which flows exit a 1478 domain (egress device). However, these two discovery mechanism do not 1479 support the discovery of one QoS controller by its peers. This is a 1480 kind of off-path to off-path discovery mechanism. 1482 The off-path MRM proposal mention "Off-path 'server' discovery from 1483 another off-path node" in section 3.1, but does not describe that 1484 mechanism. Nevertheless, this off-path to off-path discovery 1485 mechanism may be build by using the two methods (on-path to off-path 1486 discovery and vice-versa) described in the off-path MRM proposal by 1487 allowing the configuration of an on-path node for selecting a 1488 specific off-path device. This is one downstream on-path node (i.e., 1489 the edge routers in the case of the InterDomain-QoSM) should be 1490 configured to select an off-path QoS controller to which its received 1491 GIST-QUERY message should be forwarded. 1493 Figure 4 illustrates the setup of an association between two 1494 off-path inter-domain QNEs located in two different domains. After 1495 the edge QNE1 at Domain A processes the QoS-NSLP message from its 1496 upstream interior QNE, it will connect to the inter-domain QNE1 in 1497 its domain which is configured to serve it (via GIST D-mode or C-mode 1498 depending on the configuration or requirement). Next, the 1499 inter-domain QNE1 sends a GIST-Query message, which is forwarded by 1500 the Edge QNE1 in its domain and intercepted by the Edge QNE3 in 1501 Domain B. Then, this intercepted Query message is forwarded to the 1502 inter-domain QNE2 in Domain B, which is configured to serve Edge 1503 QNE3. To this end, the inter-domain QNE2 at Domain B knows the 1504 necessary info of its peer at Domain A and can send the GIST-Response 1505 message directly to its peer (here, i.e., inter-domain QNE1 at Domain 1506 A). Finally, a message association is set up between them. 1508 Domain A Domain B 1510 Inter-domain QNE1 Inter-domain QNE2 1511 +----------+ +----------+ 1512 |Inter-QOSM| Message Association |Inter-QOSM| 1513 +----------+<<############################>>+----------+ 1514 | GIST |<...............................| GIST | 1515 | C/D-mode |<.-. GIST-Response | C/D-mode | 1516 +----------+ | +----------+ 1517 . . ^ 1518 . | . 1519 +-----.----+ . +-----.----+ 1520 |Intra.QOSM| | |Intra.QOSM| 1521 +-----.----+ . +-----.----+ 1522 | . | | |GIST . | 1523 |GIST . |-.-. |C/D- . | 1524 |C/D- . | |mode . | 1525 |mode .....|....................................... | 1526 +----------+ GIST-Query +----------+ 1527 | IP | | IP | 1528 |Forwarding| Data path |Forwarding| 1529 --------------------------------------------------------------> 1530 +----------+ +----------+ 1531 Edge QNE1 Edge QNE3 1533 ---------> = Data flow (and direction) 1534 .........> = GIST D-mode messages (and direction) 1535 <<######>> = GIST C-mode messages (bidirectional) 1537 Figure 4: discovering a downstream off-path node from an upstream 1538 off-path node. 1540 This off-path discovery mechanism can be applied to discover peer 1541 off-path devices in different networks, as illustrated in Figure 4, 1542 and to discover peer off-path devices inside the same network. The 1543 later may be used in a scenario in which a domain uses distributed 1544 inter-domain QNEs -- a set of inter-domain QNEs each controlling a 1545 subset of edge nodes. 1547 5.2.2 QoS-NSLP Analysis 1549 In the example illustrated in Section 5.2.1, the inter-domain QNEs 1550 implement the InterDomain-QoSM by signaling QoS between domains, 1551 while QoS-NSLP [QoS-NSLP] is used to support an IntraDomain-QoSM. 1552 This is, the inter-domain QNE may trigger a specific ingress device, 1553 which may use QoS-NSLP to signal the needed QoS among all QoS-NSLP 1554 aware routers inside the domain from the triggered ingress device 1555 until the indicated egress device. 1557 However, the use of QoS-NSLP to signal between ingress and egress 1558 devices is not mandatory for the InterDomain-QoSM. Actually, the 1559 InterDomain-QOSM makes no assumptions about the implementation 1560 mechanisms of the IntraDomain-QoSM. That is to say intra-domain 1561 resources may be controlled in a centralized or distributed way, 1562 based on NSIS protocols or not. Nevertheless, a distributed 1563 implementation of the IntraDomain-QoSM based on QoS-NSLP signalling 1564 over several intra-domain QNEs is more close to the work being done 1565 in NSIS (independent from if the intra-domain signalling is done 1566 on-path or off-path based on the use of a new off-path MRM also 1567 inside a domain). 1569 In any case, the InterDomain-QoSM makes use of the messages, objects 1570 and procedures defined by QoS-NSLP for signaling exchanges between 1571 inter-domain QNEs. However, the InterDomain-QoSM depends on the GIST 1572 to discover the peer inter-domain QNEs in adjacent domains. This 1573 means that QoS-NSLP is used to signal between inter-domain QNEs, over 1574 a set of NSIS message associations, as described in section 5.1. 1576 Moreover, the SLS parameters and QoS control information required for 1577 the inter-domain QoS interactions are specified by using/extending 1578 the QSPEC template in [NSIS-QSPEC]. 1580 5.3 The support of ITU-T RACF end-to-end QoS control via the 1581 InterDomain-QOSM 1583 The inter-operator-domain communications for e2e QoS control in the 1584 ITU-T functional architecture are discussed in section 10 of 1585 [Y.RACF], where two ways of passing the QoS requirements for a given 1586 service over e2e paths. For the RACF Push resource control mode, the 1587 QoS requirements for a given service are proposed to be passed over 1588 the e2e path through the application layer signaling or through the 1589 Ri reference point; whereas, for the RACF Pull resource control mode, 1590 the QoS requirements for a given service are proposed to be passed 1591 over the e2e path through path-coupled QoS signaling (e.g., NSIS). 1593 The InterDomain-QoSM will be used to fulfill the Ri reference point 1594 between peer inter-domain PD-FE at adjacent operator domains. This 1595 inter-domain QoS control can be done based on two scenarios: for the 1596 RACF Push mode, when the application layer signaling is not available 1597 or incapable to carry the e2e QoS requirements, the CPE requests QoS 1598 to the SCF or it is the SCF that handle QoS requests on behalf of the 1599 CPEs and, then the e2e QoS requirements are forwarded to the 1600 inter-domain PD-FE. In another scenario (the RACF Pull mode), the CPE 1601 requests QoS via a path-coupled QoS signalling in the transport 1602 stratum. In any case the inter-domain QoS control is due by the 1603 InterDomain-QoSM via the NSIS path-decoupled message association 1604 created over the Ri reference point of the PD-FE (see section 5.2.1 - 1605 GIST analysis). That is to say, the path-coupled signaling is only 1606 used between CPEs and the access network and inside each network 1607 being the inter-domain signaling done by InterDomain-QoSM via Ri 1608 reference point. This usage of the path-coupled signalling, means 1609 that each network can use a different path-coupled signaling 1610 implementation and different NSIS intra-domain QOSM(s), since that 1611 signalling is never used end-to-end. 1613 6. InterDomain-QOSM, Detailed Description 1615 6.1 Additional QSPEC Parameters for End-to-End QoS Control By the 1616 InterDomain-QOSM 1618 TBD 1620 6.2 The Operation Modes of the InterDomain-QOSM 1622 To address the scalability issue for deploying the InterDomain-QOSM 1623 in real IP network domains, three possible ways to implement the 1624 Inter-domain QNE (see Section 4.3) are provided: fully centralized, 1625 fully distributed and hybrid. Moreover, there are two resource 1626 control scenarios in the ITU-T RACF functional architecure: RACF Push 1627 and Pull resource control modes in [Y.RACF]. Thus, to apply the 1628 Interdomain-QOSM to fully fulfill the e2e QoS control in the ITU-T 1629 RACF architecture, the Interdomain-QOSM will have to support 6 1630 possible operation combinations: fully centralized, fully distributed 1631 and hybrid under the RACF Push and Pull modes, respectively. 1633 6.2.1 Operation mode 1: fully centralized 1634 In this operation mode, a single off-path NSIS inter-domain PD-FE 1635 will exist at an AS that deploys the InterDomain-QOSM to take care 1636 of all the inter-domain QoS interaction requests from/to the domain 1637 (see Figures 1 and 4 at 1638 http://www.dcs.qmul.ac.uk/~jianzhang/Interdomain-QOSM%20Mapping.pdf). 1639 Moreover, a centralized or distributed intra-domain PD-FE will also 1640 exist at each AS and be responsible for the intra-domain QoS control 1641 at the AS. The intra-domain PD-FE can be implemented by a NSIS 1642 intra-domain QOSM (for RACF Pull mode) or any intra-domain QoS 1643 control mechanisms (for RACF Push mode) and it will interact with the 1644 inter-domain PD-FE via the ITU-T RACF Rd reference point. The 1645 off-path NSIS inter-domain PD-FE has to support the NSIS protocol 1646 suites and implement the Interdomain-QOSM and the PE-FE at the 1647 boundary of each AS must also support the GIST off-path Message 1648 Routing Method (MRM) to help the discovery of the peer NSIS 1649 inter-domain PD-FE at adjacent operator domains and transport the 1650 Interdomain-QOSM messages (i.e, implementing the ITU-T RACF Ri 1651 reference point). 1653 Under the RACF Push mode, the CPE is non-NSIS aware and the QoS 1654 requests will be triggered by the SCF to the PD-FE(s) at the source 1655 domain; at the subsequent operator domains, the QoS requests will be 1656 triggered by the inter-domain QoS interactions. Whereas, under the 1657 RACF Pull mode, the CPE is NSIS aware and acts as the QNI to trigger 1658 the QoS request at the source domain; at the subsequent operator 1659 domains, the QoS requests will first be triggered by the inter-domain 1660 QoS interactions and then the on-path NSIS aware nodes will send 1661 their requests to the intra-domain QOSM(s) for the intra-domain QoS 1662 control. 1664 6.2.2 Operation mode 2: fully distributed 1666 In this operation mode, the NSIS inter-domain PD-FE will exist at 1667 each edge node of an AS that deploys the InterDomain-QOSM to take 1668 care of the inter-domain QoS interaction requests from/to the domain 1669 via the edge node (see Figures 2 and 5 at 1670 http://www.dcs.qmul.ac.uk/~jianzhang/Interdomain-QOSM%20Mapping.pdf). 1671 Moreover, a centralized or distributed intra-domain PD-FE will also 1672 exist at each AS and be responsible for the intra-domain QoS control 1673 at the AS. The intra-domain PD-FE can be implemented by a NSIS 1674 intra-domain QOSM (for RACF Pull mode) or any intra-domain QoS 1675 control mechanisms (for RACF Push mode). For the case that the 1676 intra-domain PD-FE is also distributed at each edge node of the AS, 1677 the inter-domain and intra-domain PD-FEs will interact via the RACF 1678 Rd interface implemented internally, otherwise, it will interact with 1679 the inter-domain PD-FE via the external RACF Rd interface. 1681 Each edge node at the AS will have to implement the Interdomain-QOSM 1682 to take care of the inter-domain QoS interactions at its edge node. 1683 Under the RACF Push mode, the CPE is non-NSIS aware and the QoS 1684 requests will be triggered by the SCF to the PD-FE(s) at the source 1685 domain; at the subsequent operator domains, the QoS requests will be 1686 triggered by the inter-domain QoS interactions. Whereas, under the 1687 RACF Pull mode, the CPE is NSIS aware and acts as the QNI to trigger 1688 the QoS request at the source domain; at the subsequent operator 1689 domains, the QoS requests will first be triggered by the inter-domain 1690 QoS interactions and then the on-path NSIS aware nodes will send 1691 their requests to the intra-domain QOSM(s) for the intra-domain QoS 1692 control. 1694 6.2.3 Operation mode 3: hybrid 1696 In this operation mode, a number of off-path NSIS inter-domain PD-FEs 1697 will exist at an AS, and each of them will deploy the 1698 InterDomain-QOSM and be responsible for handling the inter-domain QoS 1699 interaction requests from/to a set of edge QNEs (see Figs 3 and 6 at 1700 http://www.dcs.qmul.ac.uk/~jianzhang/Interdomain-QOSM%20Mapping.pdf). 1701 Normally the set of edge QNEs assigned to different inter-domain 1702 PD-FEs should be disjoint to reduce the synchronization requirement 1703 between different NSIS inter-domain PD-FEs. 1705 Moreover, a centralized or distributed intra-domain PD-FE will also 1706 exist at each AS and be responsible for the intra-domain QoS control 1707 at the AS. The intra-domain PD-FE can be implemented by a NSIS 1708 intra-domain QOSM (for RACF Pull mode) or any intra-domain QoS 1709 control mechanisms (for RACF Push mode). For the case that the 1710 intra-domain and inter-domain PD-FEs are located at the same node of 1711 the AS, they will interact via the RACF Rd interface implemented 1712 internally, otherwise, they will interact with the external RACF Rd 1713 interface. 1715 Every off-path NSIS inter-domain PD-FE should support the NSIS 1716 protocol suites and implement the Interdomain-QOSM and the edge PE-FE 1717 at the AS must also support the GIST off-path Message Routing Method 1718 (MRM) to help the discovery of the peer NSIS inter-domain PD-FE at 1719 adjacent operator domains and transport the Interdomain-QOSM messages 1720 (i.e, implementing the ITU-T RACF Ri reference point). Furthermore, 1721 the off-path NSIS inter-domain PD-FEs within the AS can interact with 1722 each other via the RACF Rd reference point. 1724 Under the RACF Push mode, the CPE is non-NSIS aware and the QoS 1725 requests will be triggered by the SCF to the PD-FE(s) at the source 1726 domain; at the subsequent operator domains, the QoS requests will be 1727 triggered by the inter-domain QoS interactions. Whereas, under the 1728 RACF Pull mode, the CPE is NSIS aware and acts as the QNI to trigger 1729 the QoS request at the source domain; at the subsequent operator 1730 domains, the QoS requests will first be triggered by the inter-domain 1731 QoS interactions and then the on-path NSIS aware nodes will send 1732 their requests to the intra-domain QOSM(s) for the intra-domain QoS 1733 control. 1735 6.3 Message Format 1737 TBD 1739 6.4 InterDomain-QOSM Node State Management 1741 TBD 1743 6.5 InterDomain-QOSM Operations and Sequences of Events 1745 TBD 1747 6.5.1 Basic unidirectional operation 1749 TBD 1751 6.5.1.1 Successful reservation 1753 TBD 1755 6.5.1.2 Unsuccessful reservation 1757 TBD 1759 6.5.1.3 Refresh reservation 1761 TBD 1763 6.5.1.4 Modification of reservation 1765 TBD 1767 6.5.1.5 InterDomain release procedure 1769 TBD 1771 6.6 Inter-domain QNE Discovery and Transport of InterDomain-QOSM 1772 Messages 1774 TBD 1776 6.6.1 Requirements of InterDomain-QOSM to the Underlying Path-coupled 1777 NTLP 1779 TBD 1781 6.6.2 Requirements of InterDomain-QOSM to the Underlying path-decoupled 1782 NTLP 1784 TBD 1786 6.7 Handling of Additional Errors 1788 TBD 1790 7. Security Consideration 1792 The operation mode of the InterDomain-QOSM might produce some 1793 security concerns and this will be discussed and clarified later. 1795 8. IANA Considerations 1797 This section provides guidance to the Internet Assigned Numbers 1798 Authority (IANA) regarding registration of values related to the 1799 QSPEC template, in accordance with BCP 26 RFC 2434 [RFC2434]. 1801 The InterDomain-QOSM requires a new IANA registry. In addition, the 1802 new QSPEC parameters which will be defined in the next version of 1803 this document, need to be assigned the QSPEC Parameter ID for them. 1805 9. Open Issues 1807 This section includes the issues that we will do or we think should 1808 be analysed in the next version of the draft. Currently, the open 1809 issues include: 1811 o All the missing subsections in Section 6 will be done in the next 1812 version of the draft. 1814 o The detailed analyses of implementing the relevant ITU-T RACF 1815 reference points to support e2e QoS control by using NSIS will be 1816 given in the next version of the draft. The QSPEC parameters 1817 necessary for the implementation will also be given in the next 1818 version. 1820 o The analyses for how to adapt the NSIS QOSMs to apply to the ITU-T 1821 RACF functional architecture in this document could be moved to a 1822 new draft for further comprehensive studies so that the current 1823 NSIS QOSM drafts, such as [RMD-QOSM] and [Y.1541-QOSM], need not 1824 do the same analysis again. 1826 o The mapping between the ITU-T RACF entities and the NSIS entities 1827 for e2e QoS control need more stuides and discussion with the 1828 ITU-T and NSIS people and could be refined in the next version. 1830 o The application of the Interdomain-QOSM to the e2e QoS control in 1831 the ITU-T RACF functional architecture also needs more studies and 1832 discussions. 1834 o The support of the automatic inter-domain adjustment in the 1835 scenario of mobile end customers. 1837 10. Acknowledgments 1839 The authors would like to thank John Loughney and Robert Hancock for 1840 the helpful suggestions on this InterDomain-QOSM work. 1842 11. References 1844 11.1 Normative References 1846 [GIST] Schulzrinne, H., and Hancock, R., "GIST: General Internet 1847 Signaling Transport", work in progress. 1849 [QoS-NSLP] Manner, J., Karagiannis, G., McDonald, A. and Bosch, S., 1850 "NSLP for Quality-of-Service signaling", work in progress. 1852 [RMD-QOSM] Bader, A., et. al., "RMD-QOSM - The Resource Management 1853 in Diffserv QOS Model," work in progress. 1855 [NSIS-QSPEC] Ash, J., et. al., "QoS-NSLP QSPEC Template," work in 1856 progress. 1858 11.2 Informative References 1860 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1861 Requirement Levels", RFC 2119, March 1997. 1863 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 1864 Services," RFC 2210, September 1997. 1866 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1867 IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 1869 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. 1870 and W. Weiss, "An Architecture for Differentiated Services", RFC 1871 2475, December 1998. 1873 [RFC2638] Nichols K., Jacobson V., Zhang L. "A Two-bit 1874 Differentiated Services Architecture for the Internet", RFC 2638, 1875 July 1999. 1877 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 1878 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 1879 2005. 1881 [DCPEL-requirements] Mendes, P., and Nichols, K., "Requirements for 1882 DiffServ Control Plane Elements", draft-mendes-dcpel-requirements-00 1883 (work in progress), January 2006. 1885 [draft-hancock-nsis-pds-problem-03] Hancok, R., Kappler, C., 1886 Quittek, J., Stiemerling, M., "A Problem Statement for 1887 Partly-Decoupled Signalling in NSIS", 1888 draft-hancock-nsis-pds-problem-03, (work in progress), February 2006. 1890 [Y.RACF] ITU-T Recommendation Y.2111, "Resource and admission 1891 control functions in Next Generation Networks", 2006. 1893 [Y.2012] ITU-T Recommendation Y.2012, "Functional requirements 1894 and architecture of the NGN". 1896 [Y.1541-QOSM] Ash, J., et. al., "Y.1541-QOSM -- Y.1541 QoS Model for 1897 Networks Using Y.1541 QoS Classes," work in progress. 1899 12. Authors' Addresses 1901 Jian Zhang 1902 Dept. of Computer Science 1903 Queen Mary, Univ. of London 1904 Mile End, London E1 4NS 1905 UK 1906 Email: jian.zhang@dcs.qmul.ac.uk 1908 Edmundo Monteiro 1909 Dept. of Informatics Engineering 1910 Univ. of Coimbra 1911 Polo II - Pinhal de Marrocos 1912 3030-290 Coimbra, Portugal 1913 Email: edmundo@dei.uc.pt 1915 Paulo Mendes 1916 Future Networking Laboratory 1917 NTT DoCoMo Euro-Labs 1918 Landsbergerstr 312 1919 80687 Munich 1920 Germany 1922 Phone: +49 89 56824 226 1923 Email: mendes@docomolab-euro.com 1924 URI: http://www.docomolab-euro.com/ 1926 Georgios Karagiannis 1927 University of Twente 1928 P.O. Box 217 1929 7500 AE Enschede, The Netherlands 1930 Email: g.karagiannis@ewi.utwente.nl 1932 Jorge Andres-Colas 1933 Advanced Networks Planning 1934 Telefonica I+D 1935 Emilio Vargas, 6 1936 28043 Madrid, Spain 1937 Email: jorgeac@tid.es 1939 Intellectual Property Statement 1941 The IETF takes no position regarding the validity or scope of any 1942 Intellectual Property Rights or other rights that might be claimed to 1943 pertain to the implementation or use of the technology described in 1944 this document or the extent to which any license under such rights 1945 might or might not be available; nor does it represent that it has 1946 made any independent effort to identify any such rights. Information 1947 on the procedures with respect to rights in RFC documents can be 1948 found in BCP 78 and BCP 79. 1950 Copies of IPR disclosures made to the IETF Secretariat and any 1951 assurances of licenses to be made available, or the result of an 1952 attempt made to obtain a general license or permission for the use of 1953 such proprietary rights by implementers or users of this 1954 specification can be obtained from the IETF on-line IPR repository at 1955 http://www.ietf.org/ipr. 1957 The IETF invites any interested party to bring to its attention any 1958 copyrights, patents or patent applications, or other proprietary 1959 rights that may cover technology that may be required to implement 1960 this standard. Please address the information to the IETF at 1961 ietf-ipr@ietf.org. 1963 Full Copyright Statement 1965 Copyright (C) The IETF Trust (2007). 1967 This document is subject to the rights, licenses and restrictions 1968 contained in BCP 78, and except as set forth therein, the authors 1969 retain all their rights. 1971 This document and the information contained herein are provided on an 1972 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1973 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1974 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1975 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1976 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1977 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.