idnits 2.17.1 draft-gibson-sip-qos-resv-00.txt: ** The Abstract section seems to be numbered 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 expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 2320 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1999) is 8957 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 12 looks like a reference -- Missing reference section? '2' on line 44 looks like a reference -- Missing reference section? '3' on line 254 looks like a reference -- Missing reference section? '4' on line 65 looks like a reference -- Missing reference section? '5' on line 709 looks like a reference -- Missing reference section? '6' on line 116 looks like a reference -- Missing reference section? '7' on line 121 looks like a reference -- Missing reference section? '8' on line 277 looks like a reference -- Missing reference section? '9' on line 278 looks like a reference -- Missing reference section? '10' on line 278 looks like a reference -- Missing reference section? '11' on line 281 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 M. Gibson, J. Crowcroft 2 Internet Draft Nortel Networks, UCL 3 Document: draft-gibson-sip-qos-resv-00.txt October 1999 4 Category: Informational 6 Use of SIP for the Reservation of QoS guaranteed Paths 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026 [1]. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. Internet-Drafts are draft documents valid for a maximum of 17 six months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- Drafts 19 as reference material or to cite them other than as "work in 20 progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 23 The list of Internet-Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 26 1. Abstract 28 This draft defines a modification of the use of the SIP protocol to 29 perform route reservation. These modifications are applied to two of 30 the existing SIP Methods: INVITE and REGISTER. The modifications 31 allow the INVITE method to be used to find the best path across a 32 particular network based on QoS metrics. The route choice is able to 33 be restricted at the network edge. The proposed modifications also 34 allow the REGISTER method to be used as a means of disseminating 35 information necessary to determine these QoS metrics. This 36 information can be used to route INVITEs away from known areas of 37 congestion. 39 2. Conventions used in this document 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 43 this document are to be interpreted as described in RFC-2119 [2]. 45 Gibson Category Informational - Expiration April 1999 1 47 SIP Reservation Extensions October 1999 49 3. Protocol Context 51 The purpose of this draft is to propose that, with suitable 52 extensions, the SIP protocol may be used to perform path 53 determination and reservation across a QoS-capable IP network. 55 This draft defines a set of extended uses of the basic SIP protocol 56 the motivation for which can be found in [3], however this modified 57 functionality has a wider applicability. The purpose of the network 58 is to enable guaranteed QoS session establishment across an IP trunk 59 network between two separate LANs. The framework document describes 60 solution that can be decomposed into a three-layer model that is 61 repeated here as Figure 1. 63 The top Session Layer represents a telephony style connection model 64 with user connection stimulus being processed by a Call Server (CS). 65 These CSs may interact using either of ISUP [4] or SIP [5]. The use 66 of this layer is application specific being used by those 67 applications that generate telephony style signaling. 69 Session Control 70 +--+ +--+ 71 |CS|'''''''''''''''''ISUP/SIP'''''''''''''''''''''|CS| 72 +--+ +--+ 73 : : 74 megaco/H.248 megaco/H.248 75 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 76 : Core Management : 77 : /\ /\ /\ /\ /\ : 78 : -----|CM|-SIP----|CM|--SIP---|CM|------ : 79 : \/ \/ \/ \/ \/ : 80 : ! $ $ $ ! : 81 : COPS COPS COPS COPS COPS : 82 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 83 : ! Core Transport $ $ ! : 84 : ! $ $ $ ! : 85 +-----+ +--+ +--+ +--+ +-----+ 86 | EP |======|R1|========|R2|========|R3|======| EP | 87 +-----+\\ +--+\\ //+--+\\ //+--+ //+-----+ 88 \\ \\ // \\ // // 89 \\ \\// \\// // 90 \\ \/ \/ // 91 \\ /\ /\ // 92 \\ //\\ //\\ // 93 \\ // \\ // \\ // 94 +--+// \\+--+// \\+--+ 95 |R4|========|R5|========|R6| 96 +--+ +--+ +--+ 98 Figure 1 Extended SIP reference architecture 100 Gibson Category Informational - Expiration April 1999 2 102 SIP Reservation Extensions October 1999 104 The Session Layer connects directly to the Transport layer by means 105 of the emerging megaco protocol. This protocol is used by the CS to 106 instruct its endpoint (EP) to establish a new connection for a 107 particular session. In this mode of operation, the EP therefore 108 resembles a Media Gateway. 109 In those applications where a Session Layer is not present, the EP 110 will receive connection requests directly from the end-user, for 111 example a RSVP Path message, and in this case it resembles an IP 112 gateway router. 114 The Transport Layer consists of a number of known capacity links 115 capable of carrying IP traffic. The most likely solution being a set 116 of pre-configured LSPs across an MPLS [6] network. In the diagram, 117 where two tunnels meet, a LSR is pictured - however the LSP itself 118 may consist of a number of LSRs. 120 Whatever stimulus is used, the EP will request a path across the 121 Transport Layer using a COPS Request as specified in [7]. This is 122 sent to an Admission Manager (AM) in the Management Layer. The 123 Admission Managers are responsible for issuing requests for paths 124 across the network, processing these requests and issuing responses. 125 Only AMs can generate or terminate these message types. The COPS 126 interface is also used to carry the response to these requests. 128 The Management Layer also has a number of Connection Managers (CMs). 129 Note that AMs and CMs are collectively referred to as Management 130 Nodes (MNs). The CMs provide an administrative functionality to one 131 or more LSRs; namely they monitor the bandwidth along each of the 132 tunnels emanating from the LSRs they control and use this 133 information to decide whether a new session may be routed through 134 that tunnel. When a tunnel is established from a LSR, the LSR 135 indicates this to its associated CM using a suitably extended 136 version of COPS. When a session is admitted to or removed from a 137 tunnel, its new available bandwidth is updated. This information is 138 also forwarded to other Management Layer elements using an 139 advertising method on a periodic basis. 141 The proposed modifications to the SIP protocol contained within this 142 draft allow it to perform all messaging within the Management Layer. 143 They therefore provide for a route selection and bandwidth 144 reservation function between AMs and also a topology capacity 145 advertising function between all Management Layer elements. 147 3.1 Management layer elements 149 From Figure 1 it can be seen that there are three clearly 150 functionally different elements in the Management Layer: Admission 151 Manager, Edge Connection Manager and Core Connection Manager. It is 152 likely, however, in a real implementation that a single Management 153 Node might be required to perform at least two of these roles, 154 depending upon the physical topology of the Transport Network. 156 Gibson Category Informational - Expiration April 1999 3 158 SIP Reservation Extensions October 1999 160 Certainly, were an AM to be attached to the middle CM, it is easy to 161 see that this CM would continue to function as a Core CM to the 162 existing AMs, but as an Edge CM to the newly added AM. 164 This section will therefore define the functionality that the three 165 MN types will display. 167 3.1.1 Admission Manager 169 The Admission Manager is responsible for initiating and terminating 170 session requests. It controls access to the network via a COPS 171 interface to an Endpoint. It receives requests for new sessions over 172 this interface and issues Decision messages based on the outcome of 173 the resultant negotiation and any defined policies (these policies 174 are outside the scope of this document). 176 The AM will receive and must store the information contained within 177 topology advertisements to determine suitable paths for INVITE 178 messages. It will not generate any advertisements itself. The 179 advertising scheme operates such that the path to each of the Core 180 CMs and the congestion on each of these paths is well known. Each of 181 the reachable Core CMs also advertises the set of domains that can 182 be reached through it. The AM must store all of this information to 183 enable informed path choice. 185 The AM may also choose to store the complete 4-hop paths used to 186 reach particular destination AMs for re-use in subsequent INVITEs to 187 those AMs. This, however, has the drawback that the congestion 188 information along the length of these paths will be less well known 189 and that large information tables will have to be stored. However, 190 it does allow for a default path across the network to be specified 191 where known. 193 The AM is therefore able to perform session request blocking at the 194 edge of a network. If there is insufficient capacity on any of the 195 outgoing links the session request is automatically denied. 197 The AM must also store congestion information on incoming tunnels 198 too. This information is used in the selection of a session path 199 when multiple INVITEs are used. 201 3.1.2 Edge Connection Manager 203 An Edge Connection Manager has a peering relationship with an 204 Admission Manager. It is responsible for advertising a set of Core 205 CMs that is reachable by an AM. It must also advertise to its peer 206 Core CMs the set of AMs that it has connection to - this permits the 207 Core CM to build up its set of reachable domains. 209 In common with Core CMs, an Edge CM will operate in a similar manner 210 to a SIP proxy by processing and forwarding INVITEs. It will use the 212 Gibson Category Informational - Expiration April 1999 4 214 SIP Reservation Extensions October 1999 216 Record-Route header to ensure its continued presence in the return 217 signalling path. 219 3.1.3 Core Connection Manager 221 A Core Connection Manager has connections only to Edge CMs. A Core 222 CM must use the advertisements it receives from these Edge CMs to 223 determine the set of domains that it can reach. It must then 224 advertise this information in a broadcast manner such that it is 225 received by all AMs. (Note: it is the responsibility of the AM to 226 determine whether it has received a reachable domain message from a 227 MN that is one of its Core CMs). 229 As an AM will only have a clear picture of the network up to a Core 230 CM, when forming a path for an INVITE to traverse it is likely that 231 the next hop after the Core CM address will be wildcarded (See 232 section 5.2.4). The Core CM will be responsible for correctly 233 forwarding these INVITEs with wildcarded path values. 235 3.2 Applicability to non-MPLS Networks 237 Although the remainder of this draft will use the above MPLS-based 238 network as a basis for discussion, the SIP modifications proposed 239 are intended to allow operation over any QoS-capable IP network. 240 Providing a network of IP routers are connected by well-defined 241 Layer Two links whose capacity is well known, our proposal is 242 equally applicable. The term LSR can therefore be read as a 243 reference to any IP cross-connect between these Layer two links. 245 4. Basic Protocol Operation 247 This section shows the basic operation of the modified SIP protocol 248 within the network described above. The messaging used is outlined 249 along with the operation sequence. This is done by way of session 250 messaging examples. The exact content of the messages is dealt with 251 in later sections. 253 The descriptions of the following message types are based on the 254 four-hop network specified in [3] and pictured in Figure 1. In this 255 case the extended SIP protocol is seen to operate in the Core 256 Management Layer. 258 4.1 Set-up messaging example 260 The following is a simple example of the messaging used to establish 261 a session reservation and path within the Management Layer. 263 4.1.1 INVITE Generation 265 On receipt of a COPS Request, the AM will form one or more INVITE 266 messages. The process of forming this INVITE follows these steps: 268 Gibson Category Informational - Expiration April 1999 5 270 SIP Reservation Extensions October 1999 272 1) Before any route determination can take place, the AM must 273 determine the resource requirements of the new session. These may 274 come to it in a number of forms, carried by a suitably extended 275 version of COPS, namely: 277 - SDP [8] session description 278 - RSVP [9] TSPEC [10] 279 - RSVP ADSPEC 280 - RSVP FLOWSPEC 281 - CR-LDP [11] Traffic Resource TLV 282 - Simple Bandwidth Object 284 This information will be coupled with the destination information 285 and used to form a SDP description of the session (see section 5). 287 2)(Optional) The originating AM must assign the session a resource 288 class, where this parameter is used when advertising the tunnel 289 characteristics. The mechanism by which a resource class is 290 allocated is to be decided - as yet the MPLS drafts themselves give 291 no clear indication - but will probably be a function of media type, 292 the payment mechanism (where applicable), the DiffServ class or one 293 of a number of other parameters. 295 3) Examine available topology information and decide on a route. The 296 AM has a database that contains the information of all its 297 successful session paths plus the information from the advertising 298 REGISTERs that it has received. It can therefore use this 299 information to determine a route for the new session across the 300 network. The proposed extensions to the SIP protocol have been 301 designed such that an incomplete definition of this route can be 302 used. This is implemented by defining part of the path using 303 wildcard values. Note that the chosen path may not have sufficient 304 bandwidth for the session if either another session seizes the 305 resource, or the topology information is out of date, or the path is 306 incompletely specified. 308 4) Having chosen a path, the AM now assigns it a rank. This rank is 309 based on the AM's view of the congestion of the network, in 310 conjunction with any local policy in force. For example, it is 311 likely that the most favourable path to a particular destination 312 will be that with the lowest congestion. However, a more congested 313 link may have a lower latency and therefore be far more suitable to 314 a real-time session. Also, this allows economic rules to be applied 315 where different service providers own different sections of the 316 Transport Layer. In the case where only one INVITE is sent, the AM 317 may skip this part. 319 5) The AM must now form a SDP description of the session from the 320 description it is passed by the EP. This is attached to the INVITE 321 in the normal manner for SIP. 323 Gibson Category Informational - Expiration April 1999 6 325 SIP Reservation Extensions October 1999 327 6) The AM now forms one INVITE per path selected - the exact number 328 will be dependant on a local policy and may be restricted to reduce 329 the total signaling load on the network. The AM examines the first 330 address in the chosen path and forwards the INVITE to all CMs that 331 match this address. This uses a process like forking in standard 332 SIP. 334 4.1.2 INVITE processing at Connection Manager 336 When a CM receives an INVITE, it should perform the following 337 processing: 339 1) Examine the path list and determine if it has a connection to the 340 next hop in the path. If the CM does not have an outgoing tunnel to 341 the next listed CM, it must return an error message to that effect 342 to the originating AM. 344 2) The CM now examines the next but one MN in the path too, to 345 ensure this is reachable. Each advertising REGISTER traverses two 346 hops and therefore each CM should have topology information up to 347 two hops away. If none of the available next hop tunnels can be used 348 to reach this two-hop distant MN the CM returns an error message to 349 this effect. Intermediate MNs may read this error message on the 350 path back to the originating AM to update their topology 351 information. 353 3) The CM now examines the SDP description and determines the 354 resource requirements for the session. Where a choice of next hops 355 is available, the CM may use some policy information to pick how 356 many of the next hop tunnels will be used. Any tunnels that cannot 357 support the session are at this point discarded. 359 4) The CM can now determine the set of tunnels that can support the 360 session. The CM examines the Call-ID of the INVITE. If a temporary 361 reservation exists for this Call-ID, the tunnel already has 362 sufficient capacity for the session and may be used as a forward 363 path. No extra session bandwidth reservation need be made. 365 5) Otherwise the CM makes a temporary resource reservation for the 366 new session on each of the tunnels capable of supporting the 367 session. This reservation should match the requirements of the 368 session and will be tagged with the Call-ID of the INVITE that 369 prompted it. No other session may now be offered this part of the 370 tunnel resource. 372 6) The CM adds its SIP-URL into the Record Route header of the 373 INVITE and then forwards the INVITE to the MNs at the other end of 374 those tunnels. 376 This process is repeated at each CM along the route to the 377 destination AM. The INVITEs will thus fan out towards the centre of 378 the network and converge at the destination AM. 380 Gibson Category Informational - Expiration April 1999 7 382 SIP Reservation Extensions October 1999 384 4.1.3 INVITE processing at destination Admission Manager 386 The destination AM will probably receive a number of INVITEs, 387 depending on how tightly defined each original INVITE's path was, 388 how many INVITEs were sent and how may of the paths could be used. 389 These will arrive asynchronously, however the AM may process each 390 individually before issuing a response. The AM must perform the 391 following on each of the INVITEs: 393 1) Examine the Record-Route header and compare it to the topology 394 information the AM has stored. Using this topology information it 395 too assigns a rank to the path in the INVITE. Note this may result 396 in multiple ranks assigned to a single original INVITE due to 397 forking - identical Record Routes should have identical ranks. 399 2) By convolution with the original rank assigned by the originating 400 AM, the preferred path is chosen. This should happen after a time 401 period long enough to allow all INVITEs to arrive but short enough 402 to avoid too much setup latency. 404 3) The INVITE that contained the chosen path is now replied to with 405 a 200 OK. The Record-Route header is copied into a Route header to 406 direct the 200 OK through the MNs that forwarded the INVITE. The 407 same Call-ID must be used in this response, again copied from the 408 INVITE. 410 +--+ +--+ +--+ 411 ..1.>|CM|....1*....>|CM|. .>|CM|.3.. 412 . |11| . |24| . .##|31|<###. 413 . +--+ . +--+ 1* .# +--+ #. 414 . 1 . .200OK #. 415 /\. . .# #.>/\ 416 |AM| . .#. #|AM| 417 \/. . 3# . .>\/ 418 #. . .# . . 419 200OK. +--+ . +--+.# . +--+ . 420 #...2.>|CM|....2.....>|CM|...1......>|CM|.1/1* 421 ######|13|<##200OK###|29|<# |36| 422 +--+ +--+ +--+ 424 ...n... INVITE n Path 425 ####### 200OK Path 427 Figure 2. 200 OK operation 429 Gibson Category Informational - Expiration April 1999 8 431 SIP Reservation Extensions October 1999 433 4.1.4 Action of 200 OK Response 435 The 200 OK response is directed back over the same path as the 436 INVITE to which it is responding. At each CM in the path is has the 437 action of confirming the temporary resource reservation made by the 438 INVITE. This is achieved simply by correlating the Call-ID of the 439 response with the Call-ID used to tag of the temporary reservation. 440 The tag should not be discarded, as it will aid in the removal of 441 the reservation using a BYE message. The principle of this operation 442 can be seen in Figure 2. The left hand AM sends 2 INVITEs that get 443 routed over diverse paths to the destination AM. This AM chooses 444 INVITE 2 as the preferred route and issues a 200 OK back over the 445 same path. At each CM in this path the 200 OK confirms the temporary 446 reservation, made by the INVITE, for the duration of the session. 447 That is, until it is explicitly removed. 449 4.1.5 200 OK processing at originating Admission Manager 451 When the 200 OK is received at the originating AM it does the 452 following: 454 1) The AM makes the temporary reservation on the LSP to its Edge CM 455 permanent. The path across the network for the new session request 456 from the EP is now fully specified at the Connection Layer. 458 2) Replies to the EP using a COPS Decision, indicating that the 459 session reservation was successful. This message must contain the 460 list of LSRs that will support the session (and whose CMs have 461 accepted the session). The AM must therefore convert the SIP-URLs in 462 the Route header of the 200 OK into IP addresses. This will be 463 achieved through DNS lookup, either from the set of locally stored 464 values from previous sessions or from a central server. 466 3) If no 200 OK responses are received, the AM may either respond 467 with a COPS Decision rejecting the session, or try another set of 468 routes across the network by issuing further INVITEs. 470 4) To complete the INVITE process, an ACK is returned to the 471 destination AM, providing a 200 OK was received. This message is 472 purely informational. 474 Once the EP receives a COPS Decision, the session path can be 475 considered fully provisioned and the CR-LDP process can be initiated 476 using the returned LSR address list. 478 4.2 Session Tear-down example 480 This section gives an example of how session reservations are 481 removed as the session itself is torn-down. 483 4.2.1 Tear-down stimulus 485 Gibson Category Informational - Expiration April 1999 9 487 SIP Reservation Extensions October 1999 489 Either participant in the session can initiate the tear down of a 490 session. The stimulus for the removal will be a COPS Delete Request 491 State (DRQ) with the same Client Handle as a previously received 492 Request. The AM matches this to the original session Request and re- 493 uses the session information in the teardown process. 495 4.2.2 Originating AM action 497 The originating AM will correlate the Client Handle of the DRQ with 498 the Call-ID used to originally establish the reservation. A BYE will 499 now be issued with the corresponding Call-ID and will also include 500 the QoS characteristics used to establish the session, described 501 using SDP. 503 A Route header must be used in the BYE message that corresponds to 504 the route that the session has reserved across the network. This 505 should again be identified using the Client Handle as an index to a 506 table. 508 4.2.3 BYE operation at each CM 510 When a CM receives a BYE, it should remove from its set of confirmed 511 reservations, the one that corresponds to the Call-ID of the BYE. 512 The SDP description can be used as a fail-safe check of the resource 513 to be freed. 515 If it is unable to perform this then it must resolve the size of 516 reservation described by the SDP description. It must also examine 517 the next SIP-URL in the Route header to determine the tunnel along 518 which the original reservation was made. It then frees this amount 519 of resource from the tunnel. This is accomplished either by removing 520 a specific reservation identified by the Call-ID and re-calculating 521 the total bandwidth. 523 The CM then forwards the BYE to the next CM in the Route header. 525 4.2.4 Session Clearing notes 527 The Removal of reservations in the Management Layer can occur 528 concurrently with the removal of label mappings in the Transport 529 Layer. 531 The action of a BYE is unidirectional therefore a similar BYE must 532 be issued in the opposite direction to remove the other half of a 533 two-way session. The trigger for this will be provided by the 534 session application and signaled using a COPS DRQ at the other 535 Endpoint. 537 Gibson Category Informational - Expiration April 1999 10 539 SIP Reservation Extensions October 1999 541 4.3 Resource advertisement example 543 This section offers an overview of how SIP can be extended to 544 advertise topology information. This information includes the size 545 and destination of tunnels and the set of reachable domains via 546 particular CMs. 548 This advertisement mechanism will be implemented using the REGISTER 549 method that exists within SIP, modified such that the status of the 550 tunnel initially registered is regularly updated using a new message 551 body type that uses a similar syntax to that of SDP. 553 4.3.1 Initial tunnel advertisement 555 When a tunnel is established in the Transport Layer, its presence 556 must be indicated to the Management Layer in order for sessions to 557 be routed over it. The mechanism and reasons by which a tunnel is 558 initiated is outside of the scope of the document - it will likely 559 be driven by the owner of the network and may be caused by network 560 initialisation or re-provisioning. 562 Whatever the reason, the tunnel must always be established using a 563 known set of traffic parameters which are tightly controlled. Once 564 the tunnel exists, the LSR issues a COPS Request to its MN to 565 register the tunnel. The issuing of a COPS Decision is more of a 566 formality, as the MN is unlikely to refuse to allow the tunnel. The 567 Request must include at a minimum the address of the destination LSR 568 and the bandwidth of the tunnel. More likely it will include the 569 full description of its QoS parameters e.g. the Traffic TLV used by 570 CR-LDP. This information will be included in the message body. 572 When the MN has received this information, it must advertise it for 573 it to be of any use within the Management Layer. The MN that has 574 received the information will be at the upstream end of the tunnel 575 and will be controlling admission to the tunnel for sessions towards 576 the destination LSR. The MN must therefore perform a DNS lookup on 577 the IP address of the destination LSR to determine the SIP-URL of 578 the MN controlling it. It is this SIP-URL that will be used in the 579 advert. 581 The MN is now able to form a REGISTER message that it will send to 582 all of its peer MNs plus the MN that is the destination of the 583 tunnel. The contents of the REGISTER will be the resource 584 characteristics of the tunnel and the SIP-URLs of the MNs it runs 585 between. The purpose of this REGISTER message is twofold: 587 1) It establishes two-hop topology information in those upstream 588 (peer) MNs that receive the REGISTER. That is, each of these MNs now 589 has a route to the tunnel destination via the REGISTER sending MN. 591 2) It establishes a peering relationship with the MN at the 592 destination of the tunnel. On receipt of the REGISTER, the 594 Gibson Category Informational - Expiration April 1999 11 596 SIP Reservation Extensions October 1999 598 destination MN now knows that there is a new inbound tunnel to it 599 and therefore a new upstream MN that will want to receive its update 600 REGISTERs. 602 The above process can be seen in Figure 3. CM_X receives a COPS 603 Request for the new tunnel from LSR_X to LSR_Z. CM_X therefore forms 604 an REGISTER which it sends to its existing peer CM_Y telling it of 605 the new route. CM_X also sends the same REGISTER to CM_Z. The action 606 this time is to inform CM_Z that a new peering relationship should 607 be formed. 609 In general terms, if a MN receives a REGISTER that has a From: 610 header containing the URI of a MN it does not recognise, this should 611 be regarded as a request for peering from that MN. 613 Peering REGISTER messages should be sent to the new peer directly, 614 not multicast. A MN without a peer relationship will ignore 615 multicast REGISTERs from a MN it is not yet the peer of, as it has 616 not been told to listen for them. 618 +----+ +----+ +----+ 619 |CM_Y|<===new route===|CM_X|==new peering==>|CM_Z| 620 +----+ +----+ +----+ 621 ^ 622 | 623 | 624 REQ: tunnel CM_X->CM_Z 625 | 626 | 627 _______________ | ________________ 628 (LSR)()______________)(LSR)()_______________)(LSR) 629 Existing tunnel New Tunnel 631 Figure 3. Action of Tunnel Advert 633 4.3.2 Tunnel update advertisement 635 Each MN must update the information about the capacity of each of 636 its tunnels on a regular basis. This information should be sent to 637 each of its peers based on the following metrics: 639 Time - as a baseline, each MN must send an advertising REGISTER 640 on a regular basis at the expiry of a timer - every time an 641 advertising REGISTER is sent, the timer should be restarted; 643 Gibson Category Informational - Expiration April 1999 12 645 SIP Reservation Extensions October 1999 647 Activity - a MN may choose to send a new advert based on a 648 number of INVITE/BYE messages; 650 Resource - every time there is a significant change in tunnel 651 resource a MN may choose to send a new ADVERT. 653 Once a peering relationship is established, the same Call-ID for 654 each subsequent REGISTER to the same peer should be retained to 655 allow easy tunnel identification. The CSeq header should be used to 656 indicate an updated value. The peer should always use the 657 advertising REGISTER information with the highest CSeq value and 658 discard all lower value REGISTERs with the same Call-ID. Multiple 659 tunnel descriptions can be included in a single REGISTER as each 660 description is self-contained (See section 5.3.2) however care 661 should be taken that the total message length does not get too long. 663 As the tunnel advert information is contained in a message body, the 664 update information could be piggybacked on other messages as they 665 traverse the network to reduce the total messaging. 667 4.3.3 Reachable domain advertisement 669 Over time, a MN will build up a view of the domains it is two hops 670 distant from, based on the REGISTERs it receives from its peers. 671 This information may be advertised too to aid route selection and 672 ranking. This information should be cascaded back to the edges of 673 the Management Layer to the AMs. The To header of each domain 674 REGISTER will be formed from the end descriptor of the tunnel 675 adverts the Core CM receives. The SIP-URL used in the To header may 676 only ever have a MN-type of AM (see section 5.3.2 for details). 678 When an AM is choosing a route to a destination AM, it will only 679 have detailed topology information for the first two hops of the 680 journey to a set of reachable Core CMs. It therefore is essential 681 that the AM knows the set of nodes reachable from each of these Core 682 CMs so that the final two MNs in the path to the destination AM can 683 be determined. 685 The domain information can be gleaned by examining the domain 686 segment of the destination SIP-URL from a tunnel advertisement. A 687 Core CM is capable of choosing an onward route for an INVITE based 688 on its topology information, so by sending an INVITE via a certain 689 Core CM and allowing (through wildcarding) the CM to choose the 690 route for the final two hops of the path, the AM can reduce the 691 total amount of information it needs to store. 693 5. Protocol details 695 Gibson Category Informational - Expiration April 1999 13 697 SIP Reservation Extensions October 1999 699 The aim of this section is to describe in some detail the format and 700 use of the messages described in brief above. It will concentrate on 701 the areas where there is significant divergence from the standard 702 operation of SIP, either in operation or interpretation of fields, 703 and on the key message elements used where operation is similar. 705 5.1 Standard SIP 707 The message format of the standard SIP protocol, represented using 708 Augmented Backus-Naur format (ABNF, as described in Appendix C of 709 [5]), is as follows: 711 generic-message = start-line 712 *message-header 713 CRLF 714 [ message body ] 716 start-line = Request-Line | 717 Status-Line 719 message-header = ( general-header 720 | request-header 721 | response-header 722 | entity header ) 724 The first element is always a start-line, which can be either 725 Request line or Status line. Generally a Request line describes the 726 SIP method that the message is instigating and the Status line shows 727 the nature of a response to such a message. The Request line has the 728 following format: 730 Request-Line = Method SP Request-URI SP SIP-Version CRLF 731 e.g. INVITE sip:mark@nortelnetworks.com SIP/2.0 733 This would be for an INVITE from mark@nortelnetworks.com using 734 version 2.0 of the SIP software. For a response to this INVITE, the 735 following might be used as the Status-Line of the message: 737 Statue-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF 738 e.g. SIP/2.0 200 OK 740 in this case an OK response that has a Status-Code of 200. 742 After the start-line there are multiple message-headers (denoted by 743 the * in ABNF) that can be any of the shown types except that a 744 request-header is specific to a request and similarly a response- 745 header is specific to a response message. This draft proposes a 746 number of changes to the standard set of these headers as detailed 747 in section 5.3. 749 Gibson Category Informational - Expiration April 1999 14 751 SIP Reservation Extensions October 1999 753 Finally, in the generic message, comes any message body attached to 754 the message. The format and length of the body type is described by 755 the entity-headers at the end of the message-header list. A message 756 body is attached in native format, hence a SDP body is included 757 using its standard text-description. In order to accommodate 758 capacity advertisements we will describe an additional advert body 759 type. 761 5.1.1 Change of INVITE meaning 763 The meaning of the INVITE message is changed when compared to the 764 standard SIP protocol. Under normal operation, this message is used 765 to invite the called party to join a session and indicates the type 766 of media that the caller can receive. The indication of what is to 767 be sent is an option. 769 The INVITE is now used to make a forward reservation for the session 770 from the caller. Therefore the session description contained within 771 the INVITE is that for the forward direction and should be used to 772 reserve bandwidth in tunnels from the caller to the callee. 774 5.1.2 Change of REGISTER use 776 The REGISTER method is currently used to register the address listed 777 in the To header with a SIP server. This draft proposes two 778 alterations to the use of the message. 780 In the link advertisement we REGISTER the existence of a link to the 781 location described by the To header and advertise its available 782 capacity. The description of this path is then included in a new 783 message body type, as described in section 5.3.2. 785 Secondly, the set of domains reachable via a particular CM is 786 registered with other MNs. In this instance the To header has no 787 real meaning, with the information stored in the reachable domains 788 body type attached to the REGISTER message, as described in section 789 5.3.3. 791 To accommodate this functionality, all MNs must operate as 792 Registration servers for both path and reachable domain REGISTER 793 messages. These REGISTER messages should be sent using a different 794 multicast address than the well-known "all SIP servers" address 795 "sip.mcast.net" (224.0.1.75). It is suggested that two new well- 796 known addresses be used: "sip-path.mcast.net" for path REGISTER 797 messages; "sip-domain.mcast.net" for reachable domain REGISTER 798 messages. 800 To control the level of signalling information present in the 801 network, the REGISTER messages must be controlled using the TTL 802 field. It is recommended that in the 4-hop network shown in Figure 803 1, the value TTL = 1 be used for path REGISTER messages and TTL = 2 804 for reachable domain messages. 806 Gibson Category Informational - Expiration April 1999 15 808 SIP Reservation Extensions October 1999 810 The information in both new REGISTER message types must be 811 periodically updated without the need for outside stimulus. Updates 812 will be indicated by an increased CSeq. Previously stored 813 information must be discarded and the new information used instead. 815 5.2 Message formats 817 We now address the specific SIP headers that need to be modified to 818 allow path reservation described within this draft to be performed. 819 Also included in this section is the details of the single new 820 header type required. 822 5.2.1 From header 824 The From header takes the standard SIP form. It will only ever have 825 the SIP-URL of the Admission Manager that is originating the INVITE 826 or of the Connection Manager originating the REGISTER method. To aid 827 the determination the MN-type originating the message, it is 828 recommended that the tag is used to identify the type of MN node 829 originating the message. 831 The From header also has a vital role in the establishment of a 832 peering relationship between adjacent Management Nodes. If a path 833 REGISTER is received with a SIP-URL in its From header of a 834 Management Node that the receiving Management Node does not already 835 have a peering relationship with, the SIP-URL must be added to its 836 peer list. 838 The from header takes the standard SIP form as described below: 840 From = ( "From" | "f" ) ":" ( name-addr | addr-spec) 841 *( ";" addr-params ) 842 name-addr = [display name] "<" addr-spec ">" 843 addr-spec = SIP-URL|URI 844 display-name = *token|quoted-string 845 addr-params = tag-param 846 tag-param = "tag=" UUID 847 UUID = 1*( hex | "-" ) 849 e.g. From: "M. Gibson" ; tag=AM 851 The above example shows that the message originated from user mrg 852 whose SIP application has AM functionality. 854 5.2.2 To header 856 The main part of the To header is used in the normal SIP manner. It 857 will only ever contain the address of the Admission Manager that is 858 the destination of the INVITE. 860 Gibson Category Informational - Expiration April 1999 16 862 SIP Reservation Extensions October 1999 864 The use of the tag part, however, is to be changed to accommodate 865 the formation of multiple INVITEs for a particular session. It will 866 be used to indicate which of how many total INVITEs for the session 867 this INVITE is. 869 The To address takes the standard SIP form as described below: 871 To = ( "To" | "t" ) ":" ( name-addr | addr-spec) 872 *( ";" addr-params ) 873 addr-params = tag-param|alternate-param 874 alternate-param = instance "(" total ")" ;instance <= total 875 instance = 1*digit 876 total = 1*digit 878 e.g. To: sip:j.bloggs@sip.net; tag=2(4) 880 The above example is for an INVITE to j.bloggs and indicates that 881 this is the second of four different INVITEs. 883 5.2.3 Record-Route header 885 The Record-Route header is formed in the exact same manner as normal 886 SIP. It must always be used in an INVITE to allow determination of 887 the path over which reservation is being made. 889 The Record-Route header will never be used in an ADVERT message 890 type. The Record-Route header takes the standard SIP form as 891 described below: 893 Record-Route = "Record-Route" ":" 1# name-addr 895 e.g Record-Route: , 896 898 This indicates that the request has traversed the host ieee.org then 899 bell-telephone.com. 901 5.2.4 Route header 903 The Route header is used in an INVITE to define the path it should 904 take across the network. In contrast to normal SIP, the list of SIP- 905 URLs may contain non-explicit information. E.g. *@domain.name.com is 906 an acceptable value. Where this is used, the INVITE may be forwarded 907 to all MNs that match the non-asterisked parts of the SIP-URL. The 908 determination of which of these MNs to use is performed using the 909 topology information stored by the MN in conjunction with the next 910 element in the Route header. Only those matches that provide a route 911 to the two-hop distant SIP-URL may be used. The chosen value is 912 written into the Record-Route header as above. The Route header uses 913 the standard SIP form as described below: 915 Route = "Route" ":" 1# name-addr|wildcard-addr 917 Gibson Category Informational - Expiration April 1999 17 919 SIP Reservation Extensions October 1999 921 Wildcard-addr = "*@" *("*" | domainlabel ".") ("*" | toplabel 922 [ "." ]) 924 e.g Route: , 925 927 The Route header of an INVITE should be discarded by the AM that 928 receives it. Only the Record-Route header will contain useful route 929 information. 931 It is recommended that the Route header is not used in REGISTER 932 messages, thereby reducing the packet size and therefore signaling 933 overhead within the Management Layer. 935 5.2.4.1 Wildcard Usage 937 The SIP-URL contained in a Route header may be replaced in total or 938 just part by a wildcard value, as illustrated in the ABNF rule 939 above. This allows the originator to direct an INVITE through a 940 particular domain but to allow local SIP servers to determine the 941 path across that domain. 943 Where the whole of a Route element is wildcarded the INVITE may be 944 forwarded over any next hop, provided that there is a route to the 945 next but one Route element via the chosen next hop. This forwarding 946 decision should be made using the reachable domain information 947 REGISTER'd for this next hop. See Annex B for further usage 948 examples. 950 The Route header must always contain the SIP_URL of the destination 951 AM its last element. It must never be wildcarded. This ensures that 952 looping is avoided and allows the looping detection afforded by the 953 use of Via headers to be suppressed. Where there is any doubt about 954 the address of the destination AM, the originating AM must set the 955 TTL header of an INVITE such that it will time-out shortly after it 956 should have reached its destination. In the four-hop network 957 example, this implies a TTL=5. 959 5.2.5 No-Loop header 961 The use of wildcards within the route header allows INVITEs to 962 diverge and then converge at the same point as they travel across a 963 network. Under normal operation, SIP proxies will add Via headers to 964 allow for loop detection. However, this would suppress the multiple 965 route finding function that the wildcarded Route header introduces. 966 A No_Loop header is therefore introduced to suppress this action: 968 No-Loop = "noloop" 970 Care must obviously be taken when using this header that looping is 971 not introduced. By use of the reachable domains message body and the 972 Route header it is possible to ensure that looping is avoided by 974 Gibson Category Informational - Expiration April 1999 18 976 SIP Reservation Extensions October 1999 978 rejecting INVITEs whose next-hop Route SIP-URL cannot be reached 979 through the current MN. 981 5.3 Body formats 983 This section sets out the body formats needed to perform session 984 reservations. Firstly the extensions needed to SDP are detailed. 985 Then secondly the two new message body types needed to implement 986 advertisement are detailed. 988 5.3.1 SDP extensions 990 To exploit SDP so that it properly most profitably interworks with 991 the modified SIP protocol proposed within this draft, both the 992 bandwidth (b) and session information (i) fields need an extended 993 useage and new fields of route favourability (f) and resource class 994 (r) need to be defined. 996 5.3.1.1 Bandwidth (b) 998 The current bandwidth definition used by the SDP protocol is used to 999 indicate only the required bandwidth in kilobits per second of the 1000 session. While this may sufficient for simple implementations, there 1001 is a need to support more complex description of the session to make 1002 better use of an MPLS or similar tunnel technology. This also allows 1003 for a better mapping of RSVP TSpec and FlowSpec and CR-LDP Traffic 1004 TLV parameters. 1006 The bandwidth description will be in terms of the policed session 1007 flow from the AM. As the AM will tell the EP what committed rates 1008 the network will offer, the AM need only use these rates in INVITE. 1009 The process by which the committed rates are derived from the 1010 requested rates is outside the scope of this document. 1012 The 3-tuple that defines the peak and maximum date rates is 1013 therefore defined to be used in the bandwidth description 1014 containing: 1016 Data rate - the mean data rata of the application. (This correlates 1017 roughly to the Token Bucket Rate of RSVP and PDR parameter of CR-LDP 1018 Traffic TLV.) 1019 Peak rate - the peak data rate of the application. (This correlates 1020 roughly to the Token Bucket Size of RSVP and PBR parameter of CR-LDP 1021 Traffic TLV.) 1022 Burst rate - either the maximum burst rate that the application 1023 might produce, or the maximum burst size that a tunnel can support. 1024 (This correlates roughly to the Peak Data Rate of RSVP and EBS 1025 parameter of CR-LDP Traffic TLV.) 1027 The syntax for this SDP description is as shown: 1028 b= 1030 Gibson Category Informational - Expiration April 1999 19 1032 SIP Reservation Extensions October 1999 1034 5.3.1.1.1 Peak vs Burst rate 1036 The use of the Peak and Burst Rate parameters will depend on the 1037 context of the bandwidth parameter. In an INVITE, the bandwidth 1038 parameter will be used to describe the session requirements. 1039 Therefore the Peak rate and Burst rate should be a good match to 1040 each other as the AM will provide a policing function for the 1041 session. 1043 In an ADVERT the Peak rate may be used to indicate a preferred 1044 maximum burst rate for new sessions and the Burst rate can indicate 1045 the maximum rate that the tunnel can support. A tunnel may therefore 1046 accept a session with a higher Peak rate than the advertised burst 1047 rate - this will probably have the action of reducing the advertised 1048 Burst rate next time around. 1050 5.3.1.2 Information (i) 1052 The information description of SDP can be used to convey the same 1053 information as the tag used in the To header. Namely which of 1054 multiple INVITEs this message is. This implies that the INVITEs are 1055 forked at the originating AM using Route headers, which may not sit 1056 comfortably with the SIP standard. However, it does allow a single 1057 200 OK to be legitimately issued for all the different paths and 1058 keeps the differentiation at the session level. 1060 The syntax for this SDP description is as shown: 1062 i= of 1064 Where m < n and n is the maximum number of different routes that an 1065 AM may attempt reservation over. 1067 5.3.1.3 Favourability (f) 1069 This type is used to indicate the rank or favourability of the route 1070 in the INVITE for a particular session, as perceived by the 1071 originating AM. The higher the value assigned, the more favourable 1072 the route is. It is recommended that this be an integer value with a 1073 pre-agreed maximum value. The method for deriving the favourability 1074 value and how it is interpreted by the receiving AM is beyond the 1075 scope of this document. 1077 The syntax for this description is as shown below: 1079 f= 1081 5.3.1.4 Resource Class (r) 1083 The resource class will be decided by the AM for a particular 1084 session and used in MPLS networks where multiple tunnels exist 1086 Gibson Category Informational - Expiration April 1999 20 1088 SIP Reservation Extensions October 1999 1090 between LSRs. It must be included in all INVITEs to enable suitable 1091 route choice. 1093 The syntax for this description is as shown below: 1095 r= 1097 When used in an INVITE, every effort must be made to match the 1098 resource class of the INVITE sdp with that of the tunnel the session 1099 is to be forwarded along. 1101 5.3.2 Advert body type 1103 The Advert body type is used to advertise the existence of a tunnel 1104 between two LSRs and will be carried by a REGISTER message. It is 1105 sent initially to announce the establishment of a new tunnel - part 1106 of the peering establishment operation - and then subsequently to 1107 update the spare capacity it has left. 1109 The Advert body type takes the same basic syntax form as the SDP 1110 protocol and has six descriptors: 1112 Start [s] - the starting LSR of the tunnel 1113 End [e] - the end or terminating LSR of the tunnel 1114 Total Capacity [c*] - the total size of the tunnel 1115 Free Capacity [f] - the available capacity of the tunnel 1116 Latency [l*] - the time taken to traverse the tunnel 1117 Resource Class [r*] - the resource class of the traffic carried by 1118 the tunnel. 1120 The descriptors marked with an asterisk are all optional in every 1121 Advert and their use will depend upon the complexity of the network 1122 and the parameters used to make routing decisions. This set of 1123 descriptors is not seen as necessarily definitive and there is scope 1124 to add further descriptors as required. 1126 Each of the above descriptors will now be dealt with in more depth 1127 in the following sub-sections. 1129 5.3.2.1 Start [s] descriptor 1131 This is used to indicate the LSR (or other Layer Two element) at the 1132 beginning of the path being advertised. The Start descriptor must 1133 always be present in an advert message body. Note: the tunnel is 1134 seen as running from the start to the end such that the start 1135 performs the label mapping of incoming session packets to send them 1136 to the end. 1138 Gibson Category Informational - Expiration April 1999 21 1140 SIP Reservation Extensions October 1999 1142 Although it is the LSRs that form the tunnel's endpoints, it is the 1143 SIP-URL of the MN controlling the LSR at the start of the tunnel 1144 that is advertised. This simplifies the peering process and allows 1145 multiple different LSRs controlled by the same MN to appear as one 1146 super-LSR. The SIP-URL used to describe the start of the tunnel will 1147 be that of the MN controlling the LSR. The syntax for the Start 1148 descriptor is shown below: 1150 s= 1151 e.g. s=CM_london@SIP.co.uk 1153 There is no assumed policy for the allocation of SIP-URLs to 1154 describe the endpoints of a tunnel and is left flexible to allow 1155 tailoring to particular situations and architectures. 1157 5.3.2.2 End [e] descriptor 1159 The End descriptor is used to indicate the destination of the path 1160 being advertised. It must always be present in an advertisement. 1162 As each advertisement is sent by a MN to each of its peers, the End 1163 descriptor not only describes the path destination but also provides 1164 reachable domain information as the destination MN of the path is 1165 two hops distant from each of these peers. A CM that is acting as a 1166 Core CM should therefore log all advertisements that emanate from 1167 AM-type SIP-URLs. 1169 The End descriptor has the following syntax: 1171 e= 1172 e.g. e=AM_Paris@SIP.fr 1174 5.3.2.3 Total Capacity [c] descriptor 1176 The total capacity descriptor indicates the size of the path being 1177 advertised in terms of its bandwidth. The same 3-tuple used in the 1178 extended bandwidth descriptor for SDP is re-used here. The tunnel is 1179 therefore described in terms of: 1181 Total data rate (kbps) - essentially the capacity of the path 1183 Preferred peak rate (kbps) - the preferred maximum session burst 1184 rate 1186 Maximum allowable data burst (kbps) - the largest burst the path can 1187 handle. 1189 This descriptor is optional in all Adverts as in the most part, the 1190 useful information when forwarding an INVITE is the free tunnel 1191 capacity. If advertising the total capacity is deemed necessary, it 1192 is recommended that the total capacity be sent only once in an 1194 Gibson Category Informational - Expiration April 1999 22 1196 SIP Reservation Extensions October 1999 1198 initial REGISTER and only re-sent if it changes during the lifetime 1199 of the tunnel. 1201 The syntax for the total capacity descriptor is: 1203 c= 1204 e.g. c=10000 50 200 1206 5.3.2.4 Free Capacity [f] descriptor 1208 The free capacity descriptor is mandatory in all tunnel REGISTER 1209 messages. It uses the same format as the tunnel capacity descriptor 1210 but advertises the free or available capacity of the tunnel. 1212 The syntax for the free capacity descriptor is: 1214 f= 1215 e.g. f=300 40 200 1217 While the maximum allowable data burst size will likely remain 1218 constant, if a large number of bursty sessions have already been 1219 routed along the path, the preferred peak/burst rate may be reduced 1220 to inhibit the admission of further bursty sessions. The available 1221 data rate will indicate the amount of free bandwidth along the path. 1223 5.3.2.5 Latency [l] descriptor 1225 The latency descriptor describes the time taken to traverse the path 1226 and is optional. As with the total path capacity, this figure is 1227 unlikely to change over time and so where used it need only be sent 1228 once, unless the path changes - note resizing of the path will 1229 likely have no effect. 1231 The latency descriptor will have the following syntax: 1233 l=