Internet Draft M. Gibson Internet Draft Nortel Networks Document: draft-gibson-manage-mpls-qos-00.txt October 1999 Category: Informational The management of MPLS LSPs for scalable QoS Service Provision 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 There is an increasing use of real-time applications on IP networks. As these applications require certain QoS levels to operate acceptably there is a need for IP networks to guarantee such levels. This draft proposes a network architecture that uses a modified version of the SIP protocol to reserve IP sessions with a requested Quality of Service. The network consists of a session control layer, an IP Layer that is constrained through the use of MPLS tunnels, and a distributed management system to control those tunnels. The draft describes each of the key components needed to implement such a network and suggests suitable technologies for each of them. 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]. 2.1 Terminology and Abbreviations Label Switched Path (LSP) - an MPLS path between two MPLS routers. Gibson Category Informational - Expiration April 1999 1 Managing MPLS for QoS October 1999 Label Switched Router (LSR) - a router in an MPLS network that performs label swapping. IP Tunnel - A path between two routers that transparently forwards IP packets over a number of intermediate routers, without examining the packets themselves. In an MPLS network this would comprise a number of separate, concatenated LSPs between two LSRs. The tunnel is said to exist between these two LSRs. The intermediate LSRs will simply forward all traffic in this tunnel and the route taken by the tunnel will be abstracted from the LSRs at either end. Session - one or more data flows between two endpoints to be treated in the same manner. Users - those wishing to request a connection across the network. A user can be situated either directly at an Endpoint or may be using it as an access gateway from their private network. 3. Introduction The Internet Protocol (IP) is being increasingly seen as the ideal convergence mechanism for all forms of modern communications. It has a long history in the field of data communications and provides the means by which a great deal of today's data traffic is routed across networks. Indeed there is a great deal of maturity and understanding of how IP data networks operate. However, there are a number of emerging IP services and technologies that have not yet reached such maturity. IP networks experience problems when trying to support services which send streams of regular packets whose content has a time criticality. For the most part this means real-time multimedia streams. Real-time media streams are by their very nature, sensitive to the QoS of the network they operate over. There is a need not only to provide the correct QoS for these streams but also to guarantee it for the duration of the session. A network architecture is therefore necessary which is sufficiently flexible to support the differing QoS requirements of particular sessions but able to ensure their continued delivery. Additionally the network should make the best use of its finite resources. It should therefore provide a means of managing these resources such that existing sessions see no degradation of their service and new sessions are not admitted if they cannot be supported. Finally, there is increasing interest in the ability to perform Traffic Engineering on IP networks. This interest falls into two main areas: traffic based and resource based. The former pertains to Gibson 2 Managing MPLS for QoS October 1999 optimising the key traffic performance characteristics such as delay, packet loss and throughput efficiency. The latter refers to using the available network resource in the most efficient manner to avoid congestion and under-utilisation. Any IP network aiming to provide QoS for IP sessions should support these principles. The purpose of this draft is to determine the set of requirements needed by a network to support real-time services and then to suggest a suitable network architecture. The solution proposed here to the set of requirements should be regarded as the first iteration towards a final solution and additional comments and suggestions are most welcome. 3.1 Requirements In order to support such media streams there are a number of key requirements that a network aiming to provide QoS should meet. It should support traffic engineering principles so that sessions can be directed along the best route and can have their resource pre-allocated. It should also allow aggregation of similar traffic types across common network paths. It should offer a bandwidth guarantee based on the negotiated parameters of the session. This should be achieved, however, through a minimum level of reservation state. It should also support the use of asymmetric sessions. It should make use of the QoS characteristics of the underlying transport protocol e.g. VBR, CBR... in ATM. It should support session rejection at the edge of the network such that a session can be refused before any resource is allocated if the network cannot bear it. It should offer individual session security in two respects: firstly any network should support authentication of users and secondly each session should be secure such that its contents cannot be intercepted. Finally, any such network should be part of a scalable solution that could be extended from very small to very large networks. 3.2 Proposed Solution It is proposed that an MPLS network configured using CR-LDP to have a number of known size and destination LSPs between managed sets of LSRs can be used as a basis to achieve such a network. However, in Gibson 3 Managing MPLS for QoS October 1999 addition to this network topology, a method of choosing which of the LSPs to use to transport a new session is also required. The solution proposed within this document uses broadly connection- oriented techniques to manage the resource of an MPLS network. However, the operation of MPLS is left unaltered and it therefore retains its basic connectionless paradigm. The network architecture proposed in this document suggests a unified solution to all of the above requirements. This solution is specified using 3 distinct layers: Session Control - With the increasing popularity of internet telephony, this refers primarily to the use of Call Servers at the edge of a network. However, this extends to encompass all forms of session request. Figure 1 Functional Composition of network Session Control +--+ +--+ |CS|''''''''''''''''''''''''''''''''''''''''''''''|CS| +--+ +--+ : : : : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ : Core Management : : /\ /\ /\ /\ /\ : :-----|CM|--------|CM|--------|CM|------ : : \/ \/ \/ \/ \/ : : ! $ $ $ ! : : ! $ $ $ ! : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ : ! Core Transport $ $ ! : : ! $ $ $ ! : +-----+ +--+ +--+ +--+ +-----+ | EP |======|R1|========|R2|========|R3|======| EP | +-----+\\ +--+\\ //+--+\\ //+--+ //+-----+ \\ \\ // \\ // // \\ \\// \\// // \\ \/ \/ // \\ /\ /\ // \\ //\\ //\\ // \\ // \\ // \\ // +--+// \\+--+// \\+--+ |R4|========|R5|========|R6| +--+ +--+ +--+ Core Management - This consists of the necessary control modules needed to administer session path determination and reservation Gibson 4 Managing MPLS for QoS October 1999 across the core network. This layer is largely comprised of new network elements, linked together by an extended version of the SIP protocol, and represents the primary area of focus of this paper. Core Transport - This is a transport layer capable of providing QoS based IP tunnels whose capacity can be subdivided and apportioned on a per-session basis. The network therefore has the topology of a set of LSP clouds that have well defined and managed endpoints. The LSP clouds will consist of a number of pre-configured routes between the managed LSRs, whose topology will vary slowly with respect to the sessions established over them. 3.3 Network Composition The position of each of the functional layers in the proposed framework can be seen in Figure 1. As can be seen from the diagram, each layer consists of a number of separate functional entities whose role will now be defined. CS - Call Server, responsible for generating session setup signaling information particularly the QoS requirements for the session. Figure 2. Connection Manager to Router Coupling /\ /\ |CM|--------------------|CM| \/ \/ $$$ $$$ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ +---+ $ $ +---+ $ $ |R17|====================|R27| $ $ +---+ $ $ +---+ $ $ $ +---+ +---+ $ $ |R14|==============|R25| $ $ +---+ +---+ $ $ $ +---+ +---+ |R12|==========================|R28| +---+ +---+ AM - Admission Manager, responsible for initiating and terminating path reservation requests. All path choice decisions are made here. The AM is tightly bound to its Endpoint (EP). The AM acts like a SIP proxy storing call state information. Gibson 5 Managing MPLS for QoS October 1999 CM - Connection Manager is responsible for the management of the IP tunnels of its associated routers. It must maintain a database of all the LSPs emanating from each of its routers to other managed routers which includes the LSP's destination and capacity parameters: at least the maximum and available capacity. Each CM may control more than one Router, as shown in Figure 2. The CM also acts like a stateless SIP proxy and stores only reservation information for the session. This is a much reduced state level of state information in comparison to an AM. Note: Connection Managers and Admission Managers are collectively referred to as Manager Nodes (MNs). EP - Endpoint can either be a terminal or an edge router. It represents the origination/termination of a session on the Core Transport layer. R1,2,3 - Routers that are the switching points on the path between two endpoints. They are interconnected to each other and to the Endpoints by IP tunnels. R4,5,6 - Routers providing alternate paths and are controlled by the CMs of R1,2,3 respectively. 3.3.1 Topology Scaling It is anticipated that the 4-hop topology, indicated in Figure 1, is sufficiently scalable that it is equally applicable in a number of different situations. The topology could apply equally well to a single domain solution or could potentially scale to provide an international solution. A Connection Manager could therefore control anything from a number of low capacity IP trunks across a single domain, to a number of high capacity international trunks. For example, the topology could be used to implement a high-capacity IP trunk network, with the EPs forming the access points to this network from a regional IP network. In this mode of operation it is easy to imagine a Core CM acting as an international gateway able to access an EP hosting the destination regional network over the final two hops of the described topology. The architecture is, however, flexible to allow extra elements. If more IP tunnels are considered necessary, there are two potential topology solutions. Firstly extra CMs can be added into the session path and the distance over which topology information is transmitted can be likewise extended. Alternatively, the session can be routed through an AM without terminating it. That is an AM can operate as a Border Gateway between two such networks, each acting as a separate domain. In this Gibson 6 Managing MPLS for QoS October 1999 case a separate reservation would need to be made for each of the networks in the path between originating and destination EPs. Neither of these two final mechanisms will be dealt with in the remainder of this draft. 4. Session Control Layer This comprises the signaling needed between two endpoints to establish a QoS based connection. In the general case depicted in Figure 1, this layer comprises two Call Servers. However these may be replaced by two Gatekeepers for H.323 [3] or by SIP [4] UAS and UAC. For the purposes of this document, the term Call Server (CS) will be used throughout. The role of the CS depends on the information it is given. It is likely that the endpoint information supplied to it by an originating EP will be in the form of an alias, be that a Universal Resource Indicator (URI) or other human readable form. In this case the CS must determine the IP address of the called Endpoint. If the destination EP is acting as a router to the called user, the CS must determine the address of the EP so that the correct IP tunnels can be provisioned across the Core Layer. Regardless of the information supplied, the CS is always responsible for the calling-response phase of any session setup. This could use, for example, either ISUP or SIP and is represented by the ' line in Figure 1. The Session Control Layer treats the rest of the network as though it were a black box and knows nothing of the implementation of the QoS routes which it requests. Its only interface will be direct to the Transport Layer using a protocol such as megaco/H.248, indicated in Figure 1 by the : line. 5. Core Management Layer This is the most fundamental part of the proposed framework. Most current IP systems that provide the ability to perform QoS reservations implement some form of broker function. This typically provides an admission policing function plus route information over a single domain. In this proposed architecture, the functionality of this single entity is distributed across the whole network. While the admission to the network still occurs at the edge and although policies are stored locally not centrally, the act of route selection is performed by all Management Nodes in a particular route. Similarly precise IP tunnel state information is gathered locally at the network edges by AMs to enable more accurate route selection. Indeed most of the session state is stored at the edge of the network, with a minimal amount of hard reservation state information Gibson 7 Managing MPLS for QoS October 1999 stored across the CMs that comprise the session's path across the network. All new LSPs must be registered with the Management Layer before they can be used. Management Nodes are also able to indicate that particular LSPs are becoming congested. If viewed as a black box function, the Core Management Layer takes as its input the destination for a new session and its traffic parameters and returns the best path across the Core Transport Layer according to the rules implemented in the Management Nodes. The Core Management Layer is implemented using two new element types, an Admission Manager and a Connection Manager. These elements are responsible for: - route determination across the Core Transport Layer - the negotiation and monitoring of the capacity of the tunnels in the Core Transport Layer - typically the available and maximum capacity. They perform no session establishment function across this Layer but will refuse a new session request should there be insufficient resource for it. Each of these elements maintains a close coupling to the Core Transport Layer, especially to those elements of the Core Transport Layer that they are managing. The Core Management Layer elements are now discussed in further detail. 5.1 Admission Manager The Admission Manager is present at the edge of the network and performs a number of functions. Firstly it is responsible for determining the policy to be enforced for a session on the network. It will typically store the set of Service Level Agreements (SLAs) for the users hosted on its associated EP. When any of these users requests a session (via the ! interface from the EP), the AM will use their SLA as a basis for negotiating a path across the network. This allows the ability to deny unregistered users access to the network until they have agreed a SLA with the network administrators. The Admission Manager is then responsible for initiating and terminating new session negotiations. The AM will receive request messages that will include the IP address of the destination Endpoint and the QoS characteristics of the session. It will reply to these requests with a suitable path across the Core Transport Layer defined as a list of Routers ending with the destination Gibson 8 Managing MPLS for QoS October 1999 Endpoint, and the session description. The latter is included to maintain traceability. It is anticipated that the EP-AM (!) interface will be implemented using COPS with suitable extensions to allow the explicit bandwidth requirements of a session to be communicated. The other interface (represented by - in Figure 1) from the AM is that to its next-hop Connection Managers. As can be seen from Figure 1, each Admission Manager will have a connection to at least one Connection Manager. This interface serves a number purposes. Firstly, it allows the AM to receive updates about the availability of capacity in the LSPs in the network. In this way the AM is able to maintain up-to-date information about the congestion of all or just part of the Core Transport Layer. Secondly the interface is also used to convey topology information by the announcement of new IP tunnels, or a change in the capacity of an existing tunnel. Finally the interface is also used for the negotiation of a new path across the Core Transport Layer for a new session. The AM is the only element type that is allowed to initiate or terminate such messages. 5.2 Connection Manager A Connection Manager is responsible for monitoring how much bandwidth is available within each of the IP tunnels it is administering and advertising this to the other Core Management Layer elements. To achieve this, the CM must first know the total capacity of the IP tunnel it is administering. When a tunnel is formed between two Routers, the originating router MUST register this fact with a Connection Manager. This registration MUST include the total capacity of the tunnel and the address of the Transport Layer element which terminates the IP tunnel, be it an EP or LSR. It is recommended that COPS - again with suitable extensions - be used for this interface, which is represented in Figure 1 by a $ line. Each CM therefore has a number of LSPs, which may accordingly originate from a number of Routers, which it is responsible for administering (as per Figure 2). When each LSP has registered, the CM should advertise this to the rest of the network and should continue to do so until such time as the LSP is torn down. The frequency of these advertisements should be slow enough such that the interface does not become overloaded with messaging but frequent enough that the network can react to Gibson 9 Managing MPLS for QoS October 1999 changes in capacity. These adverts should be directed to those MNs that have a tunnel connection to the advertising MN. 5.3 Inter Manager Node Interface Protocol The protocol that runs between the Manager Nodes must perform the following functions: - a) Route Determination: The Admission Manager of one endpoint should receive sufficient information to be able to select at least one route to any other reachable endpoint. Should the Admission Manager already know of a route it must still be able to test the availability of this route. - b) Reservation: The protocol must allow a reservation to be made along the selected route for the new session. This reservation will be made with each of the Manager Nodes and linked up with the Core Transport Layer. - c) Route Selection: When more than one possible route exists across the network, the protocol must provide a simple means of choosing which path to use; this should be decided between the originating and destination Admission Managers. - d) Wildcarding: If the originating Admission Manager does not have complete topology information to reach a destination endpoint, the protocol must support wildcarding such that the network can determine the route to take over the wildcarded path leg. A CM can use locally stored information and may forward the reservation to all possible next-hops. This mechanism should be used when the originating AM either does not know or does not care about the node used for a particular leg of a path. Restricted wildcarding should also be supported, such that the AM can specify a rough but non-specific path lag. - e) Advertising: Support the advertising mechanism between the Manager Nodes to include the available capacity of the tunnel and the nodes between which it operates. 5.4 Congestion Information Congestion information is carried by advert messages and is used in two distinct ways in the network. Firstly it is used by the Admission Managers to assist in the ranking of possible paths across the network. Secondly, it is used by Connection Managers to determine if the next hop in a specified path is available. In the four-hop model of Figure 1, the maximum distance that congestion information needs to travel is two hops. It is expected that information travelling any further than this will be out-of- date by the time it has reached a Management Node. Gibson 10 Managing MPLS for QoS October 1999 6. SIP usage as Management Layer Protocol It is proposed that by introducing some modifications to its basic operation, SIP could be used to provide the functionality needed to act as the Management Layer protocol. The details of the necessary modifications can be found in [5] however an overview of the modified operation of SIP will now be given. The existing INVITE method will be re-used to establish a reservation across the network by an originating EP. Each INVITE will contain a SDP description of the session that will constitute the agreed reservation level for the session probably based on its SLA. Each INVITE message will be directed across the Management Layer using a Route header with the last element in this header being the address of the destination EP. The contents of this header will be based on the available topology information. It will be a list of SIP-URLs, all or part of which may be wildcarded to indicate that the EP is happy to let the CM forward the INVITE to the next CM using the forking mechanism. An originating AM may choose to examine a number of possible routes for a new session. The same Call-ID will be used for each of these, with differentiation performed by a new header type called ALTERNATIVE. Each of these routes will be assigned a favourability ranking that will be based on the originating AM's view of the network congestion. As an INVITE traverses the Management Layer, it creates a temporary reservation in each of the CMs it passes through along the tunnel in the direction it is forwarded. These reservations are temporary and will time out if not confirmed. At the same time as making this reservation, the Record-Route header is filled in with the SIP-URL of the forwarding CM. These reservations can subsequently be confirmed by responding with a 200 OK over the chosen route, using the Record-Route header as the Route header for the response. All other reservations will subsequently time-out. This Record-Route therefore contains a list of nodes that can be converted into the set of IP addresses used to perform the end-to- end LSP negotiation using CR-LDP on the MPLS network. The destination AM will choose a route for the session by convolution of its view of the network congestion, with the rank assigned by the originating AM. Congestion and topology information will be built up using REGISTER messages. When a new LSP is created, a REGISTER message will be issued stating the start and end of the LSP and its total capacity. Subsequent REGISTERs will be sent to update other MNs with the Gibson 11 Managing MPLS for QoS October 1999 current available capacity of the LSP. The contents of these messages may be tunnelled within ACKs too. The REGISTER will also perform a secondary role of advertising the domains reachable via a Core CM. This information will be gleaned from LSP adverts for LSPs terminating on AMs. It will subsequently be propagated back to all other AMs to enable route selection. Reservation removal will be performed using a standard BYE message that has the Route header of the ACK. The Call-ID will be used to identify the reservation and the bandwidth will be freed up. The state needed in a CM can therefore be limited to the Call-ID and the reservation size description. 6.1 Advantages of the combined SIP/COPS approach There are a number of key features of the combined SIP/COPS protocol approach that create a compelling argument for its use. It is possible to provide Grade of Service (GoS) functionality at the network edges. When a COPS request is received at an AM, it may be immediately rejected if there is insufficient bandwidth on any of the LSPs that terminate on that AM. This session request is therefore blocked at the edge of the network. This is fundamental for controlling mass calling events, which will be a major concern if the Internet evolves to perform a core role in the global PSTN/ISDN network. The scheme provides a method of dynamic traffic engineering whereby sessions are routed via a number of optional paths taking into account the current traffic commitments of each of the options. The amount of session-state stored in the core of the network is kept to a minimum by logging only the reserved bandwidth for the session along each of the LSPs it uses to traverse the network. Only the AM stores a full set of session information, including the route taken across the network. The tunnel advertisement scheme can be seen to operate in two modes. Where the network is a closed entity, owned entirely by a single operator, the advertisement mechanism resembles an Interior Gateway Protocol with Core CMs advertising the exit points from the network. If, however, the network can be thought of as being split across a number of administrative domains, the advertisements act in a manner similar to a Border Gateway Protocol, where LSPs can link domains together. Indeed in the limit, each set of LSRs might be considered to be a network in its own right, with the CM advertising the availability of routes through it. This implies some form of recursive implementation and should be regarded as an area for further study. Gibson 12 Managing MPLS for QoS October 1999 7. Core Transport Layer The Core Transport Layer can be implemented on any QoS capable IP network - it is likely that this will be an MPLS[6] network running CR-LDP[7] or RSVP[8]. This basic network is then constrained by imposing a pre-configured network of trunk LSPs ontop of it. The configuration and capacity of these trunk LSPs may be updated at any time, though major rearrangement should be avoided. Each of these trunk LSPs has a known capacity and its presence is registered with the Management Node associated with the router at the upstream end of the tunnel. Should the parameters of the IP tunnel change during its lifetime, this should be registered with the CM. This is achieved using the interface indicated by $ and ! in Figure 1. The interaction between the Transport and Management Layers centres on the determination of a route across the Transport Layer by the Management Layer. As the MPLS routers that constitute the Transport Layer will be running routing protocols such as OSPF, they will be additionally capable of carrying standard IP traffic. The Transport Layer must therefore be able to differentiate between establishing a normal session that must use not use one of the pre-configured tunnels and one it is instructed to setup by the Management Layer which must use the pre-configured tunnels. Similarly, any such normal traffic must not affect the performance characteristics of the managed tunnel network. Indeed, as the size of a tunnel increases it will squeeze the bandwidth available to non-tunnelled sessions such that, in the limit, there will be no capacity for anything other than the tunnelled sessions. When instructed to initiate a new session, the originating Endpoint should receive a list of the nodes this new session should pass through, all of which will be endpoints of the Transport Layer tunnels. When the Transport Layer establishes the path for this new session it should treat each tunnel as a single hop and negotiate the session accordingly. For example, in an MPLS network each IP tunnel may traverse a number of routers, however it will only be assigned a single label for this entire path. So by applying this label to a new session, this session is automatically routed to the correct next router. There may be an advantage, in such a case, in applying a 2-label stack with the bottom label identifying the session to allow for fast forwarding at the next router. 7.1 Endpoints An Endpoint as described in this framework can be one of two types. The EP can be either a freestanding source of IP sessions that are Gibson 13 Managing MPLS for QoS October 1999 generated and terminated at the EP, or it acts as a Gateway to an IP LAN. The Endpoint must perform a number of functions. It must be able to receive and act on all incoming messages received from the Call Server. These will arrive over the : interface and may, for example, use MGCP/H.248 protocols. Typically these will be connection requests. These messages must be sufficiently detailed that the Endpoint can request a new reservation from its Admission Manager. Having received a success or failure response, this must be indicated back to the Call Server. The Endpoint must act on a new session stimulus and issue a modified form of this request to the Admission Manager. It should present the QoS requirements of the session and the IP address of the end user and the IP address of the EP through which the session will be routed and to which an IP tunnel must be found. Having received a success indication, the EP must also initiate the reservation for the session across the Core Transport Layer and the mapping of the new session characteristics to the outgoing IP tunnel identifier. 8. Session Establishment Process This section now provides a framework for a call walkthrough to setup a single session across the framework architecture. 8.1 Call Server Session Stimulus There are two basic types of stimulus for a new session. The first type has its origin in the ITU and will typically generate a Q.931 SETUP message. This may be an H.323 terminal, or a PSTN handset. This type of stimulus will be directed to and handled by the Call Server. Using ISUP, SIP with MIME encoded ISUP, BICC or some other protocol, the originating CS contacts the correct destination CS. This will regenerate the correct PSTN type signalling and call the destination terminal. The destination CS will receive back an alerting message, showing that the terminal has been located, which will generate a provisional response from the destination CS. The originating CS should now setup the EP using megaco/MGCP, creating the necessary Tx/Rx connections. The Tx request must contain the IP address of the destination EP and the session's QoS characteristics. Note that the session request can be refused at this point if there is insufficient outgoing capacity at the EP to accommodate the new session. The CS must wait until the outgoing port has been allocated on the originating EP (indicated by a success megaco/MGCP response) before Gibson 14 Managing MPLS for QoS October 1999 it can send a connect message back to the calling terminal - on receipt of this message, the calling terminal can expect to begin transmission of its media. 8.2 IntServ stimulus A second form of session stimulus is that generated by RSVP. Under this mode of operation, an RSVP Path message will be sent by the calling terminal and received at the originating EP. This Path message must be forwarded, using an IGP/OSPF, to the correct destination EP. The EPs will therefore be the next and previous-hop RSVP routers to each other with the MPLS core treated as a non-RSVP IP network. When the called terminal receives the Path message it generates a Resv response as normal which propagates back to the destination EP. The next hop RSVP router for this message is now the originating EP and the Resv is forwarded back across the MPLS network to the originating EP. The originating EP now has sufficient information to make a reservation request across the network, as it knows both the destination EP and the size of reservation. It must, however, not continue to forward the Resv to the calling terminal until it receives confirmation that the reservation has been successfully made. 8.3 Path Determination The calling Endpoint now has all the information to request a path across the Core Transport Layer. It now sends a request to its Admission Manager detailing the destination Endpoint, called user and the bandwidth characteristics for the session. The bandwidth characteristics for the session may have to be derived from the QoS indicated by the CS. For example an MPEG video stream will have no fixed parameters so the AM may have a configured set of bandwidth characteristics for such a stream. These will probably be decided by the network provider operating the network proposed in this draft and is likely to be a function of the level of service paid for by the calling user. This area is beyond the scope of this draft. Having received a request for a new path across the network, the Admission Manager firstly examines the destination EP address. Using the set of topology information the AM has stored, it determines the set of available paths to the destination EP. Typical processes for making this decision may include: - If the AM has previously established a session to this EP, it may choose to make a reservation for this new session over one of these paths (bandwidth permitting). The EP will always store the path used for each of its sessions. Gibson 15 Managing MPLS for QoS October 1999 - If the AM knows of a free path to the midpoint of the network, it may choose to use this path, leaving the MNs over the last two hops to determine the path to the destination EP. - If there is a particular area of congestion within the network, the AM may simply choose to route away from this area. If the routers in the Transport Layer are arranged in clusters of similar IP address, this can be accomplished by specifying a route including a cluster of routers away from the congestion. Whichever of the above processes the AM uses to pick its path, it forms a list of the Routers it wishes the session to traverse. The router definition can take one of three forms, either an explicit IP address, a partially wildcarded domain name specifying a cluster or a completely wildcarded entry. However, the final element in the list must be the IP address of the destination EP. Having decided on one or more paths for the new session, the calling EP now assigns a preferential rank to each of the paths, based on its routing policy and perceived picture of the network congestion. This will be used later to determine which path to take. 8.4 Path Reservation Path reservation is performed using the extended SIP protocol described in [5]. A brief description only will now be given. An INVITE message will be generated for each of the paths across the network determined by the previous phase. An SDP description of the session is added to this INVITE that describes the size of reservation to be made. A Route header is also added that contains the route to be taken across the network. The route is ranked by the AM and this is also included in the INVITE. The INVITEs are forwarded based on the Route information they have, Where a choice of next hops is possible (i.e. the next hop is wildcarded) the MN making the forwarding decision does so based on the topology information it has received via REGISTER messages. Each MN traversed by the INVITE records its presence in the path by adding an entry to the Record-Route header of the INVITE. It also makes a temporary reservation of resource for the session. At the destination AM, a number of INVITEs will be received. The AM will examine the Route they have taken and determine its own ranking for each. By convolution with the original values, one of the Routes will be chosen. A 200 Ok will be sent back across this route which has the action of confirming the previously temporary reservation along each of the LSPs in the path. The receipt of this 200 OK by the originating AM is signalled using an ACK. Gibson 16 Managing MPLS for QoS October 1999 8.5 Path Choice Signaling Having decided on a path and reserved the bandwidth for the new session at the Management Layer, the path choice should be signaled by the calling AM to its associated EP. This message must include the exact path across the network and may include the session description. Having received the path details, the Network Layer should use this path information to setup the path across the network. In an MPLS network this will mean running either CR-LDP or RSVP to establish label mappings at each of the routers for the new session. The path may now be established between the routers in the chosen path. As the Management Layer has previously determined that the IP tunnels between each of these routers has enough free space to accommodate this new session, a simple mapping may be formed at each router for the session between the ingress and egress IP tunnels at each router. However, it is recommended that a QoS capable mechanism be used which performs a final check of the free space. 8.6 Success Indication Having setup the path in the Transport Layer for the new session, the EP should indicate this back to the CS that requested it. The EP must also be sure to maintain a mapping between the called user's IP address and the new session path, as this path has only been established to the called EP. The user may be a terminal attached to this EP, especially if this EP is a gateway or some similar entity. At this point the network should be completely configured to handle the new session and once the CS knows the path is complete it can indicate to the user that it may begin streaming. 8.7 Tear-down When a session is to be removed, the following sequence must be followed. Firstly the originating EP must instruct the Transport Layer to remove the label mapping established by CR-LDP for the new session. Secondly, the EP must send a session remove message to the AM. The AM now sends a reservation remove message across the Management Layer using the exact route used by the INVITE. At each MN the message passes through, the previously made reservation must be removed and the available capacity of the tunnel updated. Gibson 17 Managing MPLS for QoS October 1999 9. Session Policing The network architecture proposed in this framework document has an obvious need for close policing of the sessions it carries to see that they adhere to their QoS characteristics. The reservations on each IP tunnel are made with respect to the requested requirements of the session. Not only are future admission decisions made on the basis of this request but the ability to sustain the existing tunnel contents is based on this. Should this new session now exceed its stated requirements, not only might new sessions be admitted which the IP tunnel cannot sustain but it may cause degradation of service of existing sessions. It is therefore recommended that the Endpoints perform a policing function on each of their flows. This may take the form of filtering the session traffic such that it never exceeds its negotiated parameters. Routers in the Transport Layer may also support session policing and provide feedback on sessions regularly exceeding their agreed limits. The mechanisms for enforcing session policing are beyond the scope of this draft. 10. Security Considerations The Network Core of the proposed network has a level of implicit security due to its use of IP Tunnels - a construction that is commonly used to implement Virtual Private Networks. The content of the session should therefore be secure from eavesdropping. To increase the security of each of the sessions, it is recommended the session setup protocol in the Management Layer use IPSec encapsulation. 10.1 Authentication The EPs at the edge of the network must provide the authentication functionality to control access to the network. Each user of the network should undergo an encrypted password authentication process. Also, as the network is likely to be a premium service to which users subscribe, there may be an additional lookup process against a central database of users when a user becomes active. 11. Future Work It is intended to address the following in future versions of this draft: The use of IntServ/DiffServ at the edge of the network to provide a session stimulus. Gibson 18 Managing MPLS for QoS October 1999 The recursive use of the SIP extensions to allow negotiation between multiple networks, each seen to be controlled by a single CM. OA&M mechanisms to be supported by the COPS interface between the Management and Transport Layers. How is the available capacity information restored? 12. Notice Regarding Intellectual Property Rights Nortel Networks may seek patent or other intellectual property protection for some or all of the technologies disclosed in the document. If any standards arising from this disclosure are or become protected by one or more patents assigned to Nortel Networks, Nortel Networks intends to disclose those patents and license them on reasonable and non-discriminatory terms. Future revisions of this draft may contain additional information regarding specific intellectual property protection sought or received. 13. References 1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 D. Skran, (Rapporteur), "Packet based multimedia communications systems", ITU-T Recommendation H.323 version 2, October 1997. 4 M. Handley, "SIP: Session Initiation Protocol", RFC 2543, March 1999. 5 M. Gibson, "Use of SIP for the Reservation of QoS guaranteed Paths", draft-gibson-sip-qos-resv-00.txt, October 1999. 6 R. Callon et al., "A Framework for Multiprotocol Label Switching", draft-ietf-mpls-framework-04.txt, July 1999. 7 B. Jamoussi (editor), "Constraint-Based LSP Setup using LDP", draft-ietf-mpls-cr-ldp-01.txt, February 1999. 8 D. Awduche, "Extensions to RSVP for LSP Tunnels", draft-ietf- mpls-rsvp-lsp-tunnel-02.txt, March 1999. 14. Acknowledgments My thanks to Loa Andersson, Roy Mauger, Simon Brueckheimer and Dave Stacey of Nortel Networks and Jon Crowcroft for useful discussion of Gibson 19 Managing MPLS for QoS October 1999 the concepts and solutions. Also for their encouragement during the development of the ideas for this architecture. 15. Author's Addresses Mark Gibson Nortel Networks London Road, Harlow, Essex, England, CM17 9NA Phone: +44 1279 402621 Email: mrg@nortelnetworks.com Gibson 20 Managing MPLS for QoS October 1999 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Gibson 21