CCAMP M. Gibson Internet Draft Nortel Networks Document: draft-gibson-mpls-srcroute-00.txt February 2001 Category: Informational Achieving Assured Service Levels through Source Routed MPLS Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [STANDARD]. 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. Abstract This memo sets out an MPLS-based solution to the IP service delivery problems as set out in RFC 2990. The solution is based on source routing of IP flows using MPLS label stacks. The solution elements are introduced sequentially and a usage scenario is mapped out that aligns with the work in the ISSLL working group. 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 [KEY-WORDS]. Gibson Informational - August 2001 1 draft-gibson-mpls-srcroute-00.txt Feb 2001 Table of Contents Abstract.......................................................1 Conventions used in this document..............................1 1.0 Introduction...............................................3 1.1 Background to Solution....................................3 1.2 Scope of the Solution.....................................4 2.0 Key Network Components.....................................4 2.1 Flow Aggregation Schemes...................................5 2.2 Network Configuration and Control..........................5 2.2.1 Core Configuration.......................................7 2.2.2 Core Management..........................................7 2.2.3 Cross-connecting LSPs....................................8 2.2.4 Alternate XC label distribution mechanisms...............9 2.2.5 Source Routing..........................................10 2.2.6.1 Scalability...........................................11 2.2.6.2 Alternative Source Route discovery mechanisms.........11 2.3 Admission Control.........................................12 2.4 Route Selection...........................................13 2.4.1 Destination Service Notification Techniques.............14 2.5 Application of VPN techniques.............................15 2.6 Inter-operator requirements...............................16 2.7 Protection Strategies.....................................16 2.7.1 Protection across an AS.................................16 2.7.2 Protection of sessions..................................17 2.8 Applicability to RSVP aggregation.........................17 3.0 Future work...............................................18 4.0 Intellectual Property Considerations......................18 5.0 Security Considerations...................................18 6.0 References................................................18 7.0 Acknowledgments...........................................21 8.0 Author's Addresses........................................21 Appendix A....................................................22 Full Copyright Statement......................................24 Gibson Informational August 2001 2 draft-gibson-mpls-srcroute-00.txt Feb 2001 1.0 Introduction RFC 2990 [RFC 2990] entitled "Next Steps for the IP QoS Architecture" highlights the outstanding architectural issues relating to the wide- scale deployment and use of QoS mechanisms within IP networks. This memo proposes some of the key elements of an architectural solution to solve the identified issues. It is based on a source routing paradigm that builds upon key elements and protocols contained within MPLS, Intserv, Diffserv and VPNs. Minor extensions to the main protocols in these areas necessary to implement this solution are outlined. The reason for pursuing source routing is that if the service availability of each network element in a route can be known at source, then packets can be routed across a network with absolute service guarantees. By maintaining a number of independent source routes, it is possible to achieve the traffic engineering and load balancing vital to QoS routing. It is therefore possible to remove the need for crankback during path computation, while achieving the same functionality. Finally source routing retains the network intelligence at the edge of the network and therefore sits comfortably with current Internet technologies. 1.1 Background to Solution RFC 2990 defines the key objectives an IP QoS architecture as: o To control the network service response such that the response to a specific service element is consistent and predictable. o To control the network service response such that a service element is provided with a level of response equal to or above a guaranteed minimum. o To allow a service element to establish in advance the service response that can or will be obtained from the network. o To control the contention for network resources such that a service element is provided with a superior level of network resource. o To control the contention for network resources such that a service element does not obtain unfair allocation of resources (to some definition of 'fairness') o To allow for efficient total utilisation of network resources while servicing a spectrum of directed network service outcomes. Gibson Informational August 2001 3 draft-gibson-mpls-srcroute-00.txt Feb 2001 It concludes that to meet these, in their current form neither the solutions proposed in the IntServ or DiffServ working groups provide a full solution. It is suggested that some middle ground solution, borrowing from the best practices of both solutions would provide an optimum solution. This memo also takes this view, and offers a network outline building upon the mechanisms of both solutions and scoping possible enhancements to their operation. Consideration is made of suitable core aggregation techniques that permit service level guarantees to be honoured. The proposal includes methods of determining the most favourable aggregate flow paths across a network core onto which a flow might be mapped. This uses core network state feedback and several methods by which this might be achieved are outlined. The target services for the proposed solution can be referred to as those that generate Real Time over IP (RToIP) flows. It is anticipated that all such services will generate some form of signaling (and negotiation) prior to the transmission of their first packet. 1.2 Scope of the Solution The scope of this solution is to recommend the protocols that could be used to construct a network that meets the requirements specified above. Where appropriate, useful extensions to these protocols are specified. Included in this approach is a view on how these extensions would be integrated with RSVP. Out of scope of this memo are examples of specific application level stimulus protocols for RToIP flows and the means by which the establishment of the parameters and endpoints of such flows are negotiated (e.g. SIP). Also, there will be no detailed consideration of how QoS requirements in the collector LAN networks at the edge of the core network will be provided. 2.0 Key Network Components This sections aims to set out both the key functional components for a network that supports the requirements set out in [RFC 2990], and a set of candidates that fulfil the functionality. The basic premise for the overall network topology is that the core will consist of a number of Autonomous Systems (AS) across which RToIP flows will be routed. Each AS will operate some form of logical mesh of connectivity, in that all exit points of the AS are reachable from any entry point. Users will gain access to this network via an Edge Router (ER) that sits at a logical edge of an AS. These users will typically be part Gibson Informational August 2001 4 draft-gibson-mpls-srcroute-00.txt Feb 2001 of a LAN, or other such collector network. It will be assumed that users will signal their service level requirements using RSVP. This signalling will be used by the network to determine a suitable path across the network that can support the Service level requirements of the flow (without impacting the service experienced by existing flows). No RSVP Path state will be stored in the core network. The core network will consist entirely of aggregate flows. 2.1 Flow Aggregation Schemes Two flow aggregation schemes offer themselves as candidates for the network core. The most obvious of these of DiffServ, which relies on edge based admission control to a set of forwarding behaviours across a network. This is a relatively simple solution but it is limited in that it is only possible to manage the total network resource of a service class, rather than on a per-destination basis. Recent work has enhanced this basic operation using a combined DiffServ and MPLS approach described in [DIFF_MPLS] that permits the assignment of a forwarding behaviour to an LSP. By further extending this to encompass explicit routing of LSPs across a network and adopting the use of L-LSPs, the resource on a network can be partitioned and allocated to each aggregate flow. By then performing Policy-based admission control to each LSP, the service requirements for an RToIP flow can effectively be met. However, as most RToIP flows are described by bandwidth constraints, if explicitly routed LSPs are to be used it would possibly be more straightforward to use the bandwidth definition mechanisms that already exist for ER-LSPs in their negotiation protocols RSVP-TE and CR-LDP. This makes the monitoring of available resource on these LSPs more straightforward. This memo will therefore adopt the use of CR-LDP or RSVP-TE to establish known bandwidth ER-LSPs, noting that explicitly routed L- LSPs could also provide a workable solution. 2.2 Network Configuration and Control For large national and international networks it is assumed that typical RToIP flows will have to traverse two or more Autonomous Systems. Furthermore it is assumed that each AS will be configured with a full mesh of MPLS LSPs. These LSPs provide connectivity between the edge points of the network. The case of ASs that are too large to such that this full mesh assumption is invalidated is for further study. Gibson Informational August 2001 5 draft-gibson-mpls-srcroute-00.txt Feb 2001 The LSPs on each AS are provisioned by an off-line Policy Management function (see later section for details). The Policy Manager is responsible for configuring the connections across an AS. This function therefore maintains a topological picture of the connections on the AS. In addition to defining the service connectivity across the AS, the Policy Manager is also responsible for defining the MPLS recovery strategy to be used. This also forms a part of the delivered service level by providing a prescribed level of service continuity. In order to control the allocation of network resource, admission control is enforced at the edge of each AS. Each ER is administered by a controller termed an MPLS Bandwidth Broker (MBB). An MBB may control more than one ER, though a single ER will only be controlled by a single MBB. The interconnection of these control elements can be seen in Figure 1. Figure 1. Architectural components of RToIP solution +-------+ +-------+ |Policy | |Policy | "|Manager|" "|Manager|" " +-------+ " " +-------+ " " " " " " " " " +---+ +---+ +---+ "+---+ |MBB| |MBB| |MBB| |MBB| +---+ -------- +---+ +---+ -------- +---+ : // \\ : : // \\ : : // \\ : : // \\ : : / \ : : / \ : : | | : : | | : +--+ +--+ +--+ +--+ |ER| AS |ER****ER| AS |ER| +--+ +--+ +--+ +--+ | | | | \ / \ / \\ // \\ // \\ // \\ // -------- -------- Gibson Informational August 2001 6 draft-gibson-mpls-srcroute-00.txt Feb 2001 2.2.1 Core Configuration Each AS in the core network is configured with a logical mesh of LSPs with a defined service level between known ERs. This provides each ER with a route, defined by a single LSP, to each other ER on the AS. Routing decisions are therefore simplified to choosing the correct LSP for the destination IP address of the RToIP flow. To support multiple services with diverse characteristics, the mesh may be extended to have a number of logically parallel LSPs between a set of edge points, each configured to handle certain service types. 2.2.2 Core Management The configuration of the network is controlled by the Policy Managers shown in figure 1. These are responsible for the service level specific policy that is used to define connections across each AS. This policy information can be described using the MPLS Policy information model defined in [chadha]. The Policy information might also contain the SLAs of the users who access the network. Knowledge of this information will help the Policy Manager decide how to configure the network initially. By creating dynamic SLAs that can be added as required and whose requirements might change over time, it is also possible to add dynamic reconfiguration of the network into the suite of network services. The Policy information at the Policy manager is converted into provisioning information at the MBB. The MBB then uses this to provision each of its ERs with the necessary connections across the AS to support the services offered. The MBB therefore has a complete knowledge of the reachable nodes (i.e. other ERs) from an ER it controls, the label(s) that identify each of these connections and the service levels supported by each connection. The MBB can use either SNMP/SNMPCONF with suitable MPLS-TE MIBs [LSR- MIB, LDP-MIB, TE-MIB] or COPS-MPLS [COPS-MPLS] with a suitably developed PIB for this function. In some scenarios this may offer a sufficient level of management. Each MBB can set the forwarding rules for each type of RToIP flow at the edge of an AS. When a packet arrives at the end of its previous LSP, its IP header is processed and a suitable next-hop LSP is determined. This fails to address the issue caused by inconsistent SLA mapping of the packet onto a forwarding LSP. The issue of establishing the service level across the boundaries of a ASs is therefore considered in the following sections. Gibson Informational August 2001 7 draft-gibson-mpls-srcroute-00.txt Feb 2001 2.2.3 Cross-connecting LSPs The Multiprotocol Label Switching Architecture specification [RFC 3031] introduces BGP-4 as a method of piggy-backing label information between edge routers. This label distribution technique originated in work that used BGP as a VPN label distribution mechanism [RFC 2547], however the methodology is documented separately as a standalone technology [BGP-MPLS]. BGP-MPLS provides two key features that can be used in the implementation of guaranteed service networks that span Autonomous Systems. o Labels distributed in a BGP Update message may be used to indicate that a certain destination (defined in the Network Layer Reachability Information (NLRI) field) is reachable via the router identified in the Next Hop field of the Update message. o A BGP speaker may maintain (and advertise to its peers) more than one route to a given destination, as long as each such route has its own label(s). Consider the network configuration shown in Figure 2. The routers L and M on Autonomous System AS1 are BGP peers with routers J and K on Autonomous Systems AS2. Both J and K advertise themselves as providing connectivity to D. In AS1, L advertises itself as the Next Hop to D on AS 2 and associates this route with label La. Lilkewise M advertises a route to D on ASS2 and associates a different label, Lb, with this route. At router O, there therefore exists two possible routes to D via two next hops, either of which it may choose. AS1 and As2 are thus configured with a full mesh of LSPs between edge routers. The label that identifies the LSP from O to L is Ll and the corresponding label to reach M is Lm. The label stack used at O to identify the route to D would consist of the top label used to reach the chosen next hop router and the bottom label used to reach D e.g. Lm/Lb or Ll/La. Gibson Informational August 2001 8 draft-gibson-mpls-srcroute-00.txt Feb 2001 Figure 2 Cross connection of LSPs using BGP labels -------- | -------- // \\ | // \\ / \+---+ |+---+/ \ / AS1 <- | L |-+| J | AS2 \ | La +---+ |+---+ | +---+ | | | +---+ | O | | | | | D | +---+ Lb +---+ +---+ +---+ \ <- | M |-+| K | / \ /+---+ |+---+\ / \\ // | \\ // -------- | -------- +-> | | common subnet The labels La and Lb identify the next-hop LSP on AS2 that should be used to reach D. In this way, these labels are identifying a cross- connection between the incoming LSP and the egress LSP on AS2. To distinguish these cross-connecting labels from those associated with LSPs they will be referred to as XC-labels in the remainder of this memo. This XC label concept has powerful connotations. For example, when managing the flow of traffic in the network, it is desirable to be able to modify the traffic load on certain network links by re- routing it across other, perhaps more lightly loaded links. This is easily achieved through the use of the XC-label by changing its forwarding mapping. The modification of this mapping could be achieved through any of the MPLS provisioning techniques listed in Section 2.2.2 and could be instigated by an MBB. This ability to redirect traffic away from or around network hot- spots is a key component when delivering a high performance network for IP services. 2.2.4 Alternate XC label distribution mechanisms An alternative to the use of BGP-MPLS distributed labels to enable the XC function described above is through the use of tunnel-in- tunnel LSP creation. In this method, a new LSP is created that has a pre-configured mesh LSP as its route. This has causes the creation of a new label at the ingress interface of the target ER that is sent back to the originating ER. This label can then be configured at the Gibson Informational August 2001 9 draft-gibson-mpls-srcroute-00.txt Feb 2001 target LER as an index into the label table and be made to point at the correct next hop LSP. This method would require the relaxation of the MPLS peering relationship to allow its proper operation. A single LSR-LSR peer pair create the label, however this label would require distribution to all other ERs that want to access the XC. This functionality could be achieved through the Policy layer as a means of distributing this label. The MPLS MIBs, for example, already supports the pushing of a label at its mplsXCEntry (specifically the mplsXCLabelStackIndex)[LSR-MIB]. A suitable inter-MBB protocol could be used for this process. As a part of the provisioning process, LSP labels are learned at the management layer. These can then be disseminated at this higher layer to those other management layer functions that need to know them. In many ways this is a better solution than the relaxed peering approach as it is the management layer that will tend to control the mapping of XC labels onto LSPs. If a re-mapping is to occur for a provisioning function, the management layer can disseminate this information ahead of time such that when the re- mapping happens, those ERs that use this label are aware immediately of this change. This could be combined with standard LDP operating in Downstream Unsolicited mode. 2.2.5 Source Routing The implementation of the XC-Labels enables RToIP flows to be source routed across a suitable path spanning multiple ASs. An ER is able to build up route information by identifying the set of next hops that reach a given destination. At the ingress to each AS, the LSP that reaches a next hop is indicated by a single label. As every such label can be added in sequence to an MPLS label stack and appended to the front of a packet, the end-to-end path can be resolved hop-by-hop as the packet traverses the route. That is, the top-most label gives the first hop (and may be swapped as it traverse that hop). As soon as that LSP has been traversed, the next label in the stack, in this case an XC-label, is used to identify the next hop. A label stack can thus be defined at the network edge that comprises N labels, where N is the number of ASs traversed edge-to-edge. The top label is that of the first AS to be traversed. The 2nd to Nth labels of the stack consist of the XC-labels that identify the remainder of the packet's path across the network. Alternatively, a single label could be used that is re-mapped at each AS boundary. Gibson Informational August 2001 10 draft-gibson-mpls-srcroute-00.txt Feb 2001 An edge router can then be aware of a number of alternative routes to each of the other edge devices. Furthermore, this route information can be passed up to the MBBs that control these edge devices. This permits the management layer to be involved in the session establishment process to select an optimal path as a part of the admission control process. It also allows the management layer to track LSP utilization in the network and perform load balancing and other TE operations to avoid congestion. 2.2.6.1 Scalability The solution outlined in this memo has a number of desirable characteristics that enable it to scale. The source routing scheme described in this memo would typically operate over edge to edge routes that comprised no more than a collector-core-core-collector configuration of ASs. In this regard, source routes of no deeper than 3 XC-labels plus a local LSP label need be stored. Also, through using the MBB to define the routing policy at the ER, it is possible to restrict the number of active edge to edge routes that an ER stores in its loc_RIB. The full set of possible routes can, however be stored in the Adj_RIB_In. By adopting the Virtual Router methodology proposed in [RFC 2685], it is possible to separate out these constrained XC-label Routing Information Bases from those generally accessible to all normal users. 2.2.6.2 Alternative Source Route discovery mechanisms As an alternative to discovering the label defined source route using the BGP techniques described above, the following mechanisms could also be considered: o BGP could be extended such that the AS_PATH attribute contains an AS_SEQUENCE of (AS number, XC-label) pairs. This would be an extension to the existing protocol whereby the XC label became a routing element. Clearly any re-mapping of an XC label would necessitate a BGP update if it changed the destination of a LSP identified by that XC label. This is an artifact of tying the XC label into the routing protocol. o RSVP POLICY_ELEMENTS could be defined (see Appendix A) that can exchange route information between MBBs, using a COPS-RSVP interface from the ERs. This is an alternative piggyback method to the first MPLS-BGP method and makes use of the fact that most QoS requesting applications hand off the request for service to RSVP. Gibson Informational August 2001 11 draft-gibson-mpls-srcroute-00.txt Feb 2001 o The LDP Query mechanism defined in [QUERY] could be adopted and used in a CR-LDP implementation of MPLS. This would permit ERs to learn the set of labels that comprised an end-to-end link. This solution still requires an XC creation mechanism. One might use LDP operating in a Downstream Unsolicited mode to provide this functionality. 2.3 Admission Control Admission Control to the network is controlled by the MPLS Bandwidth Brokers (MBBs) that sit at the edge of the network. The MBB is responsible for controlling the mapping of RToIP flows onto edge to edge routes at each ER it controls. It therefore plays a critical role in satisfying the service level requested for the flow. Session admission will typically occur in two stages: authorization and session control. Guaranteed service network offerings are likely to come at a premium to end-users. In most cases this will be through a pre-agreed SLA with the service provider. In this case the MBB needs to perform a check on the user's credentials before performing any further message processing. If the session setup signaling is from an unauthorised user, then the session can be rejected. This may simply result in the MBB not forwarding any session information, or it might prompt the explicit signaling of a teardown message. In this memo it is assumed that most traffic that requires an explicit QoS level, will use RSVP to signal this requirement end to end. In this case, the MBB acts like a COPS-RSVP PDP [COPS-RSVP], and intercepts both Path and Resv messages. It therefore maintains a COPS-RSVP interface to the ERs it controls. The second stage of admission control also takes in the selection of a suitable path for the new RToIP flow. Assuming continued service guarantees are to be honoured, a new flow cannot be admitted where it will cause degradation below an acceptable level to an already active flow. The process of route selection is dealt with in the next section. If no suitable path can be found to support the RToIP flow's service requirements, this flow should not be admitted to the network. Admission Control may also encompass some form of billing and accounting, depending on the user's SLA. This area is outside of the scope of this memo but remains an area of high importance. Gibson Informational August 2001 12 draft-gibson-mpls-srcroute-00.txt Feb 2001 2.4 Route Selection At the edge of the network, the MBB has a view of the label stacks available to traffic that originates at the ER(s) it controls. As it has triggered the creation of the first-hop LSPs of each of those label stacks, it has explicit knowledge of their available service levels. What the MBB does not have an explicit view of, is the available service levels of the LSPs that comprise the remainder of the end to end path. The problem of picking a complete end to end path can be solved by restricting the route decision that an MBB has to make. An MBB has a clear picture of the available bandwidth on the LSPs that emanate from its local ERs. Using one of the techniques listed below, it is also relatively simple to infer information about the availability of LSPs referred to by XC labels. o Use the BGP QoS feedback mechanism described in [Jacquenet]. This describes a QOS_NLRI attribute that describes both available bandwidth and delay characteristics for a particular route. This would permit ASBR peers to exchange QoS information to aid route selection. o [FEED] Describes TLVs that contain information about the available bandwidth along an LSP that can be used to update the routing table of an LSR. This information can be retrieved, for example, by sending a Query message as per [QUERY]. This method could simply be extended to have the fed-back information pertain to the LSP that a XC-label identifies. o A third method would be to define/identify a protocol that could disseminate information between the MBBs in the management layer. This could be similar to the protocol identified to perform label stack dissemination. The work currently ongoing in the Service Level Specification (SLS) wg may lead to a suitable solution in this area. o Finally, the RSVP extensions proposed in Appendix A could be used to update path information. This could be included in either new session signaling or in refresh information. Whichever of these techniques is used, it is possible for the MBB to learn service availability information about Border routers that sit on the far side of the ASs that are connected to its home AS. In other words, it is possible to learn information about downstream routers. There is a potential scalability issue with such techniques, regarding the complexity of route information that has to be stored. In order to ease this, imagine a scenario where the routing decision Gibson Informational August 2001 13 draft-gibson-mpls-srcroute-00.txt Feb 2001 for the end to end path is divided in two at the ingress and egress point of the network. This would reduce the problem (in the 4 AS case) to picking two two-hop routes that intersect at the same ER. Such ERs will be referred to as Pivot Points. An illustration of where a Pivot Node sits in the network in relation to an MBB is shown in Figure 3. Figure 3 Role of Pivot Nodes +-----+ |MBB 1| +-----+ +-----+ |MBB 2| : +-----+ : /----\ /----\ /----\ /----\ : : / \ / \+-----+/ \ / \ : : | AS 1 |****| AS 2 |Pivot| AS 3 |****| AS 4 | : : | | | |Node | | | | : : * / \ /+-----+\ / \ * : : ** \----/ \----/ \----/ \----/ ** : +---*+ +*---+ |ER 1| |ER 2| +----+ +----+ When negotiating an end to end path with an MBB that is 4 LSP hops away, both MBBs are thus two hops away from a set of Pivot nodes that might provide connectivity. (This can be determined, for example, by determining the AS of the destination MBB and the consulting the AS_PATH information from BGP.) With reference to Figure 3, a suitable Pivot Node is illustrated at the border of both AS 2 and AS 3. It should be noted that there might be a number of such suitable Pivot Nodes, either at the intercept of other ASs that border AS1 and AS 4, or if there are multiple intercepts between AS 2 and AS 3. MBB 1 can thus determine the relevant Pivot Nodes through examination of AS_PATH information from BGP. 2.4.1 Destination Service Notification Techniques The use of such an architecture would require the knowledge at the egress point of the connection (e.g. ER 2) of those routes that terminate on it. Again, a number of options are open in this case. Simplest of all is to assume that the sessions that are carried over this network are symmetric in nature and that the LSP mesh is similarly symmetric. Thus route determination decisions can be made for the two half paths using the above listed feedback techniques and storing the extended route information at the ERs. Gibson Informational August 2001 14 draft-gibson-mpls-srcroute-00.txt Feb 2001 A second technique would be to invoke a feed-forward mechanism that notifies downstream routers of the current utilization of the routes towards them. This might easily be achieved through the use of appropriate management packets into the RToIP streams that collate route information. If the ER-LSPs are established using RSVP-TE, is it possible to use the Policy Element in Path refresh messages to include suitable remaining service level information. Alternatively, if the RSVP Aggregator/Deaggregator technique described in [RSVP-AGG] were adopted, aggregate Path refresh messages could again be used to update the service availability on each aggregate flow. Suitable POLICY_ELEMENTS are defined in Appendix A. This last method allows the MBB network visibility of the service utilization of the underlying network. This also therefore permits the MBBs to perform reconfiguration or SLA re-negotiation under congestion conditions, either autonomously or under instruction from the Policy management layer. 2.5 Application of VPN techniques A further enhancement to the MPLS approach, is the use of Virtual Network technology. This is especially relevant to deregulated networks where operators lease bandwidth from an established operator to run a set of services. This technology provides the means by which a single network can be divided into a number of separate networks over the same physical topology. It therefore provides the means of handling RToIP traffic separately from other network traffic. It also enables separation of different traffic types onto logically separate networks. This greatly aids the provision of service levels to a particular RToIP flow. A taxonomy of VPN schemes is performed in [RFC 2764], which presents, amongst others, two MPLS specific solutions. These are the BGP-based solution outlined in [RFC 2547] and a Virtual Router approach. Both technologies provide a means of dividing a router into separate logical entities at the network edge. This functionality is key if a separate high QoS network is to be run on the same physical equipment that normal (in terms of service level and requirements) Internet traffic is routed over. In order to separate the meshed LSP network into a service specific network, a VPN methodology is used. In one scenario the PE router functionality is split into a separate VR function(s) whose routing table is populated with information pertaining to the LSP mesh. Or, the BGP-based label distribution mechanism described in [RFC 2547] is used to provide a logically separate network. In either case, the Gibson Informational August 2001 15 draft-gibson-mpls-srcroute-00.txt Feb 2001 separate service networks are identified with a separate VPNID [RFC 2685] and the VPN Routing and Forwarding tables (VRF) are populated. 2.6 Inter-operator requirements For this scheme to work seamlessly across multiple operator networks, it is necessary for operators to share route availability information with other operators. Clearly this is sensitive information, that most operators would not be willing to freely share with their competitors. The XC-label scheme described in this memo appears to offer a workaround to this situation. Instead of the particulars of a route being advertised, an operator can announce the service availability of an abstract path to a particular destination. This might be as simple as a binary available/not available indication to an adjacent SP or some more complex mechanism might be used. The advantage being that the advertising SP can re-configure its network in response to rise in demand for a particular service to a particular destination seamlessly, providing it keeps the XC-label to destination mapping consistent. The ongoing work in SLS (Service Level Specification) might yield a suitable advertisement mechanism. 2.7 Protection Strategies The real-time services considered for this architecture will typically require very fast recovery, on the order of tens of milliseconds. In order to provide sufficiently fast restoration using any recovery mechanisms, very fast fault detection is required, i.e. through the use of the Fast Liveness Protocol (FLIP). For non-local repair, very rapid propagation of Failure Indication Signals (FIS) will also be necessary. 2.7.1 Protection across an AS The LSPs across an AS between AS Border Routers may be protected, using strategies consistent with the framework for MPLS-based recovery [MPLS-REC]. Some combination of local repair or global repair (end-to-end protection) may be appropriate. For operation that is transparent to per-session control, protection for these LSPs must provide equivalent recovery paths (no reduction in capacity or quality of service) and must use the same AS Border Routers. Gibson Informational August 2001 16 draft-gibson-mpls-srcroute-00.txt Feb 2001 2.7.2 Protection of sessions In some instances, LSPs across an AS may not be protected, or the level of assurance provided by the protection on these tunnels may be considered insufficient. In these cases, and also to protect against the failures of AS Border Routers, recovery mechanisms may be required for individual sessions. End-to-end protection may be implemented by selecting a second end- to-end path for a session and installing a backup mapping for the 6- tuple filter at the ingress router. End-to-end protection could be either 1+1 or 1:1. In the case of 1+1 protection, a mechanism to select one output stream at the egress router is required, which may require rapid downstream propagation of a fault indication signal (FIS) from the point of failure. In the case of 1:1 protection, rapid upstream propagation of a FIS from the point of failure to the ingress router is needed. Local repair may also be possible for some failures, by installing appropriate cross-connects and backup label-mappings to redirect traffic around a possible failure point. Note that the label stack must be correct at the path merge point. For protection paths to be effective, it must be possible to select routes that are link and node disjoint. In addition to ensuring that different AS Border routers and LSPs are selected by protection paths, it is desirable to ensure that two LSPs through an AS do not share common sources of failure. In some cases, this could be achieved through the configuration of the LSP mesh, ensuring that all LSPs in the VPRN in a given AS are fully fault-disjoint. Otherwise, it may be important to provide information about the LSPs such as the Shared Risk Link Group (SRLG) to the PDPs to use in path selection. 2.8 Applicability to RSVP aggregation One of the efforts of the Integrated Services over Specific Link Layers (ISSLL) working group is the area of RSVP aggregation [RSVP- AGG]. This draft specifies how the total amount of state stored for multiple RSVP initiated flows between two edge points of a core network can be reduced by aggregating their state together. Amongst other mechanisms involved is the determination of ingress router, the "Aggregator", and the egress router, the "Deaggregator", for these aggregate flows. Whilst determination of the former is relatively trivial - - a Policy decision on where to apply flow aggregation - - determination of the latter is more difficult. It is proposed that the solution in this memo provides a good fit to this RSVP aggregation model. Deaggregator selection is a matter of performing the source routing described in this memo. As [RSVP-AGG] Gibson Informational August 2001 17 draft-gibson-mpls-srcroute-00.txt Feb 2001 provides the mechanisms for determining what is an aggregate flow message, these solutions dovetail well. 3.0 Future work This draft is intended to set out a number of candidate solutions to the Service levels problems set out in RFC 2990. It raises the following work areas. o Scaling of full mesh LSP configurations across an AS. o Tunneling of service availability information in RSVP between Bandwidth Brokers Further work might also be carried out to see if the XC-Label functionality defined in this draft could extend to be used in IGPs such as OSPF or IS-IS. 4.0 Intellectual Property Considerations The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 5.0 Security Considerations This draft introduces a mechanism that controls entry into a segregated network for real-time media flows, associated with session service, that have been subjected to authentication. If the Service Providers are trusted third parties then in the absence of failure or misconfiguration, the real-time media flows cannot be subject to malicious eavesdropping, though they may still be subject to lawful interception. Further, if the MPLS network is capable of honouring its resource allocation to the configured LSPs then the core network is immune to denial of service attacks. These security properties may be compromised by the collector networks linking the Customer edge and Provider Edge routers. 6.0 References Gibson Informational August 2001 18 draft-gibson-mpls-srcroute-00.txt Feb 2001 [STANDARD] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [KEY-WORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [RFC 2990] G. Huston, "Next Steps for the IP QoS Architecture", RFC 2990, November 2000. [DIFF_MPLS] F. Le Faucher et al., "MPLS Support of Differentiated Services", draft-ietf-mpls-diff-ext-07.txt, work in progress, August 2000. [Chadha] R. Chadha et al, "Policy Framework MPLS Information Model for QoS and TE", draft-chadha-policy-mpls-te-01.txt, work in progress, December 2000. [LSR-MIB] C. Srinivasan, A. Viswanathan, T. Nadeau, "MPLS Label Switch Router Management Information Base Using SMIv2", draft- ietf-mpls-lsr-mib-07.txt, work in progress, January 2001. [LDP-MIB] J. Cucchiara, H. Sjostrand, J. Luciani, "Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP)", draft-ietf-mpls-ldp-mib-07.txt, work in progress, August 2000. [TE-MIB] C. Srinivasan, A. Viswanathan, T. Nadeau, "MPLS Traffic Engineering Management Information Base Using SMIv2", draft-ietf- mpls-te-mib-05.txt, work in progress, November 2000. [COPS-MPLS] F. Reichmeyer, S. Wright, M. Gibson, "COPS Usage for MPLS/Traffic Engineering", draft-franr-mpls-cops-00.txt, work in progress, July 2000. [RFC 3031] E. Rosen, A. Viswanathan & R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [BGP-MPLS] Y. Rekhter & E. Rosen, "Carrying Label Information in BGP- 4", draft-ietf-mpls-bgp4-mpls-05.txt, work in progress, January 2001. [QUERY] P. Ashwood-Smith, A. Paraschiv, "MPLS LDP Query Message Description", draft-ietf-mpls-lsp-query-01.txt, work in progress, November 2000. Gibson Informational August 2001 19 draft-gibson-mpls-srcroute-00.txt Feb 2001 [COPS-RSVP] S. Herzog et al., "COPS Usage for RSVP", RFC 2749, January 2000. [Jacquenet] C. Jacquenet, "Providing Quality of Service Indication by the BGP-4 Protocol: the QOS_NLRI attribute", draft-jacquenet-qos- nlri-01.txt, work in progress, November 2000. [FEED] P. Ashwood-Smith et al., "Improving Topology Data Base Accuracy with LSP Feedback", draft-ietf-mpls-te-feed-01.txt, work in progress, December 2000. [RFC 2764] B. Gleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis, "A Framework for IP Based Virtual Private Networks" RFC 2764, February 2000. [RFC 2547] E.Rosen, Y Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999. [RFC 2685] B. Fox, B. Gleeson, "Virtual Private Networks Identifier", RFC 2685, September 1999. [MPLS-REC] V. Sharma et al., "Framework for MPLS-based Recovery", draft-ietf-mpls-recovery-frmwrk-01.txt, work in progress, November 2000. [RSVP-AGG] F. Baker et al., "Aggregation of RSVP or IPv4 and IPv6 Reservations", draft-ietf-issll-rsvp-aggr-02.txt, work in progress, March 2000. 7.0 Acknowledgments Thanks to Mark Cullum for his words on protection strategies, Roy Mauger for the Security words and Dave Stacey for helpful review comments and draft reconfiguration. 8.0 Author's Addresses Mark Gibson Nortel Networks London Road, Harlow, Essex, UK Email: mrg@nortelnetworks.com Gibson Informational August 2001 20 draft-gibson-mpls-srcroute-00.txt Feb 2001 Appendix A This Appendix sets out some extensions to the RSVP protocol. Specifically it describes how the Path information encapsulation described in the main body of this memo can be performed, using the Policy Element in the Path and Resv messages. According to RFC 2750, it is possible to exchange Policy information between adjacent Policy aware RSVP routers using RSVP POLICY_DATA objects. That means two adjacent PEPs can exchange information regarding the Policy associated with the link between them. In this case, that Policy is translated into the route information used to select the edge-to-edge label stack. RSVP uses the POLICY_DATA element to transfer Policy data between PEPs (RSVP Policy enabled routers). This has the format shown in Figure A.1. This element is part of both Path and Resv messages and is used by adjacent RSVP nodes to exchange Policy information. It starts with a length field, followed by an identifier that it is a POLICY_DATA element. It contains two types of entries in an Option List and a Policy Element List. Fig A.1 POLICY_DATA element +------------+------------+------------+------------+ | Length |POLICY_DATA | 1 | +------------+------------+------------+------------+ | Data Offset |(0) reserved | +------------+------------+------------+------------+ | | // Option List // | | +---------------------------------------------------+ | | // Policy Element List // | | +---------------------------------------------------+ Following the Options List in the POLICY_DATA element is the Policy Element list. The format for this is the same used for the identity representation described in RFC 2752 and can be seen in Figure A.2. Gibson Informational August 2001 21 draft-gibson-mpls-srcroute-00.txt Feb 2001 Fig A.2 ROUTE_INFO POLICY_ELEMENT +------------+------------+------------+------------+ | Length | P-Type = ROUTE_INFO | +------------+------------+------------+------------+ | | // Policy Information = Route Entries // | | +---------------------------------------------------+ The ROUTE_INFO element is the container for the route information to be exchanged between the ERs. It starts with a length field, measured in bytes followed by a P-Type that is set to ROUTE_INFO. It contains a number of Route Entries whose format is shown in Figure A.3. Fig A.3 Route Entry format +------------+------------+------------+------------+ | Length | R-Type | Subtype | +------------+------------+------------+------------+ | Value | +------------+------------+------------+------------+ These Route Entries have a length field as first entry, followed by an R-Type that defines the type of routing entry it is and a subtype (currently undefined for all R-Types). The final part is the value itself. The following R-Types are supported: o IPV4_ADDR - IPv4 Address that uses the standard IPv4 address format in the Value field. This will be used to define the address of the pivot node through which a route will be selected. o BANDWIDTH - This defines the bandwidth in bits per second as a single 32-bit word. This gives up to 4.3 Gbps, however subtypes could be defined in the future if this proved limiting. Further subtypes could also be used to indicate that this was a peak/mean/burst bandwidth. o LABEL_STACK - This transports an n-label stack, when n = Length/4. These labels are transmitted as the entire 32-bit shim header. This is where the cross-connect labels would be described. This represents a initial list and other similar R-Types might be defined to extend this list. Gibson Informational August 2001 22 draft-gibson-mpls-srcroute-00.txt Feb 2001 Full Copyright Sta tement "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 implmentation 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 August 2001 23