M. Gibson, J. Crowcroft Internet Draft Nortel Networks, UCL Document: draft-gibson-sip-qos-resv-00.txt October 1999 Category: Informational Use of SIP for the Reservation of QoS guaranteed Paths Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This draft defines a modification of the use of the SIP protocol to perform route reservation. These modifications are applied to two of the existing SIP Methods: INVITE and REGISTER. The modifications allow the INVITE method to be used to find the best path across a particular network based on QoS metrics. The route choice is able to be restricted at the network edge. The proposed modifications also allow the REGISTER method to be used as a means of disseminating information necessary to determine these QoS metrics. This information can be used to route INVITEs away from known areas of congestion. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Gibson Category Informational - Expiration April 1999 1 SIP Reservation Extensions October 1999 3. Protocol Context The purpose of this draft is to propose that, with suitable extensions, the SIP protocol may be used to perform path determination and reservation across a QoS-capable IP network. This draft defines a set of extended uses of the basic SIP protocol the motivation for which can be found in [3], however this modified functionality has a wider applicability. The purpose of the network is to enable guaranteed QoS session establishment across an IP trunk network between two separate LANs. The framework document describes solution that can be decomposed into a three-layer model that is repeated here as Figure 1. The top Session Layer represents a telephony style connection model with user connection stimulus being processed by a Call Server (CS). These CSs may interact using either of ISUP [4] or SIP [5]. The use of this layer is application specific being used by those applications that generate telephony style signaling. Session Control +--+ +--+ |CS|'''''''''''''''''ISUP/SIP'''''''''''''''''''''|CS| +--+ +--+ : : megaco/H.248 megaco/H.248 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ : Core Management : : /\ /\ /\ /\ /\ : : -----|CM|-SIP----|CM|--SIP---|CM|------ : : \/ \/ \/ \/ \/ : : ! $ $ $ ! : : COPS COPS COPS COPS COPS : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ : ! Core Transport $ $ ! : : ! $ $ $ ! : +-----+ +--+ +--+ +--+ +-----+ | EP |======|R1|========|R2|========|R3|======| EP | +-----+\\ +--+\\ //+--+\\ //+--+ //+-----+ \\ \\ // \\ // // \\ \\// \\// // \\ \/ \/ // \\ /\ /\ // \\ //\\ //\\ // \\ // \\ // \\ // +--+// \\+--+// \\+--+ |R4|========|R5|========|R6| +--+ +--+ +--+ Figure 1 Extended SIP reference architecture Gibson Category Informational - Expiration April 1999 2 SIP Reservation Extensions October 1999 The Session Layer connects directly to the Transport layer by means of the emerging megaco protocol. This protocol is used by the CS to instruct its endpoint (EP) to establish a new connection for a particular session. In this mode of operation, the EP therefore resembles a Media Gateway. In those applications where a Session Layer is not present, the EP will receive connection requests directly from the end-user, for example a RSVP Path message, and in this case it resembles an IP gateway router. The Transport Layer consists of a number of known capacity links capable of carrying IP traffic. The most likely solution being a set of pre-configured LSPs across an MPLS [6] network. In the diagram, where two tunnels meet, a LSR is pictured - however the LSP itself may consist of a number of LSRs. Whatever stimulus is used, the EP will request a path across the Transport Layer using a COPS Request as specified in [7]. This is sent to an Admission Manager (AM) in the Management Layer. The Admission Managers are responsible for issuing requests for paths across the network, processing these requests and issuing responses. Only AMs can generate or terminate these message types. The COPS interface is also used to carry the response to these requests. The Management Layer also has a number of Connection Managers (CMs). Note that AMs and CMs are collectively referred to as Management Nodes (MNs). The CMs provide an administrative functionality to one or more LSRs; namely they monitor the bandwidth along each of the tunnels emanating from the LSRs they control and use this information to decide whether a new session may be routed through that tunnel. When a tunnel is established from a LSR, the LSR indicates this to its associated CM using a suitably extended version of COPS. When a session is admitted to or removed from a tunnel, its new available bandwidth is updated. This information is also forwarded to other Management Layer elements using an advertising method on a periodic basis. The proposed modifications to the SIP protocol contained within this draft allow it to perform all messaging within the Management Layer. They therefore provide for a route selection and bandwidth reservation function between AMs and also a topology capacity advertising function between all Management Layer elements. 3.1 Management layer elements From Figure 1 it can be seen that there are three clearly functionally different elements in the Management Layer: Admission Manager, Edge Connection Manager and Core Connection Manager. It is likely, however, in a real implementation that a single Management Node might be required to perform at least two of these roles, depending upon the physical topology of the Transport Network. Gibson Category Informational - Expiration April 1999 3 SIP Reservation Extensions October 1999 Certainly, were an AM to be attached to the middle CM, it is easy to see that this CM would continue to function as a Core CM to the existing AMs, but as an Edge CM to the newly added AM. This section will therefore define the functionality that the three MN types will display. 3.1.1 Admission Manager The Admission Manager is responsible for initiating and terminating session requests. It controls access to the network via a COPS interface to an Endpoint. It receives requests for new sessions over this interface and issues Decision messages based on the outcome of the resultant negotiation and any defined policies (these policies are outside the scope of this document). The AM will receive and must store the information contained within topology advertisements to determine suitable paths for INVITE messages. It will not generate any advertisements itself. The advertising scheme operates such that the path to each of the Core CMs and the congestion on each of these paths is well known. Each of the reachable Core CMs also advertises the set of domains that can be reached through it. The AM must store all of this information to enable informed path choice. The AM may also choose to store the complete 4-hop paths used to reach particular destination AMs for re-use in subsequent INVITEs to those AMs. This, however, has the drawback that the congestion information along the length of these paths will be less well known and that large information tables will have to be stored. However, it does allow for a default path across the network to be specified where known. The AM is therefore able to perform session request blocking at the edge of a network. If there is insufficient capacity on any of the outgoing links the session request is automatically denied. The AM must also store congestion information on incoming tunnels too. This information is used in the selection of a session path when multiple INVITEs are used. 3.1.2 Edge Connection Manager An Edge Connection Manager has a peering relationship with an Admission Manager. It is responsible for advertising a set of Core CMs that is reachable by an AM. It must also advertise to its peer Core CMs the set of AMs that it has connection to - this permits the Core CM to build up its set of reachable domains. In common with Core CMs, an Edge CM will operate in a similar manner to a SIP proxy by processing and forwarding INVITEs. It will use the Gibson Category Informational - Expiration April 1999 4 SIP Reservation Extensions October 1999 Record-Route header to ensure its continued presence in the return signalling path. 3.1.3 Core Connection Manager A Core Connection Manager has connections only to Edge CMs. A Core CM must use the advertisements it receives from these Edge CMs to determine the set of domains that it can reach. It must then advertise this information in a broadcast manner such that it is received by all AMs. (Note: it is the responsibility of the AM to determine whether it has received a reachable domain message from a MN that is one of its Core CMs). As an AM will only have a clear picture of the network up to a Core CM, when forming a path for an INVITE to traverse it is likely that the next hop after the Core CM address will be wildcarded (See section 5.2.4). The Core CM will be responsible for correctly forwarding these INVITEs with wildcarded path values. 3.2 Applicability to non-MPLS Networks Although the remainder of this draft will use the above MPLS-based network as a basis for discussion, the SIP modifications proposed are intended to allow operation over any QoS-capable IP network. Providing a network of IP routers are connected by well-defined Layer Two links whose capacity is well known, our proposal is equally applicable. The term LSR can therefore be read as a reference to any IP cross-connect between these Layer two links. 4. Basic Protocol Operation This section shows the basic operation of the modified SIP protocol within the network described above. The messaging used is outlined along with the operation sequence. This is done by way of session messaging examples. The exact content of the messages is dealt with in later sections. The descriptions of the following message types are based on the four-hop network specified in [3] and pictured in Figure 1. In this case the extended SIP protocol is seen to operate in the Core Management Layer. 4.1 Set-up messaging example The following is a simple example of the messaging used to establish a session reservation and path within the Management Layer. 4.1.1 INVITE Generation On receipt of a COPS Request, the AM will form one or more INVITE messages. The process of forming this INVITE follows these steps: Gibson Category Informational - Expiration April 1999 5 SIP Reservation Extensions October 1999 1) Before any route determination can take place, the AM must determine the resource requirements of the new session. These may come to it in a number of forms, carried by a suitably extended version of COPS, namely: - SDP [8] session description - RSVP [9] TSPEC [10] - RSVP ADSPEC - RSVP FLOWSPEC - CR-LDP [11] Traffic Resource TLV - Simple Bandwidth Object This information will be coupled with the destination information and used to form a SDP description of the session (see section 5). 2)(Optional) The originating AM must assign the session a resource class, where this parameter is used when advertising the tunnel characteristics. The mechanism by which a resource class is allocated is to be decided - as yet the MPLS drafts themselves give no clear indication - but will probably be a function of media type, the payment mechanism (where applicable), the DiffServ class or one of a number of other parameters. 3) Examine available topology information and decide on a route. The AM has a database that contains the information of all its successful session paths plus the information from the advertising REGISTERs that it has received. It can therefore use this information to determine a route for the new session across the network. The proposed extensions to the SIP protocol have been designed such that an incomplete definition of this route can be used. This is implemented by defining part of the path using wildcard values. Note that the chosen path may not have sufficient bandwidth for the session if either another session seizes the resource, or the topology information is out of date, or the path is incompletely specified. 4) Having chosen a path, the AM now assigns it a rank. This rank is based on the AM's view of the congestion of the network, in conjunction with any local policy in force. For example, it is likely that the most favourable path to a particular destination will be that with the lowest congestion. However, a more congested link may have a lower latency and therefore be far more suitable to a real-time session. Also, this allows economic rules to be applied where different service providers own different sections of the Transport Layer. In the case where only one INVITE is sent, the AM may skip this part. 5) The AM must now form a SDP description of the session from the description it is passed by the EP. This is attached to the INVITE in the normal manner for SIP. Gibson Category Informational - Expiration April 1999 6 SIP Reservation Extensions October 1999 6) The AM now forms one INVITE per path selected - the exact number will be dependant on a local policy and may be restricted to reduce the total signaling load on the network. The AM examines the first address in the chosen path and forwards the INVITE to all CMs that match this address. This uses a process like forking in standard SIP. 4.1.2 INVITE processing at Connection Manager When a CM receives an INVITE, it should perform the following processing: 1) Examine the path list and determine if it has a connection to the next hop in the path. If the CM does not have an outgoing tunnel to the next listed CM, it must return an error message to that effect to the originating AM. 2) The CM now examines the next but one MN in the path too, to ensure this is reachable. Each advertising REGISTER traverses two hops and therefore each CM should have topology information up to two hops away. If none of the available next hop tunnels can be used to reach this two-hop distant MN the CM returns an error message to this effect. Intermediate MNs may read this error message on the path back to the originating AM to update their topology information. 3) The CM now examines the SDP description and determines the resource requirements for the session. Where a choice of next hops is available, the CM may use some policy information to pick how many of the next hop tunnels will be used. Any tunnels that cannot support the session are at this point discarded. 4) The CM can now determine the set of tunnels that can support the session. The CM examines the Call-ID of the INVITE. If a temporary reservation exists for this Call-ID, the tunnel already has sufficient capacity for the session and may be used as a forward path. No extra session bandwidth reservation need be made. 5) Otherwise the CM makes a temporary resource reservation for the new session on each of the tunnels capable of supporting the session. This reservation should match the requirements of the session and will be tagged with the Call-ID of the INVITE that prompted it. No other session may now be offered this part of the tunnel resource. 6) The CM adds its SIP-URL into the Record Route header of the INVITE and then forwards the INVITE to the MNs at the other end of those tunnels. This process is repeated at each CM along the route to the destination AM. The INVITEs will thus fan out towards the centre of the network and converge at the destination AM. Gibson Category Informational - Expiration April 1999 7 SIP Reservation Extensions October 1999 4.1.3 INVITE processing at destination Admission Manager The destination AM will probably receive a number of INVITEs, depending on how tightly defined each original INVITE's path was, how many INVITEs were sent and how may of the paths could be used. These will arrive asynchronously, however the AM may process each individually before issuing a response. The AM must perform the following on each of the INVITEs: 1) Examine the Record-Route header and compare it to the topology information the AM has stored. Using this topology information it too assigns a rank to the path in the INVITE. Note this may result in multiple ranks assigned to a single original INVITE due to forking - identical Record Routes should have identical ranks. 2) By convolution with the original rank assigned by the originating AM, the preferred path is chosen. This should happen after a time period long enough to allow all INVITEs to arrive but short enough to avoid too much setup latency. 3) The INVITE that contained the chosen path is now replied to with a 200 OK. The Record-Route header is copied into a Route header to direct the 200 OK through the MNs that forwarded the INVITE. The same Call-ID must be used in this response, again copied from the INVITE. +--+ +--+ +--+ ..1.>|CM|....1*....>|CM|. .>|CM|.3.. . |11| . |24| . .##|31|<###. . +--+ . +--+ 1* .# +--+ #. . 1 . .200OK #. /\. . .# #.>/\ |AM| . .#. #|AM| \/. . 3# . .>\/ #. . .# . . 200OK. +--+ . +--+.# . +--+ . #...2.>|CM|....2.....>|CM|...1......>|CM|.1/1* ######|13|<##200OK###|29|<# |36| +--+ +--+ +--+ ...n... INVITE n Path ####### 200OK Path Figure 2. 200 OK operation Gibson Category Informational - Expiration April 1999 8 SIP Reservation Extensions October 1999 4.1.4 Action of 200 OK Response The 200 OK response is directed back over the same path as the INVITE to which it is responding. At each CM in the path is has the action of confirming the temporary resource reservation made by the INVITE. This is achieved simply by correlating the Call-ID of the response with the Call-ID used to tag of the temporary reservation. The tag should not be discarded, as it will aid in the removal of the reservation using a BYE message. The principle of this operation can be seen in Figure 2. The left hand AM sends 2 INVITEs that get routed over diverse paths to the destination AM. This AM chooses INVITE 2 as the preferred route and issues a 200 OK back over the same path. At each CM in this path the 200 OK confirms the temporary reservation, made by the INVITE, for the duration of the session. That is, until it is explicitly removed. 4.1.5 200 OK processing at originating Admission Manager When the 200 OK is received at the originating AM it does the following: 1) The AM makes the temporary reservation on the LSP to its Edge CM permanent. The path across the network for the new session request from the EP is now fully specified at the Connection Layer. 2) Replies to the EP using a COPS Decision, indicating that the session reservation was successful. This message must contain the list of LSRs that will support the session (and whose CMs have accepted the session). The AM must therefore convert the SIP-URLs in the Route header of the 200 OK into IP addresses. This will be achieved through DNS lookup, either from the set of locally stored values from previous sessions or from a central server. 3) If no 200 OK responses are received, the AM may either respond with a COPS Decision rejecting the session, or try another set of routes across the network by issuing further INVITEs. 4) To complete the INVITE process, an ACK is returned to the destination AM, providing a 200 OK was received. This message is purely informational. Once the EP receives a COPS Decision, the session path can be considered fully provisioned and the CR-LDP process can be initiated using the returned LSR address list. 4.2 Session Tear-down example This section gives an example of how session reservations are removed as the session itself is torn-down. 4.2.1 Tear-down stimulus Gibson Category Informational - Expiration April 1999 9 SIP Reservation Extensions October 1999 Either participant in the session can initiate the tear down of a session. The stimulus for the removal will be a COPS Delete Request State (DRQ) with the same Client Handle as a previously received Request. The AM matches this to the original session Request and re- uses the session information in the teardown process. 4.2.2 Originating AM action The originating AM will correlate the Client Handle of the DRQ with the Call-ID used to originally establish the reservation. A BYE will now be issued with the corresponding Call-ID and will also include the QoS characteristics used to establish the session, described using SDP. A Route header must be used in the BYE message that corresponds to the route that the session has reserved across the network. This should again be identified using the Client Handle as an index to a table. 4.2.3 BYE operation at each CM When a CM receives a BYE, it should remove from its set of confirmed reservations, the one that corresponds to the Call-ID of the BYE. The SDP description can be used as a fail-safe check of the resource to be freed. If it is unable to perform this then it must resolve the size of reservation described by the SDP description. It must also examine the next SIP-URL in the Route header to determine the tunnel along which the original reservation was made. It then frees this amount of resource from the tunnel. This is accomplished either by removing a specific reservation identified by the Call-ID and re-calculating the total bandwidth. The CM then forwards the BYE to the next CM in the Route header. 4.2.4 Session Clearing notes The Removal of reservations in the Management Layer can occur concurrently with the removal of label mappings in the Transport Layer. The action of a BYE is unidirectional therefore a similar BYE must be issued in the opposite direction to remove the other half of a two-way session. The trigger for this will be provided by the session application and signaled using a COPS DRQ at the other Endpoint. Gibson Category Informational - Expiration April 1999 10 SIP Reservation Extensions October 1999 4.3 Resource advertisement example This section offers an overview of how SIP can be extended to advertise topology information. This information includes the size and destination of tunnels and the set of reachable domains via particular CMs. This advertisement mechanism will be implemented using the REGISTER method that exists within SIP, modified such that the status of the tunnel initially registered is regularly updated using a new message body type that uses a similar syntax to that of SDP. 4.3.1 Initial tunnel advertisement When a tunnel is established in the Transport Layer, its presence must be indicated to the Management Layer in order for sessions to be routed over it. The mechanism and reasons by which a tunnel is initiated is outside of the scope of the document - it will likely be driven by the owner of the network and may be caused by network initialisation or re-provisioning. Whatever the reason, the tunnel must always be established using a known set of traffic parameters which are tightly controlled. Once the tunnel exists, the LSR issues a COPS Request to its MN to register the tunnel. The issuing of a COPS Decision is more of a formality, as the MN is unlikely to refuse to allow the tunnel. The Request must include at a minimum the address of the destination LSR and the bandwidth of the tunnel. More likely it will include the full description of its QoS parameters e.g. the Traffic TLV used by CR-LDP. This information will be included in the message body. When the MN has received this information, it must advertise it for it to be of any use within the Management Layer. The MN that has received the information will be at the upstream end of the tunnel and will be controlling admission to the tunnel for sessions towards the destination LSR. The MN must therefore perform a DNS lookup on the IP address of the destination LSR to determine the SIP-URL of the MN controlling it. It is this SIP-URL that will be used in the advert. The MN is now able to form a REGISTER message that it will send to all of its peer MNs plus the MN that is the destination of the tunnel. The contents of the REGISTER will be the resource characteristics of the tunnel and the SIP-URLs of the MNs it runs between. The purpose of this REGISTER message is twofold: 1) It establishes two-hop topology information in those upstream (peer) MNs that receive the REGISTER. That is, each of these MNs now has a route to the tunnel destination via the REGISTER sending MN. 2) It establishes a peering relationship with the MN at the destination of the tunnel. On receipt of the REGISTER, the Gibson Category Informational - Expiration April 1999 11 SIP Reservation Extensions October 1999 destination MN now knows that there is a new inbound tunnel to it and therefore a new upstream MN that will want to receive its update REGISTERs. The above process can be seen in Figure 3. CM_X receives a COPS Request for the new tunnel from LSR_X to LSR_Z. CM_X therefore forms an REGISTER which it sends to its existing peer CM_Y telling it of the new route. CM_X also sends the same REGISTER to CM_Z. The action this time is to inform CM_Z that a new peering relationship should be formed. In general terms, if a MN receives a REGISTER that has a From: header containing the URI of a MN it does not recognise, this should be regarded as a request for peering from that MN. Peering REGISTER messages should be sent to the new peer directly, not multicast. A MN without a peer relationship will ignore multicast REGISTERs from a MN it is not yet the peer of, as it has not been told to listen for them. +----+ +----+ +----+ |CM_Y|<===new route===|CM_X|==new peering==>|CM_Z| +----+ +----+ +----+ ^ | | REQ: tunnel CM_X->CM_Z | | _______________ | ________________ (LSR)()______________)(LSR)()_______________)(LSR) Existing tunnel New Tunnel Figure 3. Action of Tunnel Advert 4.3.2 Tunnel update advertisement Each MN must update the information about the capacity of each of its tunnels on a regular basis. This information should be sent to each of its peers based on the following metrics: Time - as a baseline, each MN must send an advertising REGISTER on a regular basis at the expiry of a timer - every time an advertising REGISTER is sent, the timer should be restarted; Gibson Category Informational - Expiration April 1999 12 SIP Reservation Extensions October 1999 Activity - a MN may choose to send a new advert based on a number of INVITE/BYE messages; Resource - every time there is a significant change in tunnel resource a MN may choose to send a new ADVERT. Once a peering relationship is established, the same Call-ID for each subsequent REGISTER to the same peer should be retained to allow easy tunnel identification. The CSeq header should be used to indicate an updated value. The peer should always use the advertising REGISTER information with the highest CSeq value and discard all lower value REGISTERs with the same Call-ID. Multiple tunnel descriptions can be included in a single REGISTER as each description is self-contained (See section 5.3.2) however care should be taken that the total message length does not get too long. As the tunnel advert information is contained in a message body, the update information could be piggybacked on other messages as they traverse the network to reduce the total messaging. 4.3.3 Reachable domain advertisement Over time, a MN will build up a view of the domains it is two hops distant from, based on the REGISTERs it receives from its peers. This information may be advertised too to aid route selection and ranking. This information should be cascaded back to the edges of the Management Layer to the AMs. The To header of each domain REGISTER will be formed from the end descriptor of the tunnel adverts the Core CM receives. The SIP-URL used in the To header may only ever have a MN-type of AM (see section 5.3.2 for details). When an AM is choosing a route to a destination AM, it will only have detailed topology information for the first two hops of the journey to a set of reachable Core CMs. It therefore is essential that the AM knows the set of nodes reachable from each of these Core CMs so that the final two MNs in the path to the destination AM can be determined. The domain information can be gleaned by examining the domain segment of the destination SIP-URL from a tunnel advertisement. A Core CM is capable of choosing an onward route for an INVITE based on its topology information, so by sending an INVITE via a certain Core CM and allowing (through wildcarding) the CM to choose the route for the final two hops of the path, the AM can reduce the total amount of information it needs to store. 5. Protocol details Gibson Category Informational - Expiration April 1999 13 SIP Reservation Extensions October 1999 The aim of this section is to describe in some detail the format and use of the messages described in brief above. It will concentrate on the areas where there is significant divergence from the standard operation of SIP, either in operation or interpretation of fields, and on the key message elements used where operation is similar. 5.1 Standard SIP The message format of the standard SIP protocol, represented using Augmented Backus-Naur format (ABNF, as described in Appendix C of [5]), is as follows: generic-message = start-line *message-header CRLF [ message body ] start-line = Request-Line | Status-Line message-header = ( general-header | request-header | response-header | entity header ) The first element is always a start-line, which can be either Request line or Status line. Generally a Request line describes the SIP method that the message is instigating and the Status line shows the nature of a response to such a message. The Request line has the following format: Request-Line = Method SP Request-URI SP SIP-Version CRLF e.g. INVITE sip:mark@nortelnetworks.com SIP/2.0 This would be for an INVITE from mark@nortelnetworks.com using version 2.0 of the SIP software. For a response to this INVITE, the following might be used as the Status-Line of the message: Statue-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF e.g. SIP/2.0 200 OK in this case an OK response that has a Status-Code of 200. After the start-line there are multiple message-headers (denoted by the * in ABNF) that can be any of the shown types except that a request-header is specific to a request and similarly a response- header is specific to a response message. This draft proposes a number of changes to the standard set of these headers as detailed in section 5.3. Gibson Category Informational - Expiration April 1999 14 SIP Reservation Extensions October 1999 Finally, in the generic message, comes any message body attached to the message. The format and length of the body type is described by the entity-headers at the end of the message-header list. A message body is attached in native format, hence a SDP body is included using its standard text-description. In order to accommodate capacity advertisements we will describe an additional advert body type. 5.1.1 Change of INVITE meaning The meaning of the INVITE message is changed when compared to the standard SIP protocol. Under normal operation, this message is used to invite the called party to join a session and indicates the type of media that the caller can receive. The indication of what is to be sent is an option. The INVITE is now used to make a forward reservation for the session from the caller. Therefore the session description contained within the INVITE is that for the forward direction and should be used to reserve bandwidth in tunnels from the caller to the callee. 5.1.2 Change of REGISTER use The REGISTER method is currently used to register the address listed in the To header with a SIP server. This draft proposes two alterations to the use of the message. In the link advertisement we REGISTER the existence of a link to the location described by the To header and advertise its available capacity. The description of this path is then included in a new message body type, as described in section 5.3.2. Secondly, the set of domains reachable via a particular CM is registered with other MNs. In this instance the To header has no real meaning, with the information stored in the reachable domains body type attached to the REGISTER message, as described in section 5.3.3. To accommodate this functionality, all MNs must operate as Registration servers for both path and reachable domain REGISTER messages. These REGISTER messages should be sent using a different multicast address than the well-known "all SIP servers" address "sip.mcast.net" (224.0.1.75). It is suggested that two new well- known addresses be used: "sip-path.mcast.net" for path REGISTER messages; "sip-domain.mcast.net" for reachable domain REGISTER messages. To control the level of signalling information present in the network, the REGISTER messages must be controlled using the TTL field. It is recommended that in the 4-hop network shown in Figure 1, the value TTL = 1 be used for path REGISTER messages and TTL = 2 for reachable domain messages. Gibson Category Informational - Expiration April 1999 15 SIP Reservation Extensions October 1999 The information in both new REGISTER message types must be periodically updated without the need for outside stimulus. Updates will be indicated by an increased CSeq. Previously stored information must be discarded and the new information used instead. 5.2 Message formats We now address the specific SIP headers that need to be modified to allow path reservation described within this draft to be performed. Also included in this section is the details of the single new header type required. 5.2.1 From header The From header takes the standard SIP form. It will only ever have the SIP-URL of the Admission Manager that is originating the INVITE or of the Connection Manager originating the REGISTER method. To aid the determination the MN-type originating the message, it is recommended that the tag is used to identify the type of MN node originating the message. The From header also has a vital role in the establishment of a peering relationship between adjacent Management Nodes. If a path REGISTER is received with a SIP-URL in its From header of a Management Node that the receiving Management Node does not already have a peering relationship with, the SIP-URL must be added to its peer list. The from header takes the standard SIP form as described below: From = ( "From" | "f" ) ":" ( name-addr | addr-spec) *( ";" addr-params ) name-addr = [display name] "<" addr-spec ">" addr-spec = SIP-URL|URI display-name = *token|quoted-string addr-params = tag-param tag-param = "tag=" UUID UUID = 1*( hex | "-" ) e.g. From: "M. Gibson" ; tag=AM The above example shows that the message originated from user mrg whose SIP application has AM functionality. 5.2.2 To header The main part of the To header is used in the normal SIP manner. It will only ever contain the address of the Admission Manager that is the destination of the INVITE. Gibson Category Informational - Expiration April 1999 16 SIP Reservation Extensions October 1999 The use of the tag part, however, is to be changed to accommodate the formation of multiple INVITEs for a particular session. It will be used to indicate which of how many total INVITEs for the session this INVITE is. The To address takes the standard SIP form as described below: To = ( "To" | "t" ) ":" ( name-addr | addr-spec) *( ";" addr-params ) addr-params = tag-param|alternate-param alternate-param = instance "(" total ")" ;instance <= total instance = 1*digit total = 1*digit e.g. To: sip:j.bloggs@sip.net; tag=2(4) The above example is for an INVITE to j.bloggs and indicates that this is the second of four different INVITEs. 5.2.3 Record-Route header The Record-Route header is formed in the exact same manner as normal SIP. It must always be used in an INVITE to allow determination of the path over which reservation is being made. The Record-Route header will never be used in an ADVERT message type. The Record-Route header takes the standard SIP form as described below: Record-Route = "Record-Route" ":" 1# name-addr e.g Record-Route: , This indicates that the request has traversed the host ieee.org then bell-telephone.com. 5.2.4 Route header The Route header is used in an INVITE to define the path it should take across the network. In contrast to normal SIP, the list of SIP- URLs may contain non-explicit information. E.g. *@domain.name.com is an acceptable value. Where this is used, the INVITE may be forwarded to all MNs that match the non-asterisked parts of the SIP-URL. The determination of which of these MNs to use is performed using the topology information stored by the MN in conjunction with the next element in the Route header. Only those matches that provide a route to the two-hop distant SIP-URL may be used. The chosen value is written into the Record-Route header as above. The Route header uses the standard SIP form as described below: Route = "Route" ":" 1# name-addr|wildcard-addr Gibson Category Informational - Expiration April 1999 17 SIP Reservation Extensions October 1999 Wildcard-addr = "*@" *("*" | domainlabel ".") ("*" | toplabel [ "." ]) e.g Route: , The Route header of an INVITE should be discarded by the AM that receives it. Only the Record-Route header will contain useful route information. It is recommended that the Route header is not used in REGISTER messages, thereby reducing the packet size and therefore signaling overhead within the Management Layer. 5.2.4.1 Wildcard Usage The SIP-URL contained in a Route header may be replaced in total or just part by a wildcard value, as illustrated in the ABNF rule above. This allows the originator to direct an INVITE through a particular domain but to allow local SIP servers to determine the path across that domain. Where the whole of a Route element is wildcarded the INVITE may be forwarded over any next hop, provided that there is a route to the next but one Route element via the chosen next hop. This forwarding decision should be made using the reachable domain information REGISTER'd for this next hop. See Annex B for further usage examples. The Route header must always contain the SIP_URL of the destination AM its last element. It must never be wildcarded. This ensures that looping is avoided and allows the looping detection afforded by the use of Via headers to be suppressed. Where there is any doubt about the address of the destination AM, the originating AM must set the TTL header of an INVITE such that it will time-out shortly after it should have reached its destination. In the four-hop network example, this implies a TTL=5. 5.2.5 No-Loop header The use of wildcards within the route header allows INVITEs to diverge and then converge at the same point as they travel across a network. Under normal operation, SIP proxies will add Via headers to allow for loop detection. However, this would suppress the multiple route finding function that the wildcarded Route header introduces. A No_Loop header is therefore introduced to suppress this action: No-Loop = "noloop" Care must obviously be taken when using this header that looping is not introduced. By use of the reachable domains message body and the Route header it is possible to ensure that looping is avoided by Gibson Category Informational - Expiration April 1999 18 SIP Reservation Extensions October 1999 rejecting INVITEs whose next-hop Route SIP-URL cannot be reached through the current MN. 5.3 Body formats This section sets out the body formats needed to perform session reservations. Firstly the extensions needed to SDP are detailed. Then secondly the two new message body types needed to implement advertisement are detailed. 5.3.1 SDP extensions To exploit SDP so that it properly most profitably interworks with the modified SIP protocol proposed within this draft, both the bandwidth (b) and session information (i) fields need an extended useage and new fields of route favourability (f) and resource class (r) need to be defined. 5.3.1.1 Bandwidth (b) The current bandwidth definition used by the SDP protocol is used to indicate only the required bandwidth in kilobits per second of the session. While this may sufficient for simple implementations, there is a need to support more complex description of the session to make better use of an MPLS or similar tunnel technology. This also allows for a better mapping of RSVP TSpec and FlowSpec and CR-LDP Traffic TLV parameters. The bandwidth description will be in terms of the policed session flow from the AM. As the AM will tell the EP what committed rates the network will offer, the AM need only use these rates in INVITE. The process by which the committed rates are derived from the requested rates is outside the scope of this document. The 3-tuple that defines the peak and maximum date rates is therefore defined to be used in the bandwidth description containing: Data rate - the mean data rata of the application. (This correlates roughly to the Token Bucket Rate of RSVP and PDR parameter of CR-LDP Traffic TLV.) Peak rate - the peak data rate of the application. (This correlates roughly to the Token Bucket Size of RSVP and PBR parameter of CR-LDP Traffic TLV.) Burst rate - either the maximum burst rate that the application might produce, or the maximum burst size that a tunnel can support. (This correlates roughly to the Peak Data Rate of RSVP and EBS parameter of CR-LDP Traffic TLV.) The syntax for this SDP description is as shown: b= Gibson Category Informational - Expiration April 1999 19 SIP Reservation Extensions October 1999 5.3.1.1.1 Peak vs Burst rate The use of the Peak and Burst Rate parameters will depend on the context of the bandwidth parameter. In an INVITE, the bandwidth parameter will be used to describe the session requirements. Therefore the Peak rate and Burst rate should be a good match to each other as the AM will provide a policing function for the session. In an ADVERT the Peak rate may be used to indicate a preferred maximum burst rate for new sessions and the Burst rate can indicate the maximum rate that the tunnel can support. A tunnel may therefore accept a session with a higher Peak rate than the advertised burst rate - this will probably have the action of reducing the advertised Burst rate next time around. 5.3.1.2 Information (i) The information description of SDP can be used to convey the same information as the tag used in the To header. Namely which of multiple INVITEs this message is. This implies that the INVITEs are forked at the originating AM using Route headers, which may not sit comfortably with the SIP standard. However, it does allow a single 200 OK to be legitimately issued for all the different paths and keeps the differentiation at the session level. The syntax for this SDP description is as shown: i= of Where m < n and n is the maximum number of different routes that an AM may attempt reservation over. 5.3.1.3 Favourability (f) This type is used to indicate the rank or favourability of the route in the INVITE for a particular session, as perceived by the originating AM. The higher the value assigned, the more favourable the route is. It is recommended that this be an integer value with a pre-agreed maximum value. The method for deriving the favourability value and how it is interpreted by the receiving AM is beyond the scope of this document. The syntax for this description is as shown below: f= 5.3.1.4 Resource Class (r) The resource class will be decided by the AM for a particular session and used in MPLS networks where multiple tunnels exist Gibson Category Informational - Expiration April 1999 20 SIP Reservation Extensions October 1999 between LSRs. It must be included in all INVITEs to enable suitable route choice. The syntax for this description is as shown below: r= When used in an INVITE, every effort must be made to match the resource class of the INVITE sdp with that of the tunnel the session is to be forwarded along. 5.3.2 Advert body type The Advert body type is used to advertise the existence of a tunnel between two LSRs and will be carried by a REGISTER message. It is sent initially to announce the establishment of a new tunnel - part of the peering establishment operation - and then subsequently to update the spare capacity it has left. The Advert body type takes the same basic syntax form as the SDP protocol and has six descriptors: Start [s] - the starting LSR of the tunnel End [e] - the end or terminating LSR of the tunnel Total Capacity [c*] - the total size of the tunnel Free Capacity [f] - the available capacity of the tunnel Latency [l*] - the time taken to traverse the tunnel Resource Class [r*] - the resource class of the traffic carried by the tunnel. The descriptors marked with an asterisk are all optional in every Advert and their use will depend upon the complexity of the network and the parameters used to make routing decisions. This set of descriptors is not seen as necessarily definitive and there is scope to add further descriptors as required. Each of the above descriptors will now be dealt with in more depth in the following sub-sections. 5.3.2.1 Start [s] descriptor This is used to indicate the LSR (or other Layer Two element) at the beginning of the path being advertised. The Start descriptor must always be present in an advert message body. Note: the tunnel is seen as running from the start to the end such that the start performs the label mapping of incoming session packets to send them to the end. Gibson Category Informational - Expiration April 1999 21 SIP Reservation Extensions October 1999 Although it is the LSRs that form the tunnel's endpoints, it is the SIP-URL of the MN controlling the LSR at the start of the tunnel that is advertised. This simplifies the peering process and allows multiple different LSRs controlled by the same MN to appear as one super-LSR. The SIP-URL used to describe the start of the tunnel will be that of the MN controlling the LSR. The syntax for the Start descriptor is shown below: s= e.g. s=CM_london@SIP.co.uk There is no assumed policy for the allocation of SIP-URLs to describe the endpoints of a tunnel and is left flexible to allow tailoring to particular situations and architectures. 5.3.2.2 End [e] descriptor The End descriptor is used to indicate the destination of the path being advertised. It must always be present in an advertisement. As each advertisement is sent by a MN to each of its peers, the End descriptor not only describes the path destination but also provides reachable domain information as the destination MN of the path is two hops distant from each of these peers. A CM that is acting as a Core CM should therefore log all advertisements that emanate from AM-type SIP-URLs. The End descriptor has the following syntax: e= e.g. e=AM_Paris@SIP.fr 5.3.2.3 Total Capacity [c] descriptor The total capacity descriptor indicates the size of the path being advertised in terms of its bandwidth. The same 3-tuple used in the extended bandwidth descriptor for SDP is re-used here. The tunnel is therefore described in terms of: Total data rate (kbps) - essentially the capacity of the path Preferred peak rate (kbps) - the preferred maximum session burst rate Maximum allowable data burst (kbps) - the largest burst the path can handle. This descriptor is optional in all Adverts as in the most part, the useful information when forwarding an INVITE is the free tunnel capacity. If advertising the total capacity is deemed necessary, it is recommended that the total capacity be sent only once in an Gibson Category Informational - Expiration April 1999 22 SIP Reservation Extensions October 1999 initial REGISTER and only re-sent if it changes during the lifetime of the tunnel. The syntax for the total capacity descriptor is: c= e.g. c=10000 50 200 5.3.2.4 Free Capacity [f] descriptor The free capacity descriptor is mandatory in all tunnel REGISTER messages. It uses the same format as the tunnel capacity descriptor but advertises the free or available capacity of the tunnel. The syntax for the free capacity descriptor is: f= e.g. f=300 40 200 While the maximum allowable data burst size will likely remain constant, if a large number of bursty sessions have already been routed along the path, the preferred peak/burst rate may be reduced to inhibit the admission of further bursty sessions. The available data rate will indicate the amount of free bandwidth along the path. 5.3.2.5 Latency [l] descriptor The latency descriptor describes the time taken to traverse the path and is optional. As with the total path capacity, this figure is unlikely to change over time and so where used it need only be sent once, unless the path changes - note resizing of the path will likely have no effect. The latency descriptor will have the following syntax: l=