idnits 2.17.1 draft-buchli-nsis-req-00.txt: -(83): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(219): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(223): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(230): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(234): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(236): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(399): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(520): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(615): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(755): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(756): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(785): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == There are 12 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 3. Overview of signaling requirements' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 696 instances of too long lines in the document, the longest one being 15 characters in excess of 72. ** The abstract seems to contain references ([4], [5], [6], [7], [8], [9], [10], [11], [13], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- The document date (February 2002) is 8105 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 63 looks like a reference -- Missing reference section? '8' on line 1007 looks like a reference -- Missing reference section? '10' on line 173 looks like a reference -- Missing reference section? '9' on line 746 looks like a reference -- Missing reference section? '11' on line 334 looks like a reference -- Missing reference section? '5' on line 335 looks like a reference -- Missing reference section? '4' on line 699 looks like a reference -- Missing reference section? '7' on line 667 looks like a reference -- Missing reference section? '13' on line 699 looks like a reference -- Missing reference section? '6' on line 726 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NSIS Working Group Maarten Buchli 2 Internet Draft Danny Goderis 3 draft-buchli-nsis-req-00.txt Sven Van den Bosch 4 Expires: August 2002 Juan-Carlos Rojas 5 Stefan Custers 6 Alcatel 7 February 2002 9 QoS signaling requirements, interfaces and architecture 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This draft gives evidence for the existence of different QoS 34 signaling interfaces based on a reference architecture that is 35 derived from two use cases. The main purpose is to refine the 36 requirements for the signaling interface that is being considered in 37 scope of NSIS. 39 The two use cases are the interconnection of PSTN trunking gateways 40 over an IP core network and the connection of an UMTS access network 41 to an IP core network. From these use cases a QoS reference 42 architecture is derived containing QoS Initiator (QI) and QoS 43 Controller (QC) entities, as defined in draft-brunner-nsis-req- 44 00.txt. The architecture encompasses the inter-connection of any 45 type of access networks over an IP DiffServ core network and does 46 not require any upgrade of the existing (and deployed) DiffServ 47 routers. 49 The proposed architecture identifies four relevant signaling 50 interfaces between functional entities. We believe the interface 51 between QI and QC to be of particular interest in the context of 52 QoS signaling architecture, interfaces February 2002 53 and requirements 55 NSIS. Based on our architecture, the signaling protocol over this 56 interface can be kept simple. 58 Conventions used in this document 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 62 this document are to be interpreted as described in RFC-2119 [1]. 64 Table of Contents 66 Status of this Memo................................................1 67 Abstract...........................................................1 68 Conventions used in this document..................................2 69 1. Introduction....................................................3 70 2. Terminology.....................................................4 71 3. Overview of signaling requirements..............................5 72 4. Use cases.......................................................6 73 4.1 PSTN trunking gateway scenario.................................7 74 4.2 UMTS access scenario...........................................8 75 5. General architecture............................................9 76 5.1 Signaling architecture........................................10 77 5.2 Protocol interfaces...........................................13 78 5.2.1 Host to QoS Initiator.......................................13 79 5.2.2 QoS Initiator to Access Gate................................13 80 5.2.3 QoS Initiator to QoS Controller (NSIS)......................14 81 5.2.4 QoS Controller to Network Management System (NMS)...........14 82 5.3 Evolution scenario............................................15 83 6. Requirements on the QoS Initiator�to-QoS Controller interface..15 84 6.1 Signaling requirements........................................15 85 6.2 Requirements on protocol content..............................17 86 6.3 Open issues...................................................18 87 7. Security Considerations........................................18 88 8. Conclusions....................................................19 89 9. Acknowledgment.................................................20 90 References........................................................20 91 Author's Addresses................................................21 92 QoS signaling architecture, interfaces February 2002 93 and requirements 95 1. Introduction 97 The task of the NSIS working group is to specify general QoS 98 signaling requirements and possibly propose a new protocol or 99 modifications to existing ones. 101 Two use cases are presented in this draft to explore such QoS 102 signaling requirements. The first case is a PSTN trunking gateway 103 interconnection scenario. The second case is the interconnection 104 between a UMTS access network and an IP core network. 106 In addition to the NSIS requirements draft [8], and based on the two 107 use cases, we introduce a QoS signaling reference architecture and 108 identify the different protocol interfaces that are in place. An 109 important observation is that several QoS signaling interfaces may 110 exist and that their requirements are of a different nature. We 111 identify four relevant signaling interfaces, which may be involved 112 in QoS provisioning. The most important being the interface between 113 the QoS Initiator (QI) and the QoS Controller (QC) as also described 114 in [8]. 116 The basic requirements of the QI-to-QC interface are described and 117 compared with the requirements as expressed in [8]. In particular it 118 must be possible to gradually deploy the NSIS QoS solution on top of 119 existing networks. This high-level requirement yields concrete 120 consequences for the QoS signaling in as well access as core 121 networks. 123 First it is noted that access networks (UMTS, Packet cable, ADSL 124 access, etc) may use their own specific QoS signaling protocols for 125 quite some time. Moreover, in current networks, QoS signaling in 126 access may be very technology dependent, while for IP core networks 127 we need definitely a technology independent protocol. This may 128 involve mapping requirements and the draft discusses particular 129 features of this mapping and the actual place in the network where 130 this mapping can take place. 132 Thus, in a first phase, access networks may still use their own QoS 133 signaling, which is mapped onto a generic NSIS protocol by an entity 134 at the edge of the network. However, in a second phase the NSIS 135 protocol may also be supported by the end-host and used in the 136 access networks to setup QoS reservations. Hence, this provides an 137 evolution scenario for gradual deployment of the NSIS protocol in 138 access networks. 140 Second the QoS technology used by most operators in IP core networks 141 is Differentiated Services (DiffServ). It should be possible to 142 deploy the QoS solution onto these networks without upgrading the 143 routers. This may require the compatibility of in-band and out-of- 144 band signaling because, for pure DiffServ networks, the QoS 145 signaling can not be done on the data-path. This draft presents one 146 way of doing this for scenarios involving one IP core and several 147 access networks. It presents a two-step approach in order to support 148 QoS signaling architecture, interfaces February 2002 149 and requirements 151 end-user Quality of Service (QoS). First step is to pre-provision 152 bandwidth pipes in the transport network defined by means of e.g. 153 DiffServ Service Level Specifications (SLS). These are e.g. IP VLLs 154 with statistical QoS guarantees, such as edge-to-edge delay and 155 packet loss bounds, for traffic aggregates. The second step is then 156 to admit (micro)-flows in the bandwidth pipes based on the user QoS 157 request. As a consequence of this two-step approach, the dynamic 158 per-flow QoS signaling can be simplified and kept out of the 159 (DiffServ) routers. 161 The outline of the draft is as follows. 162 The terminology is defined in section 2. Section 3 summarizes the 163 main signaling requirements for the QI-to-QC interface and makes the 164 comparison with [8]. Section 4 presents the two use cases while 165 section 5 draws conclusions and proposes a more general signaling 166 architecture. The requirements on the signaling protocol and the 167 parameter groups are discussed in section 6. The conclusions are 168 presented in the final section. 170 2. Terminology 172 The terminology used in this draft is in line with the DiffServ 173 terminology [10] and the NSIS requirements draft from Brunner et al. 174 [8]. The relevant terminology is repeated here and some new terms 175 are introduced. See e.g. figure 3 for a position of the relevant 176 functional entities in the network. 178 Host: end-user entity where the application is running that requires 179 QoS to another host or server. The end-user service, which should be 180 supported end-to-end by the network, is supposed to be a dynamic QoS 181 demanding service such as voice, video, etc. 183 Access Gate (AG): functional entity that enforces QoS policy by 184 policing and traffic conditioning per microflow. 185 In this context, a microflow is understood as the IP packet flow 186 carrying the payload of the actual service to be supported in the 187 network (e.g. voice) and may be formally defined as e.g. the IntServ 188 5-tuple. A microflow is always understood to be end-to-end, i.e. 189 host-to-host. 191 Edge router (ER): router at the edge of a Differentiated Services 192 (DiffServ) capable network. It is a common DiffServ edge router 193 enforcing QoS policy by policing and traffic conditioning traffic 194 aggregates and DiffServ Service Level Specifications SLS, see e.g. 195 [8][9]. 196 According to DiffServ an SLS is "a set of technical parameters and 197 their values, which together define the service, offered to a 198 traffic stream by a (DiffServ) transport network". In this context, 199 an SLS is the technical specification of a long-lived QoS service 200 such as an IP VLL or an assured rate bandwidth pipe. The 201 geographical scope of an SLS is single domain, i.e. edge-to-edge. 202 The edge-to-edge statistical QoS guarantees, such as maximum delay, 203 QoS signaling architecture, interfaces February 2002 204 and requirements 206 are provided to the in-profile packets of the traffic aggregate 207 stream defined by the SLS. For a detailed description of SLSs, see 208 [9]. For its support and implementation in a DiffServ network by 209 means of Per Hop Behaviors (PHB) and Per Domain Behaviors (PDB), see 210 [8]. 212 Network Management System (NMS): common network and element 213 management platform, configuring the edge and core routers of a 214 single IP network by e.g. the SNMP or COPS protocol. In this context 215 the NMS is the functional entity responsible for the configuration 216 and provisioning of long-lived QoS services, which are technically 217 described by SLSs. 219 QoS Controller (QC): the functional entity that is �responsible for 220 interpreting the signaling carrying the end-user service QoS 221 parameters, optionally inserting/modifying the parameters according 222 to local network QoS management policy, and invoking local QoS 223 provisioning mechanisms� [8]. More specifically in this context the 224 QC performs per-microflow admission control for a single IP domain. 225 The QC manages or "owns" (part of) the pre-provisioned network 226 resources, which are described by a set of Service Level 227 Specifications. These SLSs provide statistical edge-to-edge QoS 228 guarantees. 230 QoS Initiator (QI): the functional entity �generating the QoS 231 request for traffic flow(s) based on user or application 232 requirements and signaling them to the network as well as invoking 233 local QoS provisioning mechanisms. This can be located in the end 234 system, but may reside elsewhere in network� [8]. This draft takes 235 the same viewpoint and discusses use cases for different locations 236 of the QI. The QI is in any case an �NSIS-speaker�, i.e. it 237 implements the (to-be-defined) NSIS protocol and signals a QoS 238 request to the QC. In case the QI is situated at the network edge 239 (access-core), the QI should perform a mapping from the (access 240 technology dependent) user QoS request to the QoS request towards 241 the QC. 243 3. Overview of signaling requirements 245 The main purpose of this document is to derive requirements for NSIS 246 protocol interfaces that are identified from use cases. In this 247 section, we give an overview of the requirement list. The 248 requirements are primarily derived for the QI-QC interface but it 249 seems advantageous that they be reused (partly) for the QC-QC 250 interface. Each requirement will be put into context and clarified 251 in subsequent sections. 252 Apart from the generic requirements that the protocol should be fast 253 and lightweight, it 255 - must support both in-band and out-of-band signaling 256 - must support priority 257 - must allow notification of (QoS) failure 258 QoS signaling architecture, interfaces February 2002 259 and requirements 261 - must decouple the messaging mechanism from the information being 262 signaled 263 - should be independent of core transport technology 264 - should avoid extra complexity due to (optional) multicast support 265 - should be optimized for interactive multimedia services 266 - should support different service levels for a service class 267 - the mobility aspects should have no impact on the NSIS protocol 269 Two considerations are left as open issues: 270 - the protocol may be stateful or stateless 271 - it should consider allowing grouping of microflows 273 Related work in the NSIS group [8] states that: 274 "Specific mechanisms for QoS provisioning within a domain/subdomain 275 are not considered. It should be possible to exploit these 276 mechanisms optimally within the end to end context. Consideration of 277 how to do this might generate new requirements for NSIS however." 279 The two-step approach for which requirements are documented in this 280 draft achieves this goal of exploiting the QoS intra-domain 281 provisioning solution. In this way, it inherently addresses some of 282 the requirements in [8]: 283 - it avoids duplication of sub-domain signaling 284 - it provides independence of the underlying technology 285 - it reuses existing QoS technologies and does not impact existing 286 infrastructure during deployment 287 - it decomposes the path which is essential to provide mobility 289 It also emphasizes some other requirements in [8]: 290 - QoS signaling and QoS Controllers must not be constrained to be in 291 the data path 292 - the network is expected to handle 2 QoS granularities: per-flow 293 and per-trunk or per-class 295 Note, however, that an important difference is that per-flow 296 signaling can be considered in the core because the required amount 297 of signaling information is strongly reduced by the two-step 298 approach. 300 Finally, it allows to relax some of the signaling requirements in 301 [8]: 302 - the info that is passed as signaling content does not have to be 303 universal. It suffices that it can be translated by each domain in 304 the appropriate local QoS. 305 - communication between QoS administration functionality (e.g. 306 traffic engineering) and QI is not needed. 307 - it is not necessary to map opaque application-dependent 308 information in the message. The QI provides a mapping function and 309 the end-host to end-host alignment can be obtained at the 310 application layer. 312 4. Use cases 313 QoS signaling architecture, interfaces February 2002 314 and requirements 316 In [8] the concepts of QoS Initiator (QI) and QoS Controller (QC) 317 were introduced. Here we analyze these functions for two concrete 318 use cases. In 3.1 a scenario of interconnecting PSTN trunking 319 gateways is discussed. In this case the QI and QC are integrated in 320 one entity. In 3.2 a possible scenario is shown for providing end- 321 to-end QoS with UMTS access networks. In this case the QI and QC are 322 two separate entities. In both cases the QI function is not part of 323 the end-host. 325 4.1 PSTN trunking gateway scenario 327 This section discusses an example scenario where a number of PSTN 328 trunking gateways are interconnected by a QoS enabled IP transport 329 network. The PSTN consists of a network carrying 64 kb/s circuits. 330 It is connected to the Edge Router (ER) of the IP network by a Media 331 GateWay (MG). The PSTN call signaling is transported over a separate 332 SS7 signaling network. This signaling network is connected to a 333 Media GateWay Controller (MGC). In the IP network the SS7 signaling 334 is carried with the ISUP/SIGTRAN protocol [11]. The MGC controls the 335 MG with the Megaco protocol [5]. 337 In figure 1 the example scenario is shown for two media gateways, 338 i.e. trunking gateways. The Network Management System (NMS) is the 339 entity that is able to provision bandwidth pipes in the transport 340 network. 342 +-------------+ ISUP/SIGTRAN +-----+ +-----+ 343 | SS7 network |---------------------| MGC |--------------| SS7 | 344 +-------------+ +-------+-----+---------+ +-----+ 345 : / : \ 346 : / : \ 347 : / +--------:----------+ \ 348 : MEGACO / / : \ \ 349 : / / +-----+ \ \ 350 : / / | NMS | \ \ 351 : / | +-----+ | \ 352 : : | | : 353 +--------------+ +-----+ | bandwidth pipe (SLS) | +-----+ 354 | PSTN network |--| MG |--|ER|=====================|ER|-| MG |-- 355 +--------------+ +-----+ \ / +-----+ 356 \ QoS network / 357 +-------------------+ 359 Figure 1: PSTN trunking gateway scenario 361 Resources should be pre-provisioned between the media gateways. This 362 is done by establishing a mesh of bandwidth pipes, with strict delay 363 guarantees, between the trunking gateways. The capacity of the pipes 364 should be determined by means of traffic prediction and use of e.g. 365 Erlang calculations in order to provision for a small call blocking 366 probability. 368 QoS signaling architecture, interfaces February 2002 369 and requirements 371 The MGC receives the call setup signaling and should perform per- 372 microflow admission control onto the pre-provisioned resources. The 373 MGC determines the rate of the microflow from the type of codec that 374 is used in the MG. The resource request is a number of 64kb channels 375 and hence, a simple counter to keep track of the used capacity of 376 the bandwidth pipe could be sufficient to perform admission control. 378 The MGC should have the information about the capacity of all 379 bandwidth pipes and should block call setups when the capacity is 380 completely used. The capacity of the bandwidth pipe may be 381 negotiated by an off-line process via paper contracts or by an 382 automated process with an SLS negotiation protocol. 384 In this scenario the MG has the role of Access Gate and the MGC acts 385 as the QoS Controller, performing admission control in the pre- 386 provisioned bandwidth pipes. The QoS Initiator functionality may 387 reside in as well the MG as in the MGC, exchanging information by 388 the MEGACO protocol. This depends on the concrete implementation of 389 MG and MGC. In any case the codec type must be mapped onto a traffic 390 descriptor, which is then used for the admission control of the 391 micro-flow into the bandwidth pipe. 393 In this scenario there may be a separate network provider (owning 394 the transport network and NMS) and voice service provider (owning 395 the MGs and the MGC). Both legal entities have a service level 396 agreement (SLA) and the technical part, i.e. the SLS, describes the 397 mesh of bandwidth pipes between the MGs. The existence of such a SLA 398 is shown as a line between MGC and NMS in figure 1. For more 399 details, see section 5.2 �QC-to-NMS interface�. Remark also that 400 multiple service providers may be active on the same physical 401 network through SLAs with the network provider. 403 4.2 UMTS access scenario 405 The UMTS access scenario is shown in figure 2. The Proxy-Call State 406 Control Function/Policy Control Function (P-CSCF/PCF) is the 407 outbound SIP proxy of the visited domain, i.e. the domain where the 408 mobile user wants to set-up a call. The Gateway GPRS Support Node 409 (GGSN) is the egress router of the UMTS domain and connects the UMTS 410 access network to the Edge Router (ER) of the core IP network. The 411 P-CSCF/PCF communicates with the GGSN via the COPS protocol [4]. The 412 User Equipment (UE) consists of a Mobile Terminal (MT) and Terminal 413 Equipment (TE), e.g. a laptop. 415 +--------+ 416 +----------| P-CSCF |-------> SIP signaling 417 / +--------+ 418 / SIP : 419 : +--------+ NSIS +----------------+ 420 : | PCF |---------| QoS Controller | 421 : +--------+ +----------------+ 422 QoS signaling architecture, interfaces February 2002 423 and requirements 425 : : 426 : : COPS 427 : : 428 +----+ +--------+ +----+ 429 | UE |----------| GGSN |------| ER | 430 +----+ +--------+ +----+ 432 Figure 2: UMTS access scenario 434 In this scenario the GGSN has the role of Access Gate. According to 435 3GPP standardization, the PCF is responsible for the policy-based 436 control of the end-user service in the UMTS access network (i.e. 437 from UE to GGSN). In the current UMTS release R.5, the PCF is part 438 of the P-CSCF, but in UMTS R.6 the interface between P-CSCF and PCF 439 may evolve to an open standardized interface. In any case the PCF 440 has all required QoS information for per-flow admission control in 441 the UMTS access network (which it gets from the P-CSCF and/or GGSN). 442 Thus the PCF would be the appropriate entity to host the 443 functionality of QI, initiating the "NSIS" QoS signaling towards the 444 core IP network. The PCF/P-CSCF has to do the mapping from codec 445 type (derived from SIP/SDP signaling) to IP traffic descriptor. SDP 446 extensions to explicitly signal QoS information [7] are useful to 447 avoid the need to store codec information in the PCF and to allow 448 for more flexibility and accurate description of the QoS traffic 449 parameters. The PCF also controls the GGSN to open and close the 450 gates and to configure per-flow policers, i.e. to authorize or 451 forbid user traffic. 453 The QC is (of course) not part of the standard UMTS architecture. 454 However, to achieve end-to-end QoS a QC is needed such that the PCF 455 can request a QoS connection to the IP network. As in the previous 456 example, the QC could manage a set of pre-provisioned resources in 457 the IP network, i.e. bandwidth pipes, and the QC performs per-flow 458 admission control into these pipes. In this way, a connection can be 459 made between two UMTS access networks, and hence, end-to-end QoS can 460 be achieved. In this case the QI and QC are clearly two separate 461 entities. 462 This use case clearly illustrates the need for an "NSIS" QoS 463 signaling protocol between QI and QC. An important application of 464 such a protocol may be its use in the inter-connection of UMTS 465 networks over an IP backbone. 467 5. General architecture 469 This section proposes a QoS reference architecture generalizing the 470 examples discussed above. The architecture encompasses the inter- 471 connection of any type of (layer two) access networks with an IP 472 backbone and provides QoS to any type of (uni-cast) end-user 473 services (i.e. not only telephony services). The extension of the 474 architecture to multiple IP backbones, with multiple QCs on the end- 475 to-end signaling path, is for further study. 477 QoS signaling architecture, interfaces February 2002 478 and requirements 480 In 4.1 the architecture is presented. The different signaling 481 interfaces are identified and discussed in 4.2. In 4.3 an NSIS 482 evolution scenario is discussed with regard to access networks. 484 5.1 Signaling architecture 486 The reference architecture is shown in figure 3. In this 487 architecture the host requests QoS to the QoS Initiator, which in 488 turn contacts the QoS Controller. The functional entities are shown 489 separately but they may be located in the same physical box. For the 490 sake of simplicity the access networks are presented as single lines 491 between host and Access Gates. 493 +----+ 3 NSIS +----+ NSIS +----+ 494 +-| QI |-------------| QC |-------------| QI |-+ 495 / +----+ +----+ +----+ \ 496 / : : : \ 497 1 / : 4 : SLS IF : \ 498 / : +-----:-----+ : \ 499 / : 2 / +-----+ \ : \ 500 / : / | NMS | \ : \ 501 : : / +-----+ \ : : 502 : : | | : : 503 +------+ +----+ | | +----+ +------+ 504 | Host |----| AG |===|ER|===================|ER|==| AG |---| Host | 505 +------+ +----+ | SLS | +----+ +------+ 506 \ / 507 +---------------+ 508 IP network 510 Figure 3: QoS signaling interfaces and functional entities 512 The architecture identifies at least three roles, i.e. the end-user, 513 the service provider (SP) and the network provider (NP). The NP is 514 the owner of the IP transport equipment. The SP naturally provides 515 end-user services and may or may not be the same entity as the NP. 516 For example the SP could be an UMTS mobile operator, leasing 517 transport capacity from an IP Network Provider. The leased capacity 518 inter-connects the Access Gates of the SP and is formalized by a 519 SLSs, which are part of a Service Level Agreement between NP and SP 520 (see section 5.2 �QC-to-NMS interface� for more details). 522 The IP network is DiffServ enabled and therefore capable of 523 providing e.g. IP virtual leased line services. These IP VLLs are 524 specified by DiffServ Service Level Specifications (SLSs), which are 525 the technical part of the SLA. 527 QoS provisioning for individual flows is done by a two-step 528 approach. First step is to provision the capacity in the network by 529 provisioning bandwidth pipes between the ingress and egress points 530 of the IP network by means of SLSs. The second step is to perform 531 QoS signaling architecture, interfaces February 2002 532 and requirements 534 admission control for microflows, i.e. checking whether they still 535 fit in the bandwidth pipe. This admission control function is done 536 by the QoS Controller. 538 The end-user QoS provisioning is described in detail below. Steps 1) 539 and 2) are the pre-provisioning steps for aggregate bandwidth pipes 540 (SLS). Steps 3) and 4) are the per-microflow signaling and admission 541 control steps. 543 1) The QoS Controller requests one or more bandwidth pipes (i.e. 544 virtual leased lines) to the NMS. These bandwidth pipe IP services 545 are specified as SLSs and are requested over an SLS interface or 546 they are negotiated off-line, resulting in a paper contract SLA (in 547 case NP and SP are distinct legal entities). The capacity of the 548 bandwidth pipes is based on some kind of traffic prediction process. 549 The SLSs are stored in databases in the QoS Controller and the NMS. 551 2) The NMS triggers a traffic management process in order to 552 provision the required resources (SLSs) in the network. This may 553 involve reconfiguring one or more network elements. The traffic 554 conditioning block in the edge routers are configured to police the 555 bandwidth pipes. Thus, the traffic is policed on an aggregate base. 557 3) The application (e.g. VoIP) at the end-host, requiring a 558 connection with QoS guarantees to another host or server, signals 559 the QoS request to the QoS Initiator. This signaling may be access 560 technology dependent. The QoS initiator performs the mapping to a 561 technology independent format and signals the QoS request to the QoS 562 Controller by the NSIS protocol. 564 4) The QoS Controller performs admission control for the QoS 565 request. It determines whether sufficient capacity is available in 566 the bandwidth pipes that are defined by the SLSs. The QC will return 567 an admit or reject message. Note, that this step does not involve 568 any configuration of network elements. If the flow has been admitted 569 the QoS Initiator will configure the Access Gate in order to police 570 the microflow. 572 This end-user QoS provisioning approach provides a clear distinction 573 between the provisioning of resources in the transport network and 574 the admission of per-microflow QoS requests. The per-flow QoS 575 signaling can therefore be kept simple since the complexity resides 576 mainly in the resource provisioning in the network and specification 577 of the bandwidth pipes (i.e. SLSs). The provisioning may be static 578 or semi-dynamic. The provisioning is anyhow already in place when 579 the per-flow QoS request arrive. 581 This two-step approach is also visible in the way the traffic is 582 policed. The edge router polices per SLS (bandwidth pipe), and 583 hence, on aggregated traffic. The Access Gate polices per-microflow. 584 The main point here is that the DiffServ network is not (required to 585 be) per micro-flow aware. The DiffServ network operator only 586 QoS signaling architecture, interfaces February 2002 587 and requirements 589 provides QoS guarantees to the (SLA/SLS contracted) long-term 590 aggregate IP services such as IP virtual leased lines. 592 Above we made abstraction of the QoS class and QoS parameters to be 593 signaled. This is discussed in more detail below, but it is 594 instructive to make the following key observation at this point. 596 The main objective is to keep the NSIS signaling protocol between QI 597 and QC as simple as possible, certainly if it should be extended to 598 QC-to-QC inter-domain scenarios. Basically, the information to be 599 signaled is an indication of the QoS class plus a required 600 throughput R (peak rate, token rate, etc) for this particular QoS 601 class. 603 Indeed, provided the QoS class is determined by other means, the 604 required throughput is the main parameter needed by the QC to be 605 able to perform per-flow admission control (i.e. answering the 606 question whether there is still enough capacity in the QoS pipe SLS 607 for admitting e.g. R bandwidth units). We argue that there is no 608 need to signal delay values in the NSIS protocol (interface 3), 609 because the statistical delay bounds are already known and provided 610 by the SLSs. If the QC admits the request for R bandwidth units, 611 then the service will enjoy the delay bounds guaranteed by the SLS. 613 The remaining question is whether this approach can deal with 614 several service (QoS) classes. Suppose for example that there are 615 two QoS classes �Gold� and �Silver�. This could e.g. be used for the 616 offering of voice services with different quality. Another example 617 is to use the Gold QoS class for real-time, delay-sensitive services 618 and the Silver QoS class for elastic, non-delay sensitive services. 619 The latter only require a throughput guarantee. How is this handled 620 in the two-step approach described above? 622 First step: the pre-provisioning. The SLSs describing the bandwidth 623 pipes between the AGs may or may not contain edge-to-edge delay- 624 bound guarantees, corresponding respectively with gold and silver 625 type of services. The Gold and Silver SLSs are realized by 626 respectively the DiffServ Virtual Wire PDB and Assured Rate PDB. 628 Second step: per-flow signaling. Clearly the signaling between host 629 and QI (interface 1) must indicate whether the requested service is 630 gold or silver. The QoS class could also be implicitly derived from 631 the type of service (e.g. voice). Besides the QoS class the user 632 must at minimum also signal the required throughput. 634 In any case, the QI knows the appropriate QoS class and the required 635 throughput. 637 What remains to be decided is what information is signaled between 638 QI and QC. If the same QC is allowed to manage as well Gold as 639 Silver SLSs, then the QI needs to signal the required QoS Class. If 640 a QC only manages one type of SLSs, corresponding with one QoS 641 class, then the QI decides (based on QoS class information) which QC 642 QoS signaling architecture, interfaces February 2002 643 and requirements 645 he has to request resources and signals (only) the required 646 throughput. It is for further study to decide whether both 647 approaches should be possible and able to inter work. 649 5.2 Protocol interfaces 651 5.2.1 Host to QoS Initiator 653 The host to QoS Initiator protocol interface will in most cases 654 depend on the access technology that is used. Due to the variety of 655 access QoS technologies it is to be expected that there will not be 656 one single protocol used over this protocol interface. 658 The QoS Initiator is the entity that triggers the actual QoS setup 659 in the core network. There are several possibilities how the host 660 can trigger the QoS Initiator. 662 1) The QoS Initiator may be integrated in a web-host or an outbound 663 SIP proxy. In the first case the end-user may e.g. use a webpage in 664 order to specify the service he/she would like to use. The web host 665 may then initiate a QoS connection. In the latter case, the host may 666 piggyback the QoS information on the session setup signaling. More 667 precisely, QoS information may be carried in SDP [7] and may be 668 interpreted by the SIP proxy, which will trigger the QoS setup in 669 the network. 671 2) The host uses an access specific layer 2 or 3 protocol. This is 672 e.g. an RSVP-derived protocol for PacketCable networks and the 673 Packet Data Protocol (PDP) for UMTS networks. For xDSL broadband 674 access a mechanism based on ATM Virtual Connections (VC) maybe used. 675 The AG intercepts this QoS signaling and forwards it to the QoS 676 Initiator. In this way the access specific QoS signaling is coupled 677 to the generic QoS setup in the core. 679 This protocol interface is within the scope of NSIS in the sense 680 that existing access signaling protocols should be assessed whether 681 they contain the minimum set of parameters that are required at the 682 QoS Initiator in order to map them to the generic signaling protocol 683 between the QoS Initiator and the QoS Controller. Of course, the 684 first step should be to specify this minimum set of parameters 685 required for the generic signaling protocol. 687 5.2.2 QoS Initiator to Access Gate 689 The protocol interface between the QI and the AG is used to 690 configure the AG such that it correctly installs per-flow policers. 691 In order to configure the policer a flow identifier is required 692 (e.g. five-tuple) and a traffic descriptor (e.g. token bucket 693 parameters). Optionally an indication for DiffServ packet marking 694 may be signaled (i.e. the DiffServ Code Point value). 696 QoS signaling architecture, interfaces February 2002 697 and requirements 699 This protocol interface may be e.g. COPS [4] or a future MIDCOM [13] 700 protocol. Hence, this protocol interface is outside the scope of 701 NSIS. 703 5.2.3 QoS Initiator to QoS Controller (NSIS) 705 The protocol interface between the QoS Initiator and the QoS 706 Controller is discussed in section 6. This protocol is generic in 707 the sense that is technology independent. The QI is responsible for 708 mapping the access technology dependent user QoS request on this 709 protocol. 711 This protocol interface is certainly within the scope of NSIS. 713 5.2.4 QoS Controller to Network Management System (NMS) 715 A Service Level Agreement (SLA) is a legal agreement between a 716 customer and a provider. The technical part of the SLA is called a 717 Service Level Specification (SLS). The SLS specifies capacity and 718 QoS guarantees between one or more ingress and egress points of a 719 network. The SLS also specifies the availability and reliability of 720 the bandwidth service. The services specified in an SLS usually stay 721 in place for a long duration (e.g. days or months) and their setup 722 (time between the request of the service from the customer and the 723 availability) will not be real-time. The resources needed to fulfill 724 the SLS may be provisioned by means of traffic engineering. In case 725 the IP network is a DiffServ domain, the SLS may be implemented with 726 a PDB [6], e.g. a virtual wire or assured rate PDB. 728 Remark that it is not required for the architecture to automate this 729 interface. Indeed the SLA may be negotiated off-line yielding full 730 static SLS pipes between the Access Gates. It may however evolve to 731 an automated, (to-be-standardized) interface. 733 It is argued that automation and standardization of this SLS 734 interface may yield two key advantages for QoS provisioning. First, 735 it may be used to semi-dynamically negotiate SLSs. For example, if 736 the QoS Controller has to block too many calls between two AGs, the 737 QC may trigger the NMS for more resources on a dynamic basis. 738 Second, the interface may be used to exchange monitoring 739 information. In other words, the NMS may send information about e.g. 740 the current traffic load in the bandwidth pipe that is specified by 741 the SLS. The monitoring information applies to the traffic aggregate 742 SLSs. The QC may use this monitoring information to cross check 743 whether the currently admitted flows (and their throughput) 744 corresponds with the actual traffic load in the bandwidth pipe SLSs. 745 An SLS template has been specified by the European IST-project 746 Tequila [9] in order to facilitate for both functions. 748 Finally note that in figure 3 the SLS interface is shown as a line 749 between the QC and NMS. This is a somewhat simplified view because 750 QoS signaling architecture, interfaces February 2002 751 and requirements 753 in practice, the service provider owning the QC will also dispose of 754 an NMS for managing his equipment (e.g. Access Gates). Thus an SLS 755 interface will rather be implemented between two NMS�s of providers. 756 These NMS�s each have their SLS-database and the QC has access to 757 the NMS of the service provider for executing the policy-based 758 admission control decision. 760 This protocol interface may be in scope of NSIS. 762 5.3 Evolution scenario 764 In the previous section it was assumed that the end-host and QI were 765 two separate entities. This is because each type of access network 766 has its own QoS signaling protocol. The QI couples the access 767 dependent QoS signaling with the generic NSIS signaling in the core 768 (i.e. between QI and QC). Hence, in the short/medium-term the NSIS 769 protocol will be used between the QI and QC and an access technology 770 dependent protocol will be used between the host and the QI. 772 However, once an NSIS protocol has been specified and deployed 773 between QI and QC the access networks may gradually start to adopt 774 NSIS signaling. This implies that the QoS Initiator becomes 775 integrated in the end-host and that the NSIS protocol is also used 776 to setup QoS in the access. Of course, this is an evolution scenario 777 since there is a large installed base of cable, UMTS, xDSL access 778 networks only supporting their own QoS signaling methods. 780 Hence, in the long-term the NSIS signaling protocol may be supported 781 by the end-host (acting as QoS Initiator) and may also be used for 782 QoS signaling in the access network, realizing effectively end-to- 783 end (NSIS) QoS signaling. 785 6. Requirements on the QoS Initiator�to-QoS Controller interface 787 Per-flow QoS requests are mapped onto an SLS. Hence, most of the 788 complexity resides in the specification and provisioning of SLSs. 789 This results in a small set of requirements for the end-user QoS 790 signaling. 792 The QoS Initiator must map the parameters from the host-to-QI 793 interface on the QoS Initiator-to-QoS Controller (NSIS) protocol. 795 This section discusses the signaling requirements and parameter 796 groups that need to be signaled. 798 6.1 Signaling requirements 800 1) The protocol should be lightweight. 801 The required processing power and memory consumption per QoS request 802 should be very small at the QoS Controller such that large amounts 803 of reservation requests can be processed per time unit. The protocol 804 QoS signaling architecture, interfaces February 2002 805 and requirements 807 can be lightweight since the complexity resides in the pre- 808 provisioning of resources by means of SLSs. 810 2) The time to setup a QoS connection should be constrained to one 811 or a few round trip times. 812 This may be necessary for a telephony application because this 813 requires a small call setup delay. Short set up times can be 814 achieved by the two-step approach discussed earlier in this draft, 815 i.e. pre-provision bandwidth pipes by means of SLSs and map flow in 816 these bandwidth pipes. 818 3) Support of priority 819 A minimal support of priority and preemption in case of congestion 820 may be needed in the signaling or in the class description. 822 4) Immediate notification of QoS failure 823 The signaling must allow the users to be notified in case of QoS 824 failure or violation. This notification must be immediate if no 825 local recovery action is taken. The notification should occur when 826 local recovery actions are taken. This requirement is due to the 827 high reliability of the service that needs at least to make the user 828 know in case the QoS is no more guaranteed. 830 5) Both in-band and out-of-band signaling should be supported. This 831 implies that the QoS Initiator and QoS Controller may not be located 832 on the data path of the media flow. See e.g. the UMTS use case. The 833 main advantage of out-of-band signaling is that it avoids the need 834 to upgrade (edge) routers with e.g. the NSIS protocol. Indeed the 835 QCs can be deployed on existing (DiffServ) IP networks. In other 836 words, the network needs only to provision bandwidth pipes (e.g. by 837 means of DiffServ PDBs) while the QoS Controller performs per-flow 838 admission control into these pipes and processes the per-flow (NSIS) 839 signaling. Therefore, the NSIS protocol MUST allow for interworking 840 between both in-band and out-of-band signaling approaches for 841 (gradual) deployment reasons. 843 6) The protocol should be independent of core transport technology 844 as opposed to the access part where the transport and QoS are 845 technology specific. Because of this there is a need for 846 interworking between the QoS in the access network with the QoS in 847 the core network in order to offer end-to-end QoS (i.e. from host to 848 host). 850 7) The signaling information should be independent from the protocol 851 that carries it. 852 Different protocols may be used but the semantics should be the 853 same. The information semantics of the host-to-QI protocol must be 854 mapped on a QI-to-QC protocol. This mapping should take place in the 855 QoS Initiator. This couples the technology dependent signaling 856 protocols in the access with a generic protocol in the core. In 857 order to do this a minimal set of protocol parameters that need to 858 be mapped should be specified. 860 QoS signaling architecture, interfaces February 2002 861 and requirements 863 8) Multicast consideration should not impact the protocol complexity 864 for unicast flows. 865 Multicast support is not considered as a priority, because the 866 targeted interactive multimedia services are mainly unicast. For 867 this reason, if considered in the solution, multicast should not 868 bring complexity in the unicast scenario. 870 9) Effective support of unidirectional reservations 871 Bidirectional reservations are considered as almost impossible in a 872 multidomain configuration due to the unidirectional nature of IP. So 873 bidirectionnal reservations are considered as exceptional if not out 874 of the scope of the protocol. 876 10) the mobility aspects should have no impact on the NSIS protocol 877 A QoS controller should not be affected by mobility issues. In UMTS 878 networks, the users has an anchor point in the GGSN, and thus does 879 not require mobility support. 881 11) Optimization for interactive multimedia services 882 The SIP/H.323 applications are foreseen as the main drivers for end 883 to end QoS solutions. NSIS protocols should be designed in order to 884 be optimised for such traffics. 886 12) Support for different service levels 887 The protocol should be able to support different service levels for 888 a service class. This may, for instance, be used in relation to 889 olympic service classes ("gold", "silver" and "bronze") 891 6.2 Requirements on protocol content 893 The per-flow QoS requests are mapped onto the bandwidth pipe, which 894 is specified by an SLS. These pipes may provide statistical 895 guarantees such as delay and packet loss bounds (depending on the 896 QoS class). In order to invoke per-flow QoS services the only 897 parameter needed is a required rate, a means to identify the data 898 path (mapping on SLS) and eventually a reservation identifier. 900 1) Microflow/reservation description 901 The signaling should allow the request to describe the microflow 902 whose QoS would be guaranteed by giving at least the source and 903 destination IP addresses of the media flow. In case the QC is 904 stateful (per microflow) there may be a need to include a unique 905 reservation identifier (e.g. QI identifier+counter) such that in 906 case of e.g. a tear down message the reservation can be easily 907 identified in the QC. 909 2) Traffic descriptor 910 The required peak rate must be signaled. Optionally the traffic 911 parameters may be expressed in terms of token bucket parameters 912 (similar to the TSpec in RSVP). 914 QoS signaling architecture, interfaces February 2002 915 and requirements 917 6.3 Open issues 919 Two points are left as open issues: 921 1) The protocol may be stateful or stateless. 922 Because of the two-level approach, statefulness needs to be 923 considered both for the pre-provisioned pipes and for the 924 microflows. 925 Clearly, per QoS-class state will need to be maintained by the NMS 926 and the QC; so the (long-term) bandwidth pipe reservations always 927 should be stateful. 929 It is not clear yet whether per microflow state should be maintained 930 by the QC. 931 A stateful approach allows simple implementation of per-flow 932 notification of QoS violation and priority/preemption. This may be 933 feasible in some parts of the network because the two-step approach 934 strongly reduces the state information that needs to be kept. Still, 935 in core networks the number of reservations may be too large to use 936 a stateful approach. A stateful approach can keep hard-state or 937 soft-state. Regardless of the fact whether hard-state or soft-state 938 is used, we see a possible need for explicit refresh/feedback 939 messages that may be used for teardown and/or performance 940 notification (performance level and/or violation). Note that these 941 messages may be per-flow or per-class. 942 A stateless approach may simply decrement/increment capacity on pre- 943 provisioned bandwidth pipes without keeping per-flow state. In this 944 case, the information required for priority support and/or QoS 945 failure notification may be implemented on a per-class basis. Note 946 that in this case, only one setup message should be sent in order to 947 avoid duplicate reservation. Notification messages should be clearly 948 distinguishable as such in order to avoid unnecessary or unwanted 949 allocation or deallocation of resources. 951 2) Grouping of microflows 952 As a consequence of the optimization for the interactive multimedia 953 services, the signaling should allow one unique request for several 954 micro flows having the same origination and destination IP 955 addresses. This is usually the case for multimedia SIP calls where 956 the voice and video micro flows follow the same path. This grouping 957 of requests allows optimization of the QoS processing. Note that 958 this may be detrimental for the call setup time. The use of grouping 959 for microflows may be restricted to teardown and/or notification 960 messages when call setup time is a concern. 962 7. Security Considerations 964 This draft does not identify other security aspects than those 965 described in [8]. 967 QoS signaling architecture, interfaces February 2002 968 and requirements 970 8. Conclusions 972 Based on the use cases of an interconnection scenario of PSTN 973 trunking gateways and an interconnection scenario between a UMTS 974 access network and an IP core network, a general architecture is 975 proposed and the different protocol interfaces where identified. 976 These are between the: 978 1) host and the QoS Initiator, 979 2) QoS Initiator and the Access Gate, 980 3) QoS Initiator and the QoS Controller, 981 4) QoS Controller and the Network Management System. 983 The QoS signaling in the access is usually technology dependent. 984 However, the QoS signaling in the core should be technology 985 independent. The signaling protocol requirements and the parameter 986 groups to be signaled between the QoS Initiator and the QoS 987 Controller where discussed in this draft. 989 The proposed architecture involves two steps in QoS provisioning: 991 1) Provisioning of bandwidth pipes between the ingress and egress 992 points of the IP core network by means of SLSs. This involves 993 configuration of network elements by a Network Management System. 995 2) Admission control of per-flow QoS request in the pre-provisioned 996 bandwidth pipes. In other words, a functional entity in the network 997 checks if the usage of the bandwidth pipe between the ingress and 998 egress points of the network does not exceed the capacity specified 999 in the SLS. Hence, this step does not involve any configuration of 1000 network elements. 1002 The following recommendations are made towards the NSIS working 1003 group: 1005 1) A first priority for NSIS should be the signaling interface 1006 between the QoS Initiator and the QoS Controller. This is completely 1007 in line with the recommendation in [8]. 1009 2) The protocol between the host and the QoS Initiator is access 1010 technology dependent. Therefore, NSIS should study the different 1011 access signaling protocol and assess whether they contain the 1012 minimal set of protocol parameter groups (that have to be defined in 1013 step 1). If not, changes may be proposed for these access signaling 1014 protocols. 1016 3) The SLS interface between the QoS Controller and the NMS is used 1017 for SLS negotiation and for the exchange of SLS monitoring 1018 information. The SLS negotiation may be off-line by means of a paper 1019 contract or may be semi-dynamically signaled. The monitoring aspect 1020 of SLSs is very important and requires that the protocol between the 1021 NMS and the QC is able to exchange such information. Therefore, NSIS 1022 may consider adding this signaling interface to their scope. 1024 QoS signaling architecture, interfaces February 2002 1025 and requirements 1027 9. Acknowledgment 1029 The authors would like to acknowledge Alban Couturier for his 1030 contributions to the QoS signaling requirement section. 1032 The authors would also like to acknowledge Christian Jacquenet, 1033 George Pavlou, Richard Egan, David Griffin, Panos Georgatsos, Pim 1034 Van Heuven, Eleni Mykoniati and other participants in the TEQUILA 1035 project for their input and reflection on this work. 1037 References 1039 1 RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate 1040 Requirement Levels", BCP 14, RFC 2119, March 1997. 1042 2 RFC 2205 Braden, R. et al., "Resource ReSerVation Protocol (RSVP) 1043 - Version 1 Functional Specification", RFC 2205, September 1997. 1045 3 RFC 2223 Postel, J. and Reynolds, J., "Instructions to RFC 1046 Authors", RFC 2223, October 1997. 1048 4 RFC 2748 Boyle, J. et al., "The COPS (Common Open Policy Service) 1049 Protocol", RFC 2748, January 2000. 1051 5 RFC 3015 Cuervo, F. et al., "Megaco Protocol Version 1.0", RFC 1052 3015, November 2000. 1054 6 RFC 3086 Nichols, K. and Carpenter, B., "Definition of 1055 Differentiated Services Per Domain Behaviors and Rules for their 1056 specification", RFC 3086, April 2001. 1058 7 Bos, L. et al., "A Framework for End-to-End User Perceived 1059 Quality of Service Negotiation", draft-bos-mmusic-sdpqos- 1060 framework-00.txt, Work in Progress, November 2001. 1062 8 Brunner, M. et al., "Requirements for QoS Signaling Protocols", 1063 draft-brunner-nsis-req-00.txt, Work in Progress, November 2001. 1065 9 Goderis, D. et al., "Service Level Specification Semantics, 1066 Parameters and negotiation requirements", draft-tequila-sls- 1067 02.txt, Work in Progress, February 2002. 1069 10 Grossman, D., "New terminology for diffserv", , draft-ietf- 1070 diffserv-new-terms-08.txt, work in progress, January 2002. 1072 11 Sidebottom, G. et al., "SS7 MTP3-User Adaptation Layer (M3UA)", 1073 draft-ietf-sigtran-m3ua-12.txt, Work in Progress, Febuary 2002. 1075 QoS signaling architecture, interfaces February 2002 1076 and requirements 1078 12 Westberg, L. et al., "Resource Management in Diffserv (RMD) 1079 Framework", draft-westberg-rmd-framework-01.txt, Work in 1080 Progress, February 2002. 1082 13 IETF Middlebox Communication (MIDCOM) working group, 1083 http://www.ietf.org/html.charters/midcom-charter.html/ 1085 14 IST-Tequila project http://www.ist-tequila.org/ 1087 Author's Addresses 1089 Maarten Buchli 1090 Alcatel 1091 Network Strategy Group 1092 Francis Wellesplein 1 1093 B-2018 Antwerpen Phone: +32 3 2407081 1094 BELGIUM Email: maarten.buchli@alcatel.be 1096 Danny Goderis 1097 Alcatel 1098 Network Strategy Group 1099 Francis Wellesplein 1 1100 B-2018 Antwerpen Phone: +32 3 2407853 1101 BELGIUM Email: danny.goderis@alcatel.be 1103 Sven Van den Bosch 1104 Alcatel 1105 Network Strategy Group 1106 Francis Wellesplein 1 1107 B-2018 Antwerpen Phone: +32 3 2408103 1108 BELGIUM Email: sven.van_den_bosch@alcatel.be 1110 Juan-Carlos Rojas 1111 Alcatel 1112 Next Generation Networks Division 1113 Le Mail 1114 F-44708 Orvault Cedex Phone: +33 2 51781282 1115 FRANCE Email: juan-carlos.rojas@alcatel.fr 1117 Stefan Custers 1118 Alcatel 1119 Next Generation Networks Division 1120 Francis Wellesplein 1 1121 B-2018 Antwerpen Phone: +32 3 2409071 1122 BELGIUM Email: stefan.custers@alcatel.be