Internet Draft M. Gibson Internet Draft Nortel Networks Document: draft-gibson-manage-mpls-qos-01.txt March 2000 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. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt 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 introduces a set of requirements that must be fulfilled in order that an MPLS network can support QoS-dependant IP flows as set out in the VoMPLS draft [2]. A candidate architecture that conforms to these requirements is then set out. 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 essential components needed to implement such a network and suggests suitable technologies for each of them. Gibson Informational - Sept 2000 1 MPLS QoS management March 2000 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 [3]. 2.1 Terminology and Abbreviations Label Switched Path (LSP) - an MPLS path between two MPLS routers. 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 Gibson Informational - Sept 2000 2 MPLS QoS management March 2000 QoS requirements of particular sessions and 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 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 discuss the set of requirements needed by a network to support real-time services, such as those described in the VoMPLS architecture draft and then to suggest a suitable network architecture. In this draft, the term network refers to a core/backbone IP network that typically connects traffic between edge LANs. 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 QoS network Requirements In order to support such media streams there are a number of key requirements that a network aiming to provide QoS should meet. These requirements include those listed below. Traffic engineering principles should be supported so that sessions can be directed along the best route and can have their resource pre-allocated. This should be performed in conjunction with aggregation in the core of the network. 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. Reservation set-up time should be minimised by reducing the number of round-trips needed to establish the QoS for the session. Session rejection should occur at the network edge such that a session can be refused before any resource is allocated if the network cannot bear it. Gibson Informational - Sept 2000 3 MPLS QoS management March 2000 The route selected for a particular session must be based on not only the bandwidth but also the latency parameters for the session. Individual session security should be provided for 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. Any such network should be part of a scalable solution that could be extended from very small to very large networks. Finally, as mentioned previously, any such network must aim to satisfy the work captured in the VoMPLS draft [2]. 3.2 Proposed Solution In order to meet the requirements set out above, it is suggested that a VPN based network is the optimal solution. There is automatic aggregation of the traffic carried across the network and the topology over which it is carried can instantly be reduced in complexity. This helps to optimise the route-selection across such a network. When MPLS is used as the technology to achieve this VPN network, using CR-LDP or RSVP-TE to establish the LSPs, it becomes possible to describe the size and latency of the tunnels that comprise the VPN. It also becomes possible to optimise the characteristics of particular tunnels to support particular traffic types, or to control the mix of traffic that is transported over that tunnel. It is also possible to pin the route of a tunnel, thus avoiding packet re-ordering problems during re-routing of flows, bringing a degree of what you see is what you get certainty to the chosen route. In addition, the ongoing MPLS fast re-route/protection work being conducted currently within the IETF brings an extra degree of security to the network. There is also the ability to perform Traffic Engineering techniques on the VPNs such as time of day resizing. There is also the ability to pre-scale the network in certain areas to deal with predicted irregular surges such as mass-calling events for football tickets. If the MPLS network runs LDP too this has the advantage that the network operator can continue to run normal best-effort traffic across the same backbone network in support of web-sessions and those customers who don't require QoS guarantees. The network architecture proposed in this document suggests a unified solution to all of the above requirements. This solution is specified using three distinct layers described briefly below. More detail of their operation is found in later sections. Gibson Informational - Sept 2000 4 MPLS QoS management March 2000 3.2.1 Session Control This layer is primarily responsible for performing endpoint location for the session - determining the exit point from the network. With the increasing popularity of Internet telephony, this refers primarily to the use of Call Servers (CS) at the edge of a network. However, it may also encompass the use of application proxies (Px) at the network edge for non-telephony sessions. The Session control layer will typically determine the QoS characteristics of the session being established. In SIP this will be in the form of an exchange of SDP profiles, in H.323 this would be via H.245 signalling. Figure 1 Functional Composition of network Session Control +--+ +--+ |CS|''''''''''''''''''''''''''''''''''''''''''''''|CS| |Px| |Px| +--+ +--+ : : : : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ : Core Management : : /\ /\ /\ /\ /\ : :-----|CM|--------|CM|--------|CM|------ : : \/ \/ \/ \/ \/ : : ! $ $ $ ! : : ! $ $ $ ! : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ : ! Core Transport $ $ ! : : ! $ $ $ ! : +-----+ +--+ +--+ +--+ +-----+ | EP |======|R1|========|R2|========|R3|======| EP | +-----+\\ +--+\\ //+--+\\ //+--+ //+-----+ \\ \\ // \\ // // \\ \\// \\// // \\ \/ \/ // \\ /\ /\ // \\ //\\ //\\ // \\ // \\ // \\ // +--+// \\+--+// \\+--+ |R4|========|R5|========|R6| +--+ +--+ +--+ Gibson Informational - Sept 2000 5 MPLS QoS management March 2000 3.2.2 Core Management The Core Management Layer consists of the necessary control modules needed to administer session path determination and reservation across the core network. It also comprises the control protocol that operates between these elements that performs the route determination function. The requirements and possible solutions to this are discussed later in this draft. This layer contains two main element types that perform subtly different functions. The first is an Admission Manager (AM) which responsible for initiating and terminating path reservation requests. If there are a number of path choices across the network, the decision to choose one over all the rest is made here. The AM stores the reservation state associated with each session established across the network. The AM is tightly bound to its Endpoint (EP). The other element that comprises this layer is referred to as a Connection Manager (CM). The Connection Manager is responsible for the management of the IP tunnels of its associated routers. Each must maintain a database of all the managed tunnels 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. Figure 2. Connection Manager to Router Coupling /\ /\ |CM|--------------------|CM| \/ \/ $$$ $$$ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ +---+ $ $ +---+ $ $ |R17|====================|R27| $ $ +---+ $ $ +---+ $ $ $ +---+ +---+ $ $ |R14|==============|R25| $ $ +---+ +---+ $ $ $ +---+ +---+ |R12|==========================|R28| +---+ +---+ Each CM may control more than one Router, as shown in Figure 2. A CM, in contrast to an AM, only stores aggregate state on a per Gibson Informational - Sept 2000 6 MPLS QoS management March 2000 tunnel basis. 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). 3.2.3 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. Endpoints (EP) will typically be an edge router. Each EP is the point of origination/termination of a session on the Core Transport layer. The elements R1,2,3 are 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. The elements R4,5,6 are Routers providing alternate paths and are controlled by the CMs of R1,2,3 respectively. It should be noted that the Core Transport Layer consists of more routers than are indicated, namely those that support the tunnels. However from the point of view of the topology, these are in effect hidden and they will not appear as routes across this network. 3.3 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 Gibson Informational - Sept 2000 7 MPLS QoS management March 2000 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 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 Details 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 [4] or by SIP [5] Proxies. 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 (or SIP-T) 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 Details 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 Gibson Informational - Sept 2000 8 MPLS QoS management March 2000 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. IP tunnel state information is gathered locally at the network edges by AMs to enable more accurate route selection. In the 4-hop topology used in this document, it is only necessary to know the state of the network two hops out. Both local and remote ends of the network can therefore combine their restricted views to gain information about the possible paths across the whole network. Similarly, providing each AM maintains an accurate picture of the state of each flow that a reservation has been made for across the network, it is not necessary to store it across the core network too. As most telephony and streaming applications have well-behaved tear-down behaviour, it is possible to remove from the aggregate state stored across the network, the amount assigned to a session when it is stopped. 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. Gibson Informational - Sept 2000 9 MPLS QoS management March 2000 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. The Admission Manager is responsible for initiating and terminating new session reservation 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 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 push mechanism will be used to pass down route information. 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. Gibson Informational - Sept 2000 10 MPLS QoS management March 2000 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 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 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 Gibson Informational - Sept 2000 11 MPLS QoS management March 2000 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. These requirements are examined in more detail in [6] and include a candidate solution based on extensions to the SIP protocol. Any other protocols considered for this use must meet the requirements set out in this document. Other protocols that might be used include Boomerang [7] and YESSIR [8] as both store state information at the edge of the network. 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. 6. Core Transport Layer Details The Core Transport Layer will typically be implemented over an MPLS network running CR-LDP [9] or RSVP-TE [10], although any network capable of QoS based aggregation could be used. 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 Gibson Informational - Sept 2000 12 MPLS QoS management March 2000 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. 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. 6.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 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 megaco/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. 6.2 Interface to Core Management Layer It is recommended that in the network described in this document, the interface between the MPLS and Core Management Layers should be implemented using COPS. This provides flexibility in the manner in which information is passed over between the two layers that is Gibson Informational - Sept 2000 13 MPLS QoS management March 2000 necessary in this model. It also provides a sychronisation mechanism to ensure that the Management Nodes have the most up-to-date view of the state of their tunnels possible. 7 Key Functionality Provided by the Network Architecture It is possible to extend Grade of Service (GoS) functionality to 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 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. 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. Gibson Informational - Sept 2000 14 MPLS QoS management March 2000 However, the session could just as easily be established using a SIP INVITE. This will still be handled by the CS but in its Proxy guise. If the network is a single cloud, the Proxy will now use a protocol like TRIP to determine the destination Proxy for the call. If the call signalling must traverse multiple clouds, one or more transit- type proxies will feature in the signalling path. 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/H.248, 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 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. Alternatively, the RSVP message may be explicitly tunneled across the MPLS 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 not continue, however, to forward the Resv to the calling terminal until it receives confirmation that the reservation has been successfully made. Gibson Informational - Sept 2000 15 MPLS QoS management March 2000 An alternative to this method is to trigger a reservation on the receipt of the Path message and to size it according to the TSpec. Then if the reservation size is subsequently reduced in the Resv message, the reservation across the MPLS network can be reduced. 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 COPS interface from the EP therefore acts as a unifying protocol and the AM remains unaware of the initiating protocol. 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. - 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. Gibson Informational - Sept 2000 16 MPLS QoS management March 2000 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 can be performed by the extended SIP protocol as described in [6]. 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 the 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. 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. The method by which this is signalled must conform to one of the explicit route descriptions that either CR-LDP or RSVP-TE understands. This implies one of a list of explicit nodes, LSP-Ids or a mixture of the two. Having received the path details, the Network Layer should use this path information to setup the path across the network. In an MPLS Gibson Informational - Sept 2000 17 MPLS QoS management March 2000 network, this will mean running either CR-LDP or RSVP-TE 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. 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 based on this request but also 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. Gibson Informational - Sept 2000 18 MPLS QoS management March 2000 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. 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 Gibson Informational - Sept 2000 19 MPLS QoS management March 2000 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 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 A. Kankkunen et al., "Voice over MPLS Framework", draft- kankkunen-vompls-fw-00.txt, March 2000. 3 S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 4 D. Skran, (Rapporteur), "Packet based multimedia communications systems", ITU-T Recommendation H.323 version 2, October 1997. 5 M. Handley et al., "SIP: Session Initiation Protocol", RFC 2543, March 1999. 6 M. Gibson et al., "Requirements for a Scalable Protocol for the Reservation of QoS guaranteed Paths", Work in progress. 7 D. Ahlard et al., "Boomerang - A SIMPLE Resource Reservation Framework for IP", draft-ahlard-boomerang-framework-00.txt, February 1999. 8 Ping Pan & Henning Schulzrinne "YESSIR: A Simple Reservation Mechanism for the Internet", Proc. International Workshop on Network and Operating System Support for Digital Audio and Video (NOSSDAV), July 1998. 9 B. Jamoussi (editor), "Constraint-Based LSP Setup using LDP", draft-ietf-mpls-cr-ldp-01.txt, February 1999. 10 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 of UCL for useful Gibson Informational - Sept 2000 20 MPLS QoS management March 2000 discussion of 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 Informational - Sept 2000 21 MPLS QoS management March 2000 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 Informational - Sept 2000 22