idnits 2.17.1 draft-itsumo-dsnp-03.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 20. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. == In addition to a regular copyright notice, the document also has a copyright notice embedded in the text. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 417 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 593 instances of lines with control characters in the document. == There are 42 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 18 has weird spacing: '...tent or other...' == Line 24 has weird spacing: '... other grou...' == Line 28 has weird spacing: '... months and ...' == Line 30 has weird spacing: '... as referen...' == Line 48 has weird spacing: '...r. It can b...' == (412 more instances...) -- 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. 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. 'DIFF01' ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. 'DIFF98') -- Possible downref: Non-RFC (?) normative reference: ref. 'DRCP00' -- Possible downref: Non-RFC (?) normative reference: ref. 'IMT97' ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. 'INT94') -- Possible downref: Non-RFC (?) normative reference: ref. 'ITSUMO00' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITSUMO99' ** Obsolete normative reference: RFC 3015 (ref. 'MEGACO00') (Obsoleted by RFC 3525) ** Obsolete normative reference: RFC 2486 (ref. 'NAI99') (Obsoleted by RFC 4282) ** Downref: Normative reference to an Informational RFC: RFC 2753 (ref. 'POLICY00') ** Obsolete normative reference: RFC 2570 (ref. 'SNMP99') (Obsoleted by RFC 3410) Summary: 19 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jyh-Cheng Chen 3 INTERNET-DRAFT National Tsing Hua University 4 Internet Engineering Task Force Anthony McAuley 5 draft-itsumo-dsnp-03.txt Telcordia Technologies, Inc. 6 Date: February 15, 2006 Venkatesh Sarangan 7 Expires: August 19, 2006 Oklahoma State University 8 Shinichi Baba 9 Toshiba Corporation 10 Yoshihiro Ohba 11 Toshiba America Research Inc. 13 Dynamic Service Negotiation Protocol (DSNP) 15 Status of this memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other 29 documents at any time. It is inappropriate to use Internet-Drafts 30 as reference material or to cite them other than as "work in 31 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 August 19, 2006. 41 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 This memo presents the specification of Dynamic Service Negotiation 47 Protocol (DSNP). DSNP is a protocol to negotiate the SLS (Service 48 Level Specification) in IP layer. It can be used for service 49 negotiation from host to network, network to host, and network to 50 network. The automated negotiation makes service negotiation 51 efficient in terms of time, cost, and correctness, etc. The dynamic 52 negotiation not only allows users to adapt their needs dynamically, 53 but also let providers better utilize the network. The DSNP 54 messages and packet formats are detailed. DSNP can be used in both 55 wireline and wireless networks. It is, however, particularly 56 useful in mobile environment. To demonstrate the usefulness of 57 DSNP, a reference wireless QoS architecture is presented. 58 Exemplary applications are illustrated. 60 Table of Contents 62 1. Introduction 63 2. Protocol Overview 64 3. DSNP Messages 65 4. Basic Operation 66 4.1 Reference Architecture 67 4.2 Reference QoS Architecture 68 4.3 Distribution of QoS Profile and Traffic Conditioning 69 5. Example Applications 70 5.1 Initial QoS Negotiation 71 5.2 Client Moves within the Same Domain 72 5.3 Client Renegotiates SLS within the Same Domain 73 5.4 Client Moves into a New Domain 74 6. DSNP Message Format 75 7. Acknowledgments 76 8. References 77 9. Authors' Addresses 79 1. Introduction 81 Today, many different wireless systems exist, ranging from PANs 82 (Personal Area Networks), wireless LANs (Local Area Networks) to 83 outdoor cellular systems. They are typically not compatible with 84 each other, making it difficult to roam from one system to 85 another. PANs, Wireless LANs, and cellular wireless systems are 86 also being developed and are evolving independently (e.g., from 3G 87 to 4G, 802.11 to 802.11a/802.11b, HIPERLAN to HIPERLAN II, etc.). 88 Although ITU IMT-2000 [IMT97] has been trying to unify 89 third-generation (3G) wireless systems, incompatible systems are 90 expected to co-exist in the future. No wireless technology has 91 emerged as a common and long-term universal solution. 93 IP (Internet Protocol), which is already a universal network-layer 94 protocol for wireline packet networks, is becoming a promising 95 universal network-layer protocol over all wireless systems. An IP 96 device, with multiple radio interfaces or software radio, could 97 roam between different wireless systems if they all support IP as a 98 common network layer. Unlike today's radio systems that continue 99 to depend heavily on proprietary technologies, IP provides a 100 globally successful open infrastructure for services and 101 applications. Such an all-IP wireless and wireline network could 102 also make wireless networks more robust, scalable, and cost 103 effective. 105 A key challenge in realizing the all-IP wireless networks is how to 106 guarantee Quality of Service (QoS). To guarantee QoS on the 107 Internet, Int-Serv (Integrated Services) [INT94] and Diff-Serv 108 (Differentiated Services) [DIFF98], which differ in the technique 109 for resource provisioning and the granularity of service 110 differentiation, have been proposed. Both approaches, however, are 111 limited to stationary hosts and cannot be applied to the mobile 112 environment directly. 114 Today the service level agreement (SLA) is usually agreed, either 115 verbally or in writing, by both the user and the service provider 116 when a user signs up for a service. The service provider stores it 117 in some repository and uses it to condition the traffic sending 118 to/from the user. To change the SLA, normally a user has to contact 119 and negotiate with the authority of the service provider, which 120 then manually changes it. Usually service provider allows this 121 kind of re-negotiation or changes only in a large time scale, for 122 instance, once per year. 124 It is expected that a user will use a different terminal with 125 different capability in different situation. For example, PC may be 126 used at home or inside an office. While driving, small handset 127 might be more suitable. PDA or laptop will be used when traveling. 128 They are different not only in size, but also in processing and 129 communication capabilities. Different applications will also be 130 used in different terminals. They generally require different 131 bandwidth for network transmission. 133 As stated above, mobility and the diversity in transmission media 134 (Bluetooth, 802.11, cellular, etc.) and user terminals (PC, 135 laptop, PDA, etc.) create a very dynamic environment. It is hardly 136 for a service provider to plan uniform resource in all networks and 137 to envision fixed bandwidth requirement from all users. Users are 138 also hardly to project what they really need due to mobility and 139 the difference in terminal they may carry. In addition, users may 140 roam to other service providers and still wish to enjoy the same 141 QoS as they had in the home provider. It is desirable that there is 142 a way to negotiate the service dynamically. This dynamic service 143 negotiation should be automated and should be able to do in a small 144 time scale in opposite to today's manual negotiation in a large 145 time scale. A user should be able to negotiate with the home and 146 visiting service providers dynamically. Similarly, the service 147 provider can also negotiate with a user depending on the resource 148 available. A service provider may advertise unused resource if the 149 resource is underutilized. On the other hand, a service provider 150 can negotiate with users to lower their service grade if the 151 network is over-provisioned. While the user is roaming, the home 152 and visiting providers should also be able to negotiate with each 153 other to decide the service which can be offered to the user. 154 There should be a standard protocol which can be used for service 155 negotiation for multi-vendors and multi-service providers. 157 2. Protocol Overview 159 DSNP (Dynamic Service Negotiation Protocol) is a protocol to 160 dynamically negotiate the SLS (Service Level Specification) 161 [DIFF01] in IP layer. DSNP can be used for service negotiation 162 from host to network, network to host, and network to network. The 163 automated negotiation makes service negotiation efficient in terms 164 of time, cost, and correctness, etc. 166 DSNP can be used in both wireline and wireless networks. It is, 167 however, particularly useful in mobile environment. For example, a 168 mobile user may roam to a new service provider which does not have 169 any contract with either the mobile user or its old service 170 provider. The inter-domain negotiation might be necessary in order 171 to get network service. Even though the old and new providers have 172 certain level of service agreement, the new service provider may 173 still need to negotiate with the old service provider. When 174 roaming inside the same domain, the following are some motivation 175 to support dynamic intra-domain negotiation: 177 (1) A user may carry a different terminal at different time to 178 access the network. The capabilities of these terminals may be 179 different, thus the network resource requirements may be 180 different too. 182 (2) A user may roam to networks with different physical and link 183 layers, for instance, from Bluetooth to IEEE 802.11 to IS-95 184 (or other outdoor cellular systems). The available resource 185 typically are different in different type of networks. 187 (3) Due to mobility, the provisioning of network resource may not 188 be accurate for actual demand. For example, a special event in 189 a city may gather many unexpected network users. 191 Dynamic service negotiation not only allows users to adapt their 192 needs dynamically, but also let the service provider better utilize 193 the network. 195 Service negotiation may involve human. If so, some applications 196 may be needed. The user or the service provider may also 197 pre-define and store their policy so the negotiation can be done 198 without human interactions. In either case, DSNP is a protocol for 199 hosts and networks to negotiate SLS in IP layer. 201 DSNP can be used in any architecture frameworks. It is independent 202 of network architecture, and how resource reservation or 203 provisioning is done. DSNP, however, is particularly useful in 204 Diff-Serv [DIFF98]. Diff-Serv is built on the concept of 205 classifying packets and keeping per-customer state at the network 206 edge and letting the core deal with aggregates of traffic. In 207 operation, routers use DS (Diff-Serv) byte to differentiate traffic 208 flows belonging to different service classes. The edge routers 209 perform conditioning functions to keep traffic "in profile" with 210 the TCA (Traffic Conditioning Agreement). 212 In order to condition the traffic properly, the edge router needs 213 to know the QoS profile of a user. The changes in SLS should be 214 known by the necessary edge routers (ERs). In mobile environment, 215 there should be an efficient way to distribute mobile's QoS profile 216 to possible ERs. It is also desirable to reduce QoS-related 217 signalling messages for every handoff so fast handoff can be 218 achieved. 220 Next section presents the DSNP messages. To demonstrate the 221 usefulness of DSNP, Section 4 presents a reference architecture, 222 then shows a way to distribute QoS profile once a negotiation is 223 done so mobile users can perform fast handoff while also guarantee 224 the same level of QoS. Section 5 shows some exemplary applications 225 of DSNP. The DSNP message format is presented in Section 6. 227 3. DSNP Messages 229 3.1 Terminology 231 3.1.1 DSNP Client 232 A DSNP client is the one that initiates the SLS negotiation. 234 3.1.2 DSNP Server 236 A DSNP server is the one that responds to the SLS negotiation. 238 For example, when a host wants to negotiate with the service 239 provider for a SLS, the host acts as the DSNP client. The service 240 provider acts as the DSNP server. When a service provider starts 241 the SLS negotiation with a host, the service provider acts as the 242 DSNP client and the host acts as the DSNP server. When a service 243 provider negotiates a SLS with another service provider, the former 244 acts as the DSNP client and the latter acts as the DSNP server. 246 3.2 DSNP Message Types 248 This section explains the various messages used in DSNP. An 249 intra-domain negotiation scenario is assumed. A host acts as the 250 DSNP client and a service provider's QoS authority acts as the DSNP 251 server. 253 o SLS_LIST_REQUEST: This message is sent by a DSNP client to the 254 DSNP server, to request for a list of SLSs offered by 255 the DSNP server. A DSNP client may send this message when it 256 has just booted up and does not have any idea about the 257 services provided by the network. 259 o SLS_LIST_RESPONSE: This message is sent by the DSNP server in 260 response to the SLS_LIST_REQUEST message. This message lists 261 all the SLSs that are provided by the DSNP server. The cost 262 and the time of availability for each service may also be 263 included in the list. 265 o SLS_NEGO_REQUEST: This message is usually sent by an DSNP client 266 to the DSNP server, to request for a particular SLS. The 267 requested SLS could either be customized or one of those 268 listed in the SLS_LIST_RESPONSE message. The time for which 269 the SLS is requested may also be included in the message. This 270 message is used for both requesting a new SLS as well as 271 updating an existing one. 273 The DSNP server can also send this message to the hosts under 274 some circumstances. For example, if network resources become 275 scarce, the DSNP serversends this message to the hosts that 276 have a SLS with the DSNP server requesting them to update 277 their existing SLS to suit the current network conditions. The 278 DSNP server could offer cost incentives to the hosts that 279 accept the suggested SLS. Similarly, when there are unused 280 resources available, the DSNP server could offer them at a 281 lower price to the DSNP clients. It could do an advertisement 282 by sending out SLS_NEGO_REQUEST messages with the available 283 SLSs and the cost. Also, if the DSNP server wants to 284 forcefully terminate a SLS of an DSNP client due to some 285 reason, it sends a SLS_NEGO_REQUEST message to the DSNP client 286 with appropriate fields set to ZERO. 288 o SLS_NEGO_RESPONSE: This message is sent in response to the 289 SLS_NEGO_REQUEST. This message indicates whether the requested 290 SLS was accepted or not. If the requested SLS was not 291 accepted, then the reason for not accepting is also 292 provided. For example, if the DSNP server does not accept the 293 SLS of an DSNP client due to lack of resources, it sends back 294 a SLS_NEGO_RESPONSE indicating a reject along with the maximum 295 SLS that could be supported. 297 o SLS_STAT_REQUEST: This message is sent by a DSNP client to the 298 DSNP Server asking for a feedback on the statistics of the 299 actual usage of each SLS. The DSNP client could ask for 300 statistics like packet loss, throughput, average delay, 301 jitter, and total number of octets sent from/forwarded to the 302 DSNP client. 304 o SLS_STAT_RESPONSE: This message is sent by the DSNP server in 305 response to a SLS_STAT_REQUEST message. The DSNP server 306 collects the necessary information and sends it to the 307 requested DSNP client. 309 The above message types are explained in an intra-domain 310 negotiation scenario. The same messages could also be used in an 311 inter-domain negotiation. In an inter-domain negotiation, one 312 network requests for some service (and hence acts as the DSNP 313 client) and the other provides the requested service (and hence 314 acts the DSNP server). The nature of interaction hence remains the 315 same as in an intra-domain negotiation. 317 4. Basic Operation 319 4.1 Reference Architecture 321 To demonstrate the usefulness of DSNP, we use the ITSUMO 322 architecture as a reference architecture. DSNP, however, can be 323 used in any network architecture. 325 ITSUMO [ITSUMO00] is a research project that focuses on the design 326 of next generation IP networks. It envisions an end-to-end 327 wireless/wireline IP platform for supporting real-time and 328 non-real-time multimedia services in the future. Its goal is to 329 use IP and next generation wireless technologies to design a 330 wireless platform that allows mobile users to access all services 331 on a next generation Internet. 333 Figure 1 depicts the end-to-end packet platform of ITSUMO's all IP 334 wireless/wireline network, which comprises all IP wireless access 335 networks and a packet switched IP backbone network. The IP backbone 336 network is an end-to-end wireline IP infrastructure that will 337 comprise regional providers' wireline IP networks that are 338 connected through the Internet. Besides mobile stations/terminals, 339 a wireless access network also comprises a radio access network 340 (RAN), and an edge router and controller (ERC) [ITSUMO99]. In 341 order to support the needs of its users, a wireless access network 342 interacts with the network control entities that are shown as 343 Domain Control Agent (DCA) in Figure 1. What follows is a brief 344 description of these elements and their functions. 346 4.1.1 Mobile Station (MS) 348 It is the user mobile terminal that allows users to communicate, 349 and also provides means of interactions and control between 350 users and the network. 352 4.1.2 Radio Access Network (RAN) 354 The radio access network (RAN) represents the wireless and 355 back-haul infrastructure that provides MSs with wireless access 356 to the wireline infrastructure. A RAN usually comprises a set 357 of base stations and base station controllers. In IMT-2000 358 [IMT97], RANs use programmable software radios to provide 359 flexibility across frequency bands at the MS and across the RAN. 360 ITSUMO strives to remain independent from the underlying RAN 361 technology and to minimize the restriction (or requirements) 362 that it places on (or expects from) a RAN. 364 4.1.3 Edge Router & Controller (ERC) 366 An ERC is a routing and control system that connects a wireless 367 access network to a regional wireline IP network. Although 368 Figure 1 depicts one RAN per ERC, in practice, each ERC may 369 support several RANs. An ERC comprises two functional entities, 370 an edge router (ER) and an edge control agent (ECA). The ER is 371 an IP router, while the ECA is an intelligent agent that 372 interacts with the domain control agent (DCA) to control the 373 RANs as well as support necessary network-wide control tasks. In 374 the IP parlance, each ERC is the default gateway of all IP MSs 375 that are supported by RANs that are connected to it. 377 4.1.4 Domain Control Agent (DCA) 379 The domain control agent (DCA) provides connection management as 380 well as means for interaction between users and network control 381 system and interaction among network control 382 entities. Furthermore, the DCA also supports: (1) Mobility 383 management, (2) Authentication, Authorization, and Accounting 384 (AAA), and (3) QoS management (MAAAQ) functions for mobile 385 users. These functional entities usually reside on the wireline 386 backbone, and are part of the overall control system of the 387 end-to-end platform. As Figure 1 indicates the home and 388 visiting DCA entities may either interact directly or via a 389 third party Inter-Domain Control Agent (IDCA) on the global 390 Internet. In the latter case, the IDCA entity serves as a 391 trusted broker between the home and visiting network DCAs. 393 <-- Visiting Network --> <---- Home Network ----> 395 +---------------+ 396 | Inter-Domain | 397 | Control Agent | 398 +---------------+ 399 | 400 | 401 +---------------+ | +---------------+ 402 | Domain | | | Domain | 403 | Control Agent | | | Control Agent | 404 +---------------+ | +---------------+ 405 | | | 406 ___|___ ___|___ ___|___ 407 / \ / \ / \ 408 / \ / \ / \ 409 /Regional IP\___________/ Internet \___________/Regional IP\ 410 \ Network / \ / \ Network / 411 \ / \ / \ / 412 ---\_______/--- \_______/ ---\_______/--- 413 | | | | 414 +-----+ +-----+ +-----+ +-----+ 415 | ERC | | ERC | | ERC | | ERC | 416 +-----+ +-----+ +-----+ +-----+ 417 | | | | 418 | | | | 419 | | | | 420 __|__ __|__ __|__ __|__ 421 / \ / \ / \ / \ 423 / Radio \ / Radio \ / Radio \ / Radio \ 424 / Access \ / Access \ / Access \ / Access \ 425 \ Network / \ Network / \ Network / \ Network / 426 \ / \ / \ / \ / 427 \_____/ \_____/ \_____/ \_____/ 428 | | | | 429 v v v v 430 +----+ +----+ +----+ +----+ 431 | MS | | MS | | MS | | MS | 432 +----+ +----+ +----+ +----+ 434 FIGURE 1: ITSUMO long term network architecture 436 4.2 Reference QoS Architecture 438 This section presents a reference QoS architecture which is based 439 on the ITSUMO overall architecture. Again, DSNP is independent of 440 QoS architecture. 442 <----------- DOMAIN 1 -----------> <---------- DOMAIN 2 -------------> 444 +--------------+ +---------------+ 445 | QoS Global | | QoS Global | 446 | Server (QGS) | | Server (QGS) | 447 +--------------+ +---------------+ 448 | | 449 ___|___ _______ ___|___ 450 / \ / \ / \ 451 / \ / \ / \ 452 /Regional IP\__________/ Global IP \__________/Regional IP\ 453 \ Network / \ Network / \ Network / 454 \ /---------\ \ / ----------\ / 455 --\_______/--- \ \_______/ | \_______/----- 456 | | \ | | | 457 +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ 458 | QLN | | QLN | | QLN | | QLN | | QLN | | QLN | 459 +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ 460 __|__ __|__ __|__ __|__ __|__ __|__ 461 / \ / \ / \ / \ / \ / \ 462 / Radio \ / Radio \ / Radio \ / Radio \ / Radio \ / Radio \ 463 / Access \ / Access \ / Access \ / Access \ / Access \ / Access \ 464 \ Network / \ Network / \ Network / \ Network / \ Network / \ Network / 465 \ / \ / \ / \ / \ / \ / 466 \_____/ \_____/ \_____/ \_____/ \_____/ \_____/ 467 | | | | | | 468 v v v v v v 469 +----+ 470 | MS | --> 471 +----+ 473 FIGURE 2: Reference QoS architecture 475 As that in the ITSUMO overall architecture, there is at least one 476 logical global server and several local nodes in each 477 administrative domain. The server is referred to as the QoS Global 478 Server (or QGS), and local nodes are referred to as QoS local nodes 479 (or QLN). The architecture is depicted in Figure 2. In addition 480 to other necessary components in the system such as 481 DHCP[DHCP97]/DRCP[DRCP00] server, AAA, etc., there are three major 482 QoS components: 484 4.2.1 MS (Mobile Station) 486 MS is the device that allows users to communicate, and also 487 provides means of interaction between users and the networks. 488 Traffic is generated/received by MS and may be queued in the MS 489 while waiting for transmission/reception. 491 4.2.2 QGS (QoS Global Server) 493 As shown in Figure 2, there is one logical QGS in each 494 administrative domain. The QGS has the global information of 495 the resource available in the whole domain. Essentially, it is 496 a bandwidth broker with extension for wireless networks. The MS 497 interacts with the QGS when the MS requests certain degree of 498 QoS in the domain. The QGS is the entity for QoS negotiation 499 and signaling between MS and the network control system, i.e. 500 it is in control plan, as that of MGC (Media Gateway Controller) 501 in MEGACO [MEGACO00]. The QGS decides what services are 502 available for each MS and sends the decision to related QLNs. 503 Thus, the QGS is an intelligent entity for decision making. It 504 is similar to PDP (Policy Decision Point) in Policy Framework 505 [POLICY00]. 507 4.2.3 QLN (QoS Local Node) 509 QLN is the edge router residing in the boundary of the DS 510 domain. Figure 2 depicts that QLN could be part of ERC (Edge 511 Router & Controller), or could reside in a component inside RAN 512 (radio access network) such as BS (base station). QLN is like a 513 wireless bandwidth broker which retains the local information of 514 the resource in the local domain. However QLN does not interact 515 with MS directly for QoS negotiation and signaling. In stead, 516 this local information is provided to the QGS. QLN then performs 517 traffic conditioning according to the instruction from the 518 QGS. Therefore, it functions like PEP (Policy Enforcement Point) 519 in Policy Framework [POLICY00]. In contrast to QGS, QLN handles 520 the actual traffic thus it is in transport plane, similar to MG 521 (Media Gateway) in MEGACO [MEGACO00]. 523 Please note, the QGSs in domain 1 and domain 2 may contact with 524 each other directly, or through a public QGS which may attach to 525 the "Global IP Network" in Figure 2. 527 Since QGS retains the global information of the whole 528 administrative domain, dynamic service negotiation can be achieved 529 easily and efficiently. The MS only needs to negotiate with the 530 QGS, which makes the decision based on the up-to-date global 531 information. Once it is done, the QGS will instruct the related 532 QLNs how to condition the MS's traffic. Therefore, the MS can move 533 freely inside the domain. How does the QGS allocate resource and 534 reach the decision can be done in many different ways which have 535 been proposed in literature. By separating control and transport, 536 the architecture is also flexible, easy to add new services, easy 537 to integrate with other network components, and easy to 538 interoperate with legacy networks. 540 One can also distribute the intelligence and functionality of QGS 541 to all QLNs, which makes a different QoS architecture. The 542 discussion of QoS architecture is outside the scope of this memo. 543 We simply use the QoS architecture defined above to illustrate the 544 applications of DSNP. 546 4.3 Distribution of QoS profile and Traffic Conditioning 548 In wired network, it is easy to locate a user, therefore it is easy 549 to locate the edge router that will need to condition the traffic 550 for a specific user. In wireless networks, however, users can roam 551 anywhere. Thus potentially all edge routers will need to know the 552 QoS profile of a users. One straightforward solution is to let all 553 edge routers in the domain maintain the QoS profiles of all 554 users. Each time when service negotiation is done, the new SLS is 555 broadcast to all edge routers. It is, however, inefficient to 556 maintain the same copy of data in all edge routers. It causes 557 unnecessary broadcast too. If the number of edge routers in the 558 domain is huge, the data are replicated unnecessarily in many 559 places. The database in each edge router will be huge too if there 560 are many users in the domain. In addition, once a MS moves or 561 changes its SLS, the same transaction for updating the database 562 must be performed for all edge routers. Many edge routers may 563 never have traffic coming from or going to the MS. 565 It is desirable to maintain the QoS profiles of all users in the 566 domain only in a central repository. Edge routers only keep the 567 necessary data without maintaining the QoS profiles of all users in 568 the domain. Referring to the QoS architecture presented in Section 569 4.2, the QGS of the domain retains the database of all users. Each 570 time when the service negotiation is done, the QGS sends the new 571 SLS of the user to potential QLNs only. The potential QLNs may be 572 the neighboring QLNs of current serving QLN. Each time when the MS 573 moves, the QGS can select the new set of potential QLNs, as that 574 the QGS maintains the global information and is the decision 575 maker. Therefore, the QoS profile of the MS can be distributed to 576 the new QLN before the MS moves. Since everything is done by the 577 network, the MS does not need to perform QoS-related signaling once 578 the initial negotiation is done. It reduces the amount of QoS 579 signaling messages, conserves MS's energy, and achieves fast 580 handoff. 582 5. Example Applications 584 5.1 Initial QoS Negotiation 586 When a MS is powered up, first it may need to perform registration 587 and configuration with DHCP/DRCP to get an IP address. Before the 588 MS sends actual traffic, it initiates the QoS signaling with the 589 QGS if there is no service agreement or the MS wants to renegotiate 590 it. The QGS may need to consult with AAA or other servers if 591 necessary. Based on the interaction with other servers, the global 592 information in QGS, service agreement, and other information such 593 as mobility pattern, etc., the QGS will either admit or reject the 594 QoS request. If the request is accepted, the SLS for the MS will be 595 multicast to the potential QLNs. As discussed in Section 4.3, the 596 potential set of QLNs may include current serving QLN and its 597 neighboring QLNs. 599 Figure 3 shows an example in that the MS uses DHCP to get an IP 600 address for the subnet in the initial set-up. It then makes a QoS 601 request for the list of available SLS. Based on the response, the 602 MS negotiates with QGS for the SLS it wants. The QGS consults with 603 AAA server, then makes the decision. Assuming that the QGS decides 604 to offers certain kind of service to the MS. It sends the decision 605 to the related QLNs so they can condition the MS's traffic 606 accordingly. COPS [COPS00] or SNMP [SNMP99] can be used for the 607 communication between QGS and QLNs. After receiving the 608 SLS_NEGO_RESPONSE, the MS can send its actual traffic. 610 DHCP AAA 611 MS Server QGS Server QLNi 613 | | | | | 614 | DHCP DISCOVER | | | | 615 |--------------->| | | | 616 | DHCP OFFER | | | | 617 |<---------------| | | | 618 | DHCP REQUEST | | | | 619 |--------------->| | | | 620 | DHCP ACK | | | | 621 |<---------------| | | | 622 | | | | | 623 | | | | 624 | SLS_LIST_REQUEST | | | 625 |---------------------------->| | | 626 | | | | 627 | SLS_LIST_RESPONSE | | | 628 |<----------------------------| | | 629 | | | | 630 | SLS_NEGO_REQUEST | | | 631 |---------------------------->| | | 632 | | AAA REQUEST | | 633 | |------------>| | 634 | | AAA RESPOND | | 635 | |<------------| | 636 | | | | 637 | | | 638 | | UPDATE | 639 | |------------------------->| 640 | | ACK | 641 | |<-------------------------| 642 | | | 643 | SLS_NEGO_RESPONSE | | 644 |<----------------------------| | 645 | | | 646 | | 647 | | 648 | actual traffic | 649 |<------------------------------------------------------>| 650 | | 652 * QLNi indicates the potential set of QLNs 654 FIGURE 3: Example flow for initial set-up 656 5.2 Client Moves within the Same Domain 657 When the MS is roaming inside the same administrative domain, i.e., 658 the domain serving by the same QGS, the MS only needs to get a new 659 IP address if changing subnet. It does not need to have any QoS 660 signaling since the decision made by the QGS has been sent to all 661 potential QLNs. As discussed in Section 4.3, the set of potential 662 QLNs may be changed dynamically while the MS is moving. Thus the 663 MS can transmit/receive traffic without initiating new QoS 664 signaling while it is moving within the same administrative domain. 665 Figure 4 is an example flow for moving within the same domain but 666 the subnet is changed. 668 DHCP 669 MS Server QLNi QGS 671 | DHCP DISCOVER | | | 672 |---------------------->| | | 673 | DHCP OFFER | | | 674 |<----------------------| | | 675 | DHCP REQUEST | | | 676 |---------------------->| | | 677 | DHCP ACK | | | 678 |<----------------------| | | 679 | | | | 680 | | | 681 | actual traffic | | 682 |<-------------------------------------->| | 683 | | | 685 FIGURE 4: Example flow for moving within the same domain 687 5.3 Client Renegotiates SLS within the Same Domain 689 Once the MS is up and the QoS negotiation is done, the MS is free 690 to move within the same domain without any QoS signaling. As 691 discussed before, however, the MS may want to change the SLS and 692 renegotiate with the network for the service level. Figure 5 plots 693 an example flow for this. It is similar to Figure 3 except that the 694 MS has the IP address and the list of SLS already. 696 AAA 697 MS QGS Server QLNi 699 | | | | 700 | SLS_NEGO_REQUEST | | | 701 |---------------------------->| | | 702 | | AAA REQUEST | | 703 | |------------>| | 704 | | AAA RESPOND | | 705 | |<------------| | 706 | | | | 707 | | | 708 | | UPDATE | 709 | |------------------------->| 710 | | ACK | 711 | |<-------------------------| 712 | | | 713 | SLS_NEGO_RESPONSE | | 714 |<----------------------------| | 715 | | | 716 | | 717 | | 718 | actual traffic | 719 |<------------------------------------------------------>| 720 | | 722 FIGURE 5: Example flow for renegotiating SLS within the same domain 724 5.4 Client Moves into a New Domain 726 When the MS moves to a new administrative domain, it must initiate 727 the QoS signaling with the new QGS. The new QGS may consult with 728 the new AAA server, old AAA server, and the old QGS to decide 729 whether it should admit or reject the QoS request. After that, it 730 is similar to what described above. Figure 6 presents an example 731 flow when the MS roams to a new domain. 733 New DHCP New New Previous Previous New 734 MS Server QGS AAA QGS AAA QLNi 736 | | | | | | | 737 | DHCP | | | | | | 738 | DISCOVER| | | | | | 739 |-------->| | | | | | 740 | DHCP | | | | | | 741 | OFFER | | | | | | 742 |<--------| | | | | | 743 | DHCP | | | | | | 744 | REQUEST | | | | | | 745 |-------->| | | | | | 746 | DHCP | | | | | | 747 | ACK | | | | | | 748 |<--------| | | | | | 749 | | | | | | 750 | SLS_NEGO_REQUEST | | | | | 751 |------------------>| | | | | 752 | | AAA | | | | 753 | | REQUEST | | | | 754 | |-------->| | | 755 | | | AAA REQUEST | | 756 | | |------------------>| | 757 | | | AAA RESPOND | | 758 | | |<------------------| | 759 | | AAA | | | 760 | | RESPOND | | | 761 | |<--------| | | 762 | | | | | 763 | | SLS_NEGO REQUEST | | | 764 | |------------------>| | | 765 | | SLS_NEGO_RESPONSE | | | 766 | |<------------------| | | 767 | | | | | 768 | | | 769 | | UPDATE | 770 | |-------------------------------------->| 771 | | ACK | 772 | |<--------------------------------------| 773 | SLS_NEGO_RESPONSE | | 774 |<------------------| | 775 | | | 776 | | 777 | actual traffic | 778 |<--------------------------------------------------------->| 779 | | 781 FIGURE 6: Example flow for roaming to a new domain 783 6. DSNP Message Format 785 All DSNP messages are sent in UDP/IP packets to special DSNP ports 786 and are network byte ordered. The size of the fields is shown in 787 braces. 789 6.1 SLS_LIST_REQUEST 791 0 1 2 3 792 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | op(2) | AttrMap(2) | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | UIDlen(1) | UID(variable) | 797 +-+-+-+-+-+-+-+-+ | 798 | | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 The various fields are : 803 FIELD OCTETS DESCRIPTION 804 ----- ------ ----------- 805 op 2 Message Opcode 806 AttrMap 2 Attribute Map 807 UID variable Universal identifier 808 for the host. 809 UIDlen 1 Length of the UID 810 field 812 6.1.1 Opcode 814 The opcode field has two octets. The first octet indicates which 815 of the six messages described in section 3 is being transmitted 816 or received. The possible values for the first octet are: 818 Octet Value Message Type 819 ----------- ------------ 820 0 0 0 0 0 0 0 0 SLS_LIST_REQUEST 821 0 0 0 0 0 0 0 1 SLS_LIST_RESPONSE 822 0 0 0 0 0 0 1 0 SLS_NEGO_REQUEST 823 0 0 0 0 0 0 1 1 SLS_NEGO_RESPONSE 824 0 0 0 0 0 1 0 0 SLS_STAT_REQUEST 825 0 0 0 0 0 1 0 1 SLS_STAT_RESPONSE 827 Each type of DSNP message has associated sub-types. The second 828 octet indicates the sub-type of the DSNP message. However, this 829 message SLS_LIST_REQUEST has no sub-types. Hence the second octet 830 will be assigned zero. The use of the second octet will be clear 831 in the DSNP messages. 833 6.1.2 AttrMap 835 The AttrMap field has two octets. This field is a bit map of the 836 attributes the DSNP client is interested in negotiating with the 837 DSNP server. In this version of DSNP, only the bits in the 838 second octet are used in the bitmap. The first octet is reserved 839 for future use. 841 Bit Position Associated Attribute 842 ------------- -------------------- 843 1 Scope 844 2 Flow specification 845 3 Traffic description 846 4 Traffic guarantees 847 5 Service schedule 848 6 Unused 849 7 Unused 850 8 Unused 852 For example, if the DSNP client sends bitmap 00001110 in the 853 SLS_LIST_REQUEST message, it means that it is requesting only the 854 flow specification, traffic description and traffic guarantees 855 (and not the scope or the service schedule) of the various SLSs 856 provided by the DSNP server. The field AttrMap is thus used to 857 indicate the set of attributes that are negotiated between a DSNP 858 client and the DSNP server. The second octet in opcode identifies 859 which attribute of the set is being negotiated. 861 6.1.3 UID 863 This filed is the universal identifier for the DSNP client. For 864 example, this could be the IPv4 home address of the DSNP client, 865 or the Network Access Identifier (NAI) [NAI99]. 867 6.2 SLS_LIST_RESPONSE 869 The semantic content of SLS has associated attributes. The second 870 octet in the opcode indicates which of the these attributes is 871 being dealt by the message. So far, five attributes have been 872 identified. They are : 874 - Scope of the SLS 875 - Flow specification 876 - Traffic description and conformance testing 877 - Performance guarantees 878 - Service schedule 880 The second octet indicates the sub-type within each of the above 881 six messages. The possible values for the second octet are: 883 Octet Value Sub-Type 884 ------------ -------- 885 0 0 0 0 0 0 0 0 Initial message 886 0 0 0 0 0 0 0 1 Scope 887 0 0 0 0 0 0 1 0 Flow specification 888 0 0 0 0 0 0 1 1 Traffic description 889 0 0 0 0 0 1 0 0 Traffic guarantees 890 0 0 0 0 0 1 0 1 Service schedule 892 There are five sub-types within the SLS_LIST_RESPONSE message. 894 6.2.1 SLS_LIST_RESPONSE: Initial message 896 0 1 2 3 897 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | op(2) | AttrMap(2) | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | UIDlen(1) | UID(variable) | 902 +-+-+-+-+-+-+-+-+ | 903 | | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | SlsAvail(1) | SlsIndex(1) | SlsId(2) | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 This message is sent in response to the SLS_LIST_REQUEST 909 message. All fields are in the same as in SLS_LIST_RESPONSE 910 except that three new fields SlsAvail(1), SlsIndex(1) and 911 SlsId(2) are included. 913 6.2.1.1 SlsAvail 915 In response to the SLS_LIST_REQUEST message, the DSNP server 916 could send a list of SLSs available to the DSNP client. The 917 field SlsAvail indicates the total number of SLSs that are 918 being sent. 920 6.2.1.2 SlsIndex 922 SlsIndex indicates the number of the current SLS that is 923 being sent. 925 6.2.1.3 SlsId 927 SlsId is the identifier for the SLS that is being sent. 929 In this message, the second octet of the field "op" is set to 930 zero, indicating that, none of the SLS attributes are transmitted 931 in that packet. Subsequent to the above SLS_LIST_RESPONSE 932 message, the DSNP server sends additional SLS_LIST_RESPONSE 933 messages that describe the attributes of the various SLSs 934 offered. The DSNP server sends back only those attributes the 935 DSNP client requested for using the "AttrMap" field of the 936 SLS_LIST_REQUEST message. For each attribute that is begin sent, 937 the second octet in the opcode is set appropriately. 939 6.2.2 SLS_LIST_RESPONSE: Sending the scope 940 The scope of a SLS indicates the topology of the reservation 941 with reference to the end-points of the traffic flow. 943 0 1 2 3 944 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | op(2) | AttrMap(2) | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | UIDlen(1) | UID(variable) | 949 +-+-+-+-+-+-+-+-+ | 950 | | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | SlsAvail(1) | SlsIndex(1) | SlsId(2) | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | NumIngRtr(2) | NumEgrRtr(2) | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | | 957 | Ingress_list (variable) | 958 | | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | | 961 | Egress_list (variable) | 962 | | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 All fields are common to the initial SLS_RESPONSE_MESSAGE sent 966 but for the inclusion of the following fields: NumIngRtr(2), 967 NumEgrRtr(2), Ingress_list(variable) and 968 Egress_list(variable). The second octet in the opcode field is 969 set to 00000001 to indicate the attribute scope is being sent in 970 this message. 972 6.2.2.1 NumIngRtr 974 This field indicates the number of Ingress routers associated 975 with the scope. 977 6.2.2.2 NumEgrRtr 979 This field indicates the number of Egress routers associated 980 with the scope. 982 6.2.2.3 Ingress_list 984 This field is the address list of the ingress routers in the 985 scope. 987 6.2.2.4 Egress_list 989 This filed is the address list of the egress routers in the 990 scope. 992 6.2.3 SLS_LIST_RESPONSE: Sending the flow 994 Flow identification aims in creating an association between 995 packets and SLSs. The Term "flow" refers to a stream of packets 996 that are related. 998 0 1 2 3 999 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 | op(2) | AttrMap(2) | 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 | UIDlen(1) | UID(variable) | 1004 +-+-+-+-+-+-+-+-+ | 1005 | | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 | SlsAvail(1) | SlsIndex(1) | SlsId(2) | 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 | Length (1) | FlowType(1) | NumFlows(1) | | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | Src IP address (4) | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | Dest IP address (4) | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | Proto(1) | DS Byte (1) | | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | source port number (4) | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | Destination port number (4) | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | | 1022 | Rest_flows(variable) | 1023 | | 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 The second octet in the opcode is set to 00000010 to indicate 1027 that flow information about the SLS is being sent in the 1028 packet. The following fields are present in this message in 1029 addition to the fields already introduced: 1031 6.2.3.1 Length 1033 This field indicates the length of the message in bytes. 1035 6.2.3.2 FlowType 1037 This field indicates whether the flow specification contains 1038 only one flow - Simple flow or multiple flows - Complex 1039 flow. The complex flow is the logical OR of the set of flows 1040 specified. 1042 Field FlowType 1043 ----- -------- 1044 00000000 Simple flow 1045 00000001 Complex flow 1047 6.2.3.3 Numflows 1049 This field indicates the number of flows present in the 1050 specification. In the case of simple flow, this field will 1051 have a value 1, indicating only one flow is specified. In the 1052 case of a complex flow, this field will have a value equal to 1053 the number of flows. 1055 6.2.3.4 Src Ip address 1057 This field indicates the source IP address associated with the 1058 flow. This could be a wild card entry or a IP address. 1060 6.2.3.5 Dest Ip address 1062 This field gives the destination IP address associated with 1063 the flow. This could be a wild card entry or a IP address. 1065 6.2.3.6 Proto 1067 This filed gives the protocol associated with the flow. For 1068 example, this could be either TCP or UDP. 1070 6.2.3.7 DS Byte 1072 This filed gives the DS byte marking associated with the flow. 1073 Please note that this field indicates only the DSNP 1074 client-marking value. This is only for flow 1075 identification. The core routers do not take any routing 1076 decision based on this byte. 1078 6.2.3.8 Source port number 1080 This field gives the source port number associated with the 1081 flow. This could be a wild card entry or a valid port number. 1083 6.2.3.9 Destination Port number 1085 This filed gives the destination port number associated with 1086 the flow. This could be a wild card entry or a valid port 1087 number. 1089 6.2.3.10 Rest_flows 1091 This portion of the packet contains information about the 1092 additional flows in case a complex flow is defined. This 1093 includes fields from 6.2.3.4 to 6.2.3.9 for each of the 1094 remaining flows. 1096 6.2.4 SLS_LIST_RESPONSE: Sending the traffic description and 1097 conformance parameters 1099 The traffic description aims to provide an effective description 1100 of the traffic relevant to the reservation. 1102 0 1 2 3 1103 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | op(2) | AttrMap(2) | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | UIDlen(1) | UID(variable) | 1108 +-+-+-+-+-+-+-+-+ | 1109 | | 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 | SlsAvail(1) | SlsIndex(1) | SlsId(2) | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 | SR (4) | 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 | BSS (4) | 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | PR (4) | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | BSP (4) | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 | EAR (4) | 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 | M (4) | 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 | m (4) | 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 The opcode field is set appropriately to indicate that traffic 1129 description parameters are being sent. The following fields 1130 are present, in addition to the fields already before: 1132 6.2.4.1 SR 1134 This field indicates the Sustainable Rate in bit/s. 1136 6.2.4.2 BSS 1138 This field gives the Bucket size in bytes for SR. 1140 6.2.4.3 PR 1142 This field gives the peak rate of the traffic in bit/s. 1144 6.2.4.4 BSP 1146 This field gives the bucket size in bytes for PR. 1148 6.2.4.5 EAR 1150 This field gives the Expected Average Rate for the traffic 1151 in bit/s. 1153 6.2.4.6 M 1155 This field gives the maximum allowed packet size in bytes. 1157 6.2.4.7 m 1159 This field gives the minimum policed unit. 1161 6.2.5 SLS_LIST_RESPONSE: Sending the performance guarantees 1163 The performance guarantee attributes describe the QoS parameters 1164 enjoyed by the flow specified by the flow id, with the specified 1165 scope and conforming to the specified traffic conformance 1166 attributes. 1168 0 1 2 3 1169 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 | op(2) | AttrMap(2) | 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 | UIDlen(1) | UID(variable) | 1174 +-+-+-+-+-+-+-+-+ | 1175 | | 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 | SlsAvail(1) | SlsIndex(1) | SlsId(2) | 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1179 |G| unused | QntDelayPercentile(3) | 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 | QntJitterPercentile (3) | QntMaxLoss(1) | 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 | QntMaxDelay (2) | QntMaxJitter(2) | 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | QntAveDelay (2) | QntAveJitter(2) | 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 | QltDelay (1) | QltJitter(1) | QltLoss (1) | | 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 The second byte in the opcode is set appropriately to indicate 1191 that performance guarantee attributes are being exchanged. The 1192 following fields are present in addition to the already 1193 explained fields : 1195 6.2.5.1 G 1197 This field is only one bit wide and indicates whether the 1198 performance guarantee is qualitative or quantitative. '0' 1199 indicates qualitative and '1' indicates quantitative. 1201 6.2.5.2 QntDelayPercentile 1203 This filed indicates the quantitative delay percentile. The 1204 first octet in this field indicates the percentile and the 1205 next two octets indicate the delay value in ms. 1207 6.2.5.3 QntJitterPercentile 1209 This filed indicates the quantitative jitter percentile. The 1210 first octet in this field indicates the percentile and the 1211 next two octets indicate the jitter value in ms. 1213 6.2.5.4 QntMaxLoss 1215 This field gives the quantitative maximum loss ratio of the 1216 packets. 1218 6.2.5.5 QntMaxDelay 1220 This field gives the quantitative maximum delay in ms. 1222 6.2.5.7 QntMaxJitter 1224 This field gives the quantitative maximum jitter in ms. 1226 6.2.5.8 QntAveDelay 1228 This field gives the quantitative average delay in ms. 1230 6.2.5.9 QntAveJitter 1232 This field gives the quantitative average jitter in ms. 1234 6.2.5.10 QltDelay 1236 This field gives the qualitative delay. The possible values 1237 are high, medium, low, very low. 1239 Field Qualitative Delay Value 1240 ----- ----------------------- 1241 00000000 High 1242 00000001 medium 1243 00000010 low 1244 00000011 very low 1246 6.2.5.11 QltJitter 1248 This field gives the qualitative jitter. The possible values 1249 are high, medium, low, very low. 1251 Field Qualitative Jitter Value 1252 ----- ------------------------ 1253 00000000 High 1254 00000001 medium 1255 00000010 low 1256 00000011 very low 1258 6.2.5.11 QltLoss 1260 This field gives the qualitative loss ratio. The possible 1261 values are high, medium, low, very low. 1263 Field Qualitative Loss ratio 1264 ----- ------------------------ 1265 00000000 High 1266 00000001 medium 1267 00000010 low 1268 00000011 very low 1269 6.2.6 SLS_LIST_RESPONSE: Sending the service schedule 1271 The servie schedule attributes provide information regarding the 1272 start and duration of the service. 1274 0 1 2 3 1275 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 | op(2) | AttrMap(2) | 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 | UIDlen(1) | UID(variable) | 1280 +-+-+-+-+-+-+-+-+ | 1281 | | 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1283 | SlsAvail(1) | SlsIndex(1) | SlsId(2) | 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 | SchType(1) | StrDay(1) | StartTime(2) | 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 | EndDay(1) | EndTime(2) | | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1290 The second byte in the opcode is set appropriately to indicate 1291 that the service schedule attributes are being exchanged. The 1292 following fields are present in addition to the already 1293 explained : 1295 6.2.6.1 SchType 1297 This field indicates the type of the schedule. The schedule 1298 could be Immediate and dynamic (like the telephone 1299 connections), or periodic or advance reservation with start 1300 date-time and end date-time specified. 1302 Field Schedule Type 1303 ----- -------------- 1305 00000001 Immediate 1306 00000010 Periodic 1307 00000011 Advance reservation 1309 6.2.6.2 StrDay 1311 This field indicates the starting day of the service. The 1312 values are offset from the current day. For example, a value 1313 of 0 would indicate the current day and a value of 1 would 1314 indicate the next day. 1316 6.2.6.3 StartTime 1318 This field indicates the start time of the service on the 1319 day specified in the StrDay field. 1321 6.2.6.4 EndDay 1323 This field indicates the ending day of the service. The 1324 values are offset from the current day. 1326 6.2.6.5 EndTime 1328 This field indicates the ending time of the service on the 1329 day specified in the EndDay field. 1331 6.3 SLS_NEGO_REQUEST 1333 This message is used by the DSNP client to negotiate the QoS with a 1334 DSNP server. As in the SLS_LIST_RESPONSE message, the DSNP client 1335 starts by sending an initial SLS_NEGO_REQUEST message indicating 1336 the SLS attributes it wants to negotiate. Then subsequently, the 1337 DSNP client sends more messages with the actual SLS attributes. 1339 6.3.1 SLS_NEGO_REQUEST: Initial message 1341 0 1 2 3 1342 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 | op(2) | AttrMap(2) | 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 | UIDlen(1) | UID(variable) | 1347 +-+-+-+-+-+-+-+-+ | 1348 | | 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 | | 1351 | options(variable) | 1352 | | 1353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1355 The first octet in the opcode is set to "00000010" to indicate 1356 that it is a SLS_NEGO_REQUEST message. The second octet is set 1357 to "00000000" to indicate that this is the initial message in 1358 the negotiation. The AttrMap field is set suitably depending on 1359 the attributes the DSNP client wants to negotiate. 1361 6.3.2 SLS_NEGO_REQUEST: To negotiate the scope 1363 0 1 2 3 1364 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 | op(2) | AttrMap(2) | 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 | UIDlen(1) | UID(variable) | 1369 +-+-+-+-+-+-+-+-+ | 1370 | | 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1372 | NumIngRtr(2) | NumEgrRtr(2) | 1373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1374 | | 1375 | Ingress_list (variable) | 1376 | | 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1378 | | 1379 | Egress_list (variable) | 1380 | | 1381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 The first octet in the opcode is set to 0000010 to indicate that 1384 it is a SLS_NEGO_REQUEST and the second octet is set to 0000001 1385 to indicate that scope is being negotiated. The DSNP client 1386 sets appropriate values to other fields and sends the message to 1387 the DSNP server. 1389 6.3.2 SLS_NEGO_REQUEST: To negotiate the flow 1391 0 1 2 3 1392 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 | op(2) | AttrMap(2) | 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 | UIDlen(1) | UID(variable) | 1397 +-+-+-+-+-+-+-+-+ | 1398 | | 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 | Length (1) | FlowType(1) | NumFlows(1) | | 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 | Src IP address (4) | 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 | Dest IP address (4) | 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1406 | Proto(1) | DS Byte (1) | | 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 | source port number (4) | 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1410 | Destination port number (4) | 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 | | 1413 | Information about rest of the flows (variable) | 1414 | | 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 The first octet in the opcode is set to 0000010 to indicate that 1418 it is a SLS_NEGO_REQUEST and the second octet is set to 0000010 1419 to indicate that flow is being negotiated. The DSNP client sets 1420 appropriate values to other fields and sends the message to the 1421 DSNP server. 1423 6.3.3 SLS_NEGO_REQUEST: To negotiate the traffic description and 1424 conformance parameters 1426 0 1 2 3 1427 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 | op(2) | AttrMap(2) | 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 | UIDlen(1) | UID(variable) | 1432 +-+-+-+-+-+-+-+-+ | 1433 | | 1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 | SR (4) | 1436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1437 | BSS (4) | 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1439 | PR (4) | 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1441 | BSP (4) | 1442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 | EAR (4) | 1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1445 | M (4) | 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 | m (4) | 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 The first octet in the opcode is set to 0000010 to indicate that 1451 it is a SLS_NEGO_REQUEST and the second octet is set to 0000011 1452 to indicate that traffic conformance parameters are being 1453 negotiated. The DSNP client sets appropriate values to other 1454 fields and sends the message to the DSNP server. 1456 6.3.4 SLS_NEGO_REQUEST: To negotiate the performance guarantees 1458 0 1 2 3 1459 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 | op(2) | AttrMap(2) | 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 | UIDlen(1) | UID(variable) | 1464 +-+-+-+-+-+-+-+-+ | 1465 | | 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 |G| unused | QntDelayPercentile(3) | 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1469 | QntJitterPercentile (3) | QntMaxLoss(1) | 1470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 | QntMaxDelay (2) | QntMaxJitter(2) | 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1473 | QntAveDelay (2) | QntAveJitter(2) | 1474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1475 | QltDelay (1) | QltJitter(1) | QltLoss (1) | | 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1478 The first octet in the opcode is set to 0000010 to indicate that 1479 it is a SLS_NEGO_REQUEST and the second octet is set to 00000100 1480 to indicate that performance guarantee parameters are being 1481 negotiated. The DSNP client sets appropriate values to other 1482 fields and sends the message to the DSNP server. 1484 6.3.5 SLS_NEGO_REQUEST: To negotiate the service schedule 1486 0 1 2 3 1487 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 | op(2) | AttrMap(2) | 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 | UIDlen(1) | UID(variable) | 1492 +-+-+-+-+-+-+-+-+ | 1493 | | 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 | SchType(1) | StrDay(1) | StartTime(2) | 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1497 | EndDay(1) | EndTime(2) | | 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1499 The first octet in the opcode is set to 0000010 to indicate that 1500 it is a SLS_NEGO_REQUEST and the second octet is set to 00000101 1501 to indicate that the service schedule is being negotiated. The 1502 DSNP client sets appropriate values to other fields and sends 1503 the message to the DSNP server. 1505 6.4 SLS_NEGO_RESPONSE 1507 This message is sent by the DSNP server to the DSNP client in 1508 response to the SLS_NEGO_REQUEST. As in the SLS_NEGO_REQUEST 1509 message, the DSNP server starts by sending an initial 1510 SLS_NEGO_RESPONSE message indicating whether the request made by 1511 the DSNP client is accepted or not. If the request is accepted, the 1512 subsequent messages that follow confirm the parameters chose by the 1513 DSNP client. If the SLS_NEGO_REQUEST is not accepted, then the 1514 messages that follow tell the DSNP client the SLS that could be 1515 supported. 1517 6.4.1 SLS_NEGO_RESPONSE: Initial message 1519 0 1 2 3 1520 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 | op(2) | AttrMap(2) | 1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1524 | UIDlen(1) | UID(variable) | 1525 +-+-+-+-+-+-+-+-+ | 1526 | | 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1528 |A| unused | 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 | options(variable) | 1531 | | 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1534 The first octet in the opcode is set to 0000011 to indicate that 1535 it is a SLS_NEGO_RESPONSE and the second octet is set to 1536 00000000 to indicate that the initial response to the 1537 SLS_NEGO_REQUEST is being sent. All the fields are same as 1538 explained before but for the "A" field. 1540 6.4.1.1 A 1542 The A bit indicates whether the DSNP client's SLS request is 1543 accepted or not. If the A bit is set to '1', it means that 1544 the request was accepted. If the A bit is not set, it means 1545 that the request was not accepted. 1547 6.4.2 SLS_NEGO_RESPONSE: Sending the scope attributes 1549 0 1 2 3 1550 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1552 | op(2) | AttrMap(2) | 1553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1554 | UIDlen(1) | UID(variable) | 1555 +-+-+-+-+-+-+-+-+ | 1556 | | 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1558 |A| unused | 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1560 | NumIngRtr(2) | NumEgrRtr(2) | 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 | | 1563 | Ingress_list (variable) | 1564 | | 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 | | 1567 | Egress_list (variable) | 1568 | | 1569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1571 The first octet in the opcode is set to 0000011 to indicate that 1572 it is a SLS_NEGO_RESPONSE and the second octet is set to 1573 00000001 to indicate that the scope parameters are being sent. 1575 6.4.3 SLS_NEGO_REQUEST: Sending the flow attributes 1577 0 1 2 3 1578 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 | op(2) | AttrMap(2) | 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 | UIDlen(1) | UID(variable) | 1583 +-+-+-+-+-+-+-+-+ | 1584 | | 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 |A| unused | 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 | Length (1) | FlowType(1) | NumFlows(1) | | 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1590 | Src IP address (4) | 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 | Dest IP address (4) | 1593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1594 | Proto(1) | DS Byte (1) | | 1595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1596 | source port number (4) | 1597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 | Destination port number (4) | 1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 | | 1601 | Information about rest of the flows (variable) | 1602 | | 1603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 The first octet in the opcode is set to 0000011 to indicate that 1606 it is a SLS_NEGO_RESPONSE and the second octet is set to 1607 00000010 to indicate that the flow parameters are being sent. 1609 6.4.4 SLS_NEGO_REQUEST: Sending the traffic conformance and 1610 description attributes 1612 0 1 2 3 1613 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1615 | op(2) | AttrMap(2) | 1616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1617 | UIDlen(1) | UID(variable) | 1618 +-+-+-+-+-+-+-+-+ | 1619 | | 1620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 |A| unused | 1622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1623 | SR (4) | 1624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1625 | BSS (4) | 1626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1627 | PR (4) | 1628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1629 | BSP (4) | 1630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1631 | EAR (4) | 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1633 | M (4) | 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 | m (4) | 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 The first octet in the opcode is set to 0000011 to indicate that 1639 it is a SLS_NEGO_RESPONSE and the second octet is set to 1640 00000011 to indicate that the traffic conformance and 1641 description parameters are being sent. 1643 6.4.5 SLS_NEGO_REQUEST: Sending the performance guarantee attributes 1645 0 1 2 3 1646 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1648 | op(2) | AttrMap(2) | 1649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1650 | UIDlen(1) | UID(variable) | 1651 +-+-+-+-+-+-+-+-+ | 1652 | | 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 |A| unused | 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1656 |G| unused | QntDelayPercentile(3) | 1657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1658 | QntJitterPercentile (3) | QntMaxLoss(1) | 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 | QntMaxDelay (2) | QntMaxJitter(2) | 1661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1662 | QntAveDelay (2) | QntAveJitter(2) | 1663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1664 | QltDelay (1) | QltJitter(1) | QltLoss (1) | | 1665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1667 The first octet in the opcode is set to 0000011 to indicate that 1668 it is a SLS_NEGO_RESPONSE and the second octet is set to 1669 00000100 to indicate that the performance guarantee attributes 1670 are being sent. 1672 6.4.6 SLS_NEGO_REQUEST: Sending the service schedule attributes 1674 0 1 2 3 1675 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1677 | op(2) | AttrMap(2) | 1678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1679 | UIDlen(1) | UID(variable) | 1680 +-+-+-+-+-+-+-+-+ | 1681 | | 1682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 |A| unused | 1684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1685 | SchType(1) | StrDay(1) | StartTime(2) | 1686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1687 | EndDay(1) | EndTime(2) | | 1688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1690 The first octet in the opcode is set to 0000011 to indicate that 1691 it is a SLS_NEGO_RESPONSE and the second octet is set to 1692 00000101 to indicate that the service schedule attributes are 1693 being sent. 1695 6.5 SLS_STAT_REQUEST 1697 0 1 2 3 1698 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 | op(2) | unused | 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 | UIDlen(1) | UID(variable) | 1703 +-+-+-+-+-+-+-+-+ | 1704 | | 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 The first octet in the opcode field is set to 00000100 to indicate 1708 that this is a SLS_STAT_REQUEST message. The second octet is set to 1709 zero. Unlike other DSNP messages seen so far, only one 1710 SLS_STAT_REQUEST message is sent. 1712 6.6 SLS_STAT_RESPONSE 1714 0 1 2 3 1715 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1717 | op(2) | unused | 1718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1719 | UIDlen(1) | UID(variable) | 1720 +-+-+-+-+-+-+-+-+ | 1721 | | 1722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1723 | unused | QntDelayPercentile(3) | 1724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1725 | QntJitterPercentile (3) | QntMaxLoss(1) | 1726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1727 | QntMaxDelay (2) | QntMaxJitter(2) | 1728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1729 | QntAveDelay (2) | QntAveJitter(2) | 1730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1731 | OctSent(4) | 1732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1733 | OctRcvd (4) | 1734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1736 The first octet in the opcode field is set to 00000101 to indicate 1737 that this is a SLS_STAT_RESPONSE message. The second octet is set 1738 to zero. Like SLS_STAT_REQUEST message, only one SLS_STAT_RESPONSE 1739 is sent. The following fields are unique to SLS_STAT_RESPONSE 1740 message: 1742 6.6.1 OctSent 1744 This field indicates the total number of octets sent from the 1745 DSNP client. 1747 6.6.2 OctRcvd 1749 This field indicates the total number of octets forwarded to the 1750 DSNP client. 1752 7. Acknowledgments 1754 The authors wish to acknowledge the contributions of other members 1755 of the ITSUMO (Internet Technologies Supporting Universal Mobile 1756 Operation) team from Telcordia Technologies and Toshiba America 1757 Research Incorporated. 1759 (TM): ITSUMO (Internet Technology Supporting Universal Mobile 1760 Operation) is a trademark of Telcordia. It is a joint research 1761 project of Telcordia Technologies and Toshiba America Research Inc. 1762 (TARI). It envisions an end-to-end wireless/wireline IP platform 1763 for supporting real-time and non-real-time multimedia services in 1764 the future. Its goal is to use IP and third generation wireless 1765 technologies to design a wireless platform that allows mobile users 1766 to access multimedia services on a next generation Internet. In 1767 Japanese, ITSUMO means all the time, anytime. 1769 8. References 1771 [COPS00] D. Durham, et al., "The COPS (Common Open Policy Service) 1772 Protocol", IETF RFC 2748, Jan. 2000. 1774 [DHCP97] R. Droms, "Dynamic Host Configuration Protocol", IETF RFC 1775 2131, Mar. 1997. 1777 [DIFF01] D. Grossman, "New Terminology for Diffserv", IETF Internet 1778 Draft, , work in 1779 progress, Mar. 2001. 1781 [DIFF98] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and 1782 W. Weiss, "An Architecture for Differentiated Services", IETF 1783 RFC 2475, Dec. 1998. 1785 [DRCP00] A. McAuley, S. Das, S. Madhani, S. Baba, and Y. 1786 Shobatake, "Dynamic Registration and Configuration Protocol 1787 (DRCP)", IETF Internet Draft, , work 1788 in progress, Jul. 2000. 1790 [IMT97] ITU-R Rec. M.687-2, "International Mobile 1791 Telecommunications-2000 (IMT-2000)", 1997. 1793 [INT94] R. Braden, D. Clark, and S. Shenker, "Integrated Services 1794 in the Internet Architecture: an Overview", IETF RFC 1633, 1795 Jun. 1994. 1797 [ITSUMO00] ITSUMO Group, "Benchmarking of ITSUMO's All IP Wireless 1798 Architecture", mwif2000.028, Jan. 28, 2000. 1800 [ITSUMO99] ITSUMO Group, "Evolution of Wireless Telephony Towards 1801 Voice over 3G-IP", 3GPP2-P00-19990824-010, Aug. 23, 1999. 1803 [MEGACO00] F. Cuervo, et al., "Megaco Protocol Version 1.0", IETF 1804 RFC 3015, Nov. 2000. 1806 [NAI99] B. Aboba and M. Beadles, "The Network Access Identifier", 1807 IETF RFC 2486, Jan. 1999. 1809 [POLICY00] R. Yavatkar, et al., "A Framework for Policy-based 1810 Admission Control", IETF RFC 2753, Jan. 2000. 1812 [SNMP99] J. Case, et al., "Introduction to Version 3 of the 1813 Internet-standard Network Management Framework", IETF RFC 2570, 1814 Apr. 1999. 1816 9. Authors' Addresses 1818 Jyh-Cheng Chen 1819 Department of Computer Science 1820 National Tsing Hua University 1821 Hsinchu 300, Taiwan 1822 Phone: +886-3-574-2961 1823 Email: jcchen@cs.nthu.edu.tw 1825 Anthony J. McAuley 1826 Telcordia Technologies 1827 One Telcordia Drive, RRC-1A225 1828 Piscataway, NJ 08854-4157 1829 Phone: +1-732-699-2431 1830 Email: mcauley@research.telcordia.com 1832 Venkatesh Sarangan 1833 Department of Computer Science 1834 Oklahoma State University 1835 219 MSCS 1836 Stillwater, OK 74078 1837 Phone: +1-405-744-5672 1838 Email: saranga@cs.okstate.edu 1840 Shinichi Baba 1841 PC & Network Company 1842 Toshiba Corporation 1843 Shibaura 1-1-1, Minato-Ku 1844 Tokyo 105-8001, Japan 1845 Phone: +81-3-3457-2583 1846 Email: shinichi1.baba@toshiba.co.jp 1848 Yoshihiro Ohba 1849 Toshiba America Research, Inc. 1850 One Telcordia Drive 1851 Piscataway, NJ NJ 08854-4151 1852 Email: yohba@tari.toshiba.com 1854 Full Copyright Statement 1856 "Copyright (C) The Internet Society (2004). This document is 1857 subject to the rights, licenses and restrictions contained in BCP 1858 78, and except as set forth therein, the authors retain all their 1859 rights." 1861 "This document and the information contained herein are provided on 1862 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1863 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1864 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1865 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1866 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1867 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1868 PARTICULAR PURPOSE."