Internet Draft Internet Engineering Task Force Olivier Duroyon Rudy Hoebeke Hans De Neve Internet Draft Alcatel Document: draft-duroyon-te-ip-optical-00.txt July 2000 Triggering and advertising lightpaths in an IP over optical network <draft-duroyon-te-ip-optical-00.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract The objective of this draft is to propose an IP service model where lightpaths are dynamically triggered by the IP layer and subsequently advertised for IP routing. The network model assumes that several IP service domains, some of which represent different administrative entities, share the same optical backbone and focuses therefore primarily on an overlay model. Therefore, this draft intends to complement the IP over optical framework with respect to the overlay model. 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 RFC2119. 3. Introduction Duroyon, Hoebeke, De Neve Expires: January 2001 Page 1 Internet Draft draft-duroyon-te-ip-optical-00.txt July 2000 This draft introduces an end-to-end IP service model enabling the dynamic management of optical lightpaths by means of MPLS signaling. For reasons of definiteness, the optical devices are always referred to as optical cross-connects (OXCs) and the IP devices as routers. The terminology used in the draft attempts to be in line with the definitions found in [ip-optical]. Service model issues raised in this draft apply mainly to an overlay/peer model although some of them equally pertain to an integrated model. An overlay model is appropriate for an untrusted environment where several IP service domains, representing different administrative entities, share the same optical backbone. Moreover it seems well suited for a network architecture including non-IP devices, e.g., legacy TDM or ATM equipment, that interface with the same optical backbone. This is however beyond the scope of this draft. The concept of an overlay/peer model has been introduced in [ip- optical] but allows for several diverse interpretations. Our understanding of the overlay model is based on the following characteristics, which are largely defined in other contributions (ODSI, OIF and IETF drafts): - Typical for an overlay model is that any addressing scheme may be used within the optical domain, even non-IP based. However, in this draft, public IP addressing is assumed for any addressable entity (OXC, control channels and lightpaths or bundle of lightpaths when lit up). - One (or more) IP interface(s) used as control channel(s), called Optical-User Network Interface(s) (O-UNIs), are defined for each router interfacing with an OXC. These devices are hereafter respectively referred to as boundary router and boundary OXC. - These control channels can be associated with one (or more) of the boundary router's physical ports, interconnecting with the boundary OXC (when sub-rate bandwidth connections are supported on a physical interface, this association could be at the level of sub-rate channels, e.g., SONET containers). These ports (or sub- rate channels) are hereafter generically referred to as IP-capable end-points. A lightpath is defined as the entity formed by two IP- capable end-points and their interconnecting path across the optical domain. - In the optical domain, the control channels are terminated on an OXC-Controller (OXC-C). An OXC-C is a device processing any kind of control channel messages and controls the lightpath setup in an Duroyon, Hoebeke, De Neve Expires: January 2001 Page 2 Internet Draft draft-duroyon-te-ip-optical-00.txt July 2000 OXC. An OXC-C can be integrated in a single OXC or remotely control one or more OXCs. - Routing protocol messages (such as IGP or EGP) are not exchanged across the O-UNI. - Boundary router reachability across the optical domain is achieved via a service discovery mechanism across the O-UNI in conjunction with either a directory service or an IGP across the optical domain, denoted as optical IGP (O-IGP). - A boundary router (or some other device connected to the boundary OXC) can issue a lightpath request through extended RSVP or CR-LDP across the O-UNI. Fundamental lightpath requests are the establishment of a new lightpath or the tear down of an existing lightpath, although other requests can be envisioned (e.g., requests to change some attribute of a lightpath). We refer to all these as lightpath requests. - In case of an untrusted O-UNI, any lightpath request coming from the boundary router has to be authenticated and validated by the optical domain. - A lit-up lightpath is advertised as an IP link in the IP service domains or is added to an existing IP link (forming a bundle). - IP destination reachability is subsequently achieved by exchanging IP routing messages across lightpaths. - Traffic Engineering-Label Switched Paths (TE-LSPs) for the purpose of IP traffic engineering may be created on top of lightpaths. Our service model further assumes that a decision point in the IP service domain, e.g., a Traffic Engineering (TE) tool, will trigger a boundary router to issue a lightpath request towards the optical domain. The decision point determines the need for a lightpath on the basis of IP Service Level Agreements (IP-SLAs) and related information, such as for instance load measurements in the IP service domain. In the remainder of the document, the terms TE tool or decision point are used interchangeably and refer to the IP service domain device, capable of triggering lightpath requests. 4. IP service model description This section outlines the sequence of events that characterize our proposed IP service model. Duroyon, Hoebeke, De Neve Expires: January 2001 Page 3 Internet Draft draft-duroyon-te-ip-optical-00.txt July 2000 (1) Provisioning Provisioning consists of installing and configuring interfaces between boundary OXC and boundary routers. At this stage, an association is configured between the control channels and one (or more) of the boundary router's IP-capable end-points. In case of our overlay model, the control channel is identified by a numbered IP address and forms an IP link with an OXC-C. This IP link is not announced into the IGP routing realm of the IP service domain but is only advertised into the optical domain. (2) Optical Service Level Agreements Next, the service model consists of negotiating Optical SLAs (O- SLA) at optical domain-IP service domain boundaries. In case of an untrusted peering relationship, each lightpath request is authenticated and validated against the O-SLA. (3) Service Discovery A service discovery mechanism across the O-UNI, as defined for example in ODSI, provides the necessary reachability information to the IP service domain for the authorized Closed User Groups (CUGs). In addition, specific optical characteristics of the IP-capable end-point are learned, such as, e.g., sub-channel size or O-UNI restoration capabilities. (4) Lightpath request The decision point of the IP service domain determines the required connectivity through the optical domain based on service requirements as per the IP SLAs. It then triggers the boundary routers to launch a lightpath request towards the associated boundary OXCs, using MPLS-based signaling. This process is dynamic and may involve, amongst others, the set-up of additional lightpaths, release of existing lightpaths or redirection of existing lightpaths. (5) Optical path selection In case an O-IGP is used inside the optical transport network, each boundary OXC learns the complete topology of the optical domain. A Constraint-based Shortest Path First (CSPF) algorithm can then be implemented in the boundary OXCs to calculate a route for the lightpath in line with the constraints specified in the request. As an example, the route of a lightpath may depend on the protection/restoration requirements or routing constraints specified in the lightpath request. The latter may indicate that the requested lightpath should be routed diversely from other Duroyon, Hoebeke, De Neve Expires: January 2001 Page 4 Internet Draft draft-duroyon-te-ip-optical-00.txt July 2000 lightpaths. This CSPF algorithm is expected to be quite different from an IP CSPF algorithm because of optical considerations. (6) Lightpath advertisement to the IP layer As soon as the lightpaths are lit up, they are advertised to the IP layer. The involved boundary routers will either create a new IP link and start to exchange routing information (using IGP or eBGP) or modify the characteristics of the existing IP link. (7) Traffic engineering for optimization of the optical domain Optionally, the optical domain may have its own off-line Optical Traffic Engineering (O-TE) tool. This tool may be used for optimization of resource utilization in the optical domain by rearranging some lightpaths. 5. Optical Service Level Agreements As mentioned before, lightpath requests issued by a boundary router are only accepted within the constraints of an O-SLA. An optical domain-IP service domain boundary coincides with an O-UNI with its associated O-SLA. Similarly, if there are multiple optical subnetworks in the optical domain, there will be O-SLAs negotiated at each optical subnetwork boundary. An optical subnetwork boundary then corresponds to an Optical Network to Network Interface (O- NNI). In this draft, we limit the discussion to O-SLAs at the level of O-UNIs. Additionally, we only discuss the technical aspects of an O-SLA. Borrowing from the terminology introduced in [diffserv-framework], we refer to the technical part of an O-SLA as an Optical Service Level Specification (O-SLS). An O-SLS is considered to be unidirectional and to specify performance expectations (i.e., the service level) for the IP service domain as well as imposed reachability constraints, e.g., CUG. O-SLS parameters could for example include: 1. Capacity constraints An ingress O-SLS may contain limits on the maximum number of lightpaths that can be established from a specific ingress point, possibly as a function of time of day, as well as bandwidth constraints (OC-48, OC-192, etc.). An egress O-SLS may put capacity constraints on the lightpaths that the receiving IP service domain is willing to terminate. 2. Service performance parameters Duroyon, Hoebeke, De Neve Expires: January 2001 Page 5 Internet Draft draft-duroyon-te-ip-optical-00.txt July 2000 Examples are lightpath latency, supported protection/restoration options, reliability, availability, supported routing constraints, accessibility (i.e., lightpath request blocking probability), responsiveness (specifying upper limits on the processing time of lightpath requests), etc. 3. Constraints on the 'scope' of lightpath request This may be viewed as an extension to the concept of CUGs, which by nature already exhibit reachability limitations. Scope constraints are intended to additionally restrict the topological extent of lightpaths. In its simplest form, the O-SLS offers to accept any lightpath request issued by the IP service domain over a specific O-UNI up to a maximum capacity without any scope constraint within the CUG (so-called hose O-SLS). Conversely, the agreement may be constrained by the egress point of a lightpath. For example, the optical domain service provider might agree to the setup of lightpaths, up to a certain maximum capacity, but only if these lightpaths are destined to a specific set of egress points within the CUG. Part of the purpose of O-SLSs is to protect resources in the optical domain by validation of submitted lightpath requests. If the optical domain and the IP service domain are under control of the same administrative authority, then there is likely to be a trusted peering relationship between both domains. Conversely, in case of an untrusted peering relationship, the optical domain service provider validates incoming lightpath requests as per the O-SLS. This validation process can be implemented in the OXC-C. In this case, there exist several mechanisms to install an O-SLS in an OXC-C, e.g., CLI, SNMP, LDAP or COPS. Alternatively, the O-SLS enforcement may be outsourced to another policy entity. An O-SLS offers to accept lightpath requests at the service level agreed with the IP service domain. The optical domain service provider will provision the optical domain accordingly. A broad range of optical services could be envisioned. As an example, services could be defined with different levels of accessibility, depending on the probability that a lightpath establishment request is blocked. Moreover, services could also be categorized as protected or non-protected, depending on the offered protection level. All of these service level characteristics influence the resource provisioning process in the optical backbone. For each lightpath request, the optical domain service provider may also need to identify the O-SLS for which the request is submitted. Some authentication may be included in the request in order to verify that the rightful IP service provider issued the request. In some cases, this customer might be implicitly derived from the Duroyon, Hoebeke, De Neve Expires: January 2001 Page 6 Internet Draft draft-duroyon-te-ip-optical-00.txt July 2000 control channel on which the lightpath request was received. The authentication mechanism must be specified in the O-SLS. Although it can be assumed that O-SLSs will be static for the foreseeable future, this draft does not preclude dynamic O-SLSs. These would necessitate some automated form of interaction between the IP service domain and the optical domain. In case of an O-SLS at the O-UNI, this may for instance require the interaction between a Bandwidth Broker (BB) in the IP service domain and a Lambda Broker (LB) in the optical domain. At the level of an O-NNI, this would be between different LBs, acting on behalf of the different optical subnetworks. This automated (re-)negotiation of O-SLSs would in turn call for an automated O-SLS admission control function. Note that this admission control function is different from the validation of lightpath requests as per the negotiated O- SLS, referred to as O-SLS enforcement. 6. Lightpath triggers As stated in [ip-optical], the lightpath request triggering process should be part of a stable traffic engineering tool in the IP service domain as opposed to a data-driven shortcut approach, similar to the schemes proposed for IP over ATM networks. Henceforth, an integrated TE-LSP and lightpath triggering process is proposed at the end of this section to alleviate the shortcomings of the former method and is elaborated below. 6.1 Data-driven shortcut approach for lightpaths The data-driven shortcut model would imply that the boundary routers use traffic measurements to autonomously control the number of lightpaths that connect them with a set of remote boundary routers across the optical domain. For example, boundary router A could detect that some of its traffic is reaching boundary router B in a multi-hop way. If this traffic trunk is large enough, boundary router A might decide to set-up a lightpath to boundary router B, relieving the IP forwarding at all intermediate routers on the multi-hop path. In an overlay model, once a lightpath has been established to a new destination, it should be announced as a (new) IP link in the IP service domain routing database. As such, it can be used by any TE entity in the IP service domain and this IP link may carry several TE-LSPs. This means that the TE entity in the IP service domain would then be constantly reacting to decisions of the boundary routers that are continuously changing the IP topology. Such a layered scheme of lightpath requests and TE-LSP requests is inefficient and could also break the TE service model, when the only available lightpath between two boundary routers would be torn down. Such a decision might be based on the valid observation that Duroyon, Hoebeke, De Neve Expires: January 2001 Page 7 Internet Draft draft-duroyon-te-ip-optical-00.txt July 2000 the traffic pattern has changed such that the existing lightpath is under-utilized and may be re-directed towards another boundary router. However, the lightpath might still carry TE-LSPs. Turning off the lightpath has the effect of a link failure and will hence trigger the TE entity in the IP service domain to recover from this failure. Depending on whether the TE-LSP was protected or not, one of the following scenarios will take place. 6.1.1 Protected TE-LSPs TE-LSPs can be used to carry mission critical traffic requiring a fast recovery scheme in case of link failures. Upon such an event, the traffic of the working TE-LSP can be switched to a protect TE- LSP that has been pre-configured along a node- and link-disjoint path. - Protected lightpath: if the turned-off lightpath was protected within the optical domain, the TE-LSP path calculation might have selected this IP link for both the working and the protect path of the TE-LSP. In that case, the TE-LSP protect path will not be available and connectivity will be lost. - Unprotected lightpath: in this case the problem would not arise since the route diversity TE-LSP protect scheme would have selected another IP link for the protect path. 6.1.2 Unprotected TE-LSPs If the TE-LSP was not protected, the source nodes of the TE-LSPs running over the turned-off lightpath will start a CSPF calculation to find an alternative path. As all source nodes will be competing for the same resources, some LSP requests will be blocked and it might take a while before all LSPs have been restored. The above scenario equally pertains to the case of any link failure in an IP service domain. However, link failures in an IP service domain may be considered as rare events. This is however not the case when this link failure behavior is the result of a data-driven shortcut approach across an optical backbone. 6.2 Integrated TE-LSP and lightpath triggering process Given the above shortcoming, boundary routers should not autonomously decide to tear down a lightpath. Yet, it may not always be appropriate to maintain an under-utilized lightpath. However, a lightpath should not be turned off until the TE-LSPs it carries have been re-routed along an alternative path. This might even require that a new lightpath is set up between two other boundary routers. All of this calls for a co-ordinated TE-LSP and lightpath triggering process, integrated in the same decision Duroyon, Hoebeke, De Neve Expires: January 2001 Page 8 Internet Draft draft-duroyon-te-ip-optical-00.txt July 2000 point. This is possible since both responsibilities reside within the IP service domain. The ability to dynamically establish lightpaths adds an extra dimension to the TE capabilities of an IP service domain. In addition to forwarding packets along non-shortest paths, it is now also possible to (re-)configure the topology of the IP service domain by means of adding, deleting or changing lightpaths across the optical backbone. This integrated decision point will use the set of IP SLAs and the derived traffic trunk requirements across the IP service domain (possibly complemented with traffic measurements) to determine the optimal set of lightpaths and TE-LSPs. Optionally, the explicit path calculation for the TE-LSPs could still be left to the routers running a CSPF algorithm within the topology, as determined by the decision point. 7. Lightpath advertisement to the IP layer The decision point may thus trigger the set-up of an additional lightpath to an already connected boundary router. Alternatively, it may trigger a rearrangement of existing lightpaths, or the establishment of a lightpath to a boundary router that could previously not be reached through the optical domain. It might very well be that the decision point triggers a boundary router to drop a lightpath if its capacity is no longer needed to meet the requirements of the IP SLAs. In order to make efficient use of the dynamicity of lightpath requests, the routing protocol parameters should be dynamically configurable as well. This section outlines a proposal to achieve a seamless integration of a new lightpath within the IP service domain for the overlay model by means of automatic configuration. As soon as a lightpath to a particular boundary router has been lit up, it is assumed that it is promoted to an operational IP link. In case of, e.g., regular SONET framing, this is achieved by running PPP on the newly established lightpath. 7.1. Lightpath set-up to a previously unreachable boundary router The draft [kompella] defines the different facets of the creation of an IP link in case of an integrated model and proposes to use the newly established IP link as a forwarding adjacency in the IP service domain. The overlay model imposes different requirements on the IP layer of the boundary routers. Indeed, once the first lightpath is established between two boundary routers and promoted as IP link, Duroyon, Hoebeke, De Neve Expires: January 2001 Page 9 Internet Draft draft-duroyon-te-ip-optical-00.txt July 2000 it is to be advertised as a point-to-point link for IP routing in order to initiate the IP connectivity between the two boundary routers. And subsequently it will allow IP reachability between the associated IP service domains. Two cases must be considered. The lightpath is promoted to an IP link connecting: - two boundary routers of the same Autonomous System (IGP peering), or, - two boundary routers of different Autonomous Systems (eBGP peering). The IGP and BGP peering cases do not require the same kind of configuration and are described separately. Note that in case of an IGP peer, it is necessary that the lightpath be bi-directional, because IGP protocols require a bi- directional transport layer. However, this is for further study [saha-rsvp]. From an addressing point of view, the IP-capable end-points can be unnumbered (and, e.g., identified by the Router Id of the boundary router), or numbered through provisioning, but different from the control channel IP address. It has to be noticed again that the control channel identification is neither known nor advertised throughout the IP service domain. 7.1.1. IGP support Once the first IP link is established between two boundary routers and configured to support an IGP peer, the boundary routers need to get the proper information: - The first requirement is to select IS-IS or OSPF for the newly formed IP link. - In addition, link routing parameters such as timers and area numbers might have to be specified. For instance, timers in OSPF should be consistent at both ends of the IP link. - Also, link metrics (e.g., resource classes, etc.) need to be inherited or configured for use by IP routing. - Finally, the IGP protocol is enabled and the IP link is advertised. Duroyon, Hoebeke, De Neve Expires: January 2001 Page 10 Internet Draft draft-duroyon-te-ip-optical-00.txt July 2000 These parameters have to be accessible and are automatically configured (prior to or at the time of lightpath establishment) by the decision point of the IP service domain to efficiently deploy the IP service on top of the lightpath. However, some of the routing parameters (e.g., OSPF timers) may be defaulted to pre-determined values. Those values must be defined network-wide and be consistent between all possible boundary router pairs. The decision point should be allowed to overwrite those parameters at the setup time of the lightpath. 7.1.2. eBGP peering In the case of an inter-AS lightpath, static route configuration specifying the BGP peer (most probably a virtual interface of the remote boundary router) should be configured in the local boundary router in order to set up the TCP session used in BGP. In addition, an IP SLA is going to be negotiated between the autonomous systems and routing policies are going to be configured on both ends of the lightpaths. As opposed to the IGP peering case, triggering of inter-AS lightpaths will very likely not arise from an automated process because of the BGP peering negotiation procedure. 7.2. Set-up of an additional lightpath In addition to the option described in 7.1 (creation of a new stand-alone IP link with the new lightpath and advertisement to the routing protocol), a second option is now possible, which is to add a supplementary lightpath to an existing IP link that forms a bundled link [kompella-bundle]. In this case there is no new configuration necessary for the IGP or BGP routing layer but only interactions internal to the boundary routers. This bundle is advertised as a single IP link. The lightpath in itself may be unidirectional, and hence the bundle could have an asymmetric bandwidth. - The boundary router upgrades the bandwidth of the bundle link based on the characteristics of this new lightpath. - The new lightpath is included in the load balancing mechanism that distributes the traffic amongst the component lightpaths of the bundled link, e.g., proportional to their bandwidth. - The addition of a new lightpath to a bundle does not impact the routing topology. Only the new bandwidth of the IP link is Duroyon, Hoebeke, De Neve Expires: January 2001 Page 11 Internet Draft draft-duroyon-te-ip-optical-00.txt July 2000 advertised within the IP service domain. The other characteristics of the IP link, e.g., the resource classes, remain unchanged. In the case described in this section, the only mandatory information to be automatically configured by the decision point is the bundle identifier to which the lightpath is to be added. 7.3. Rearrangement of an existing lightpath This case is the straightforward combination of lightpath tear-down followed by a new lightpath set-up. 8. References [diffserv-framework] Y.Bernet et al, "A Framework for Differentiated Services", draft-ietf-diffserv-framework-03.txt, Internet Draft, Work in Progress, February 1999. [ip-optical] James Luciani et al., " IP over Optical Networks _ A Framework", draft-ip-optical-framework-00.txt, Internet draft, Work in Progress, February 2000. [kompella] K. Kompella et al., "Extensions to IS-IS/OSPF and RSVP in support of MPL(ambda)S", draft-kompella-mpls-optical- 00.txt,Internet Draft, Work in Progress, February 2000. [kompella-bundle] K. Kompella et al., "Link bundling in MPLS traffic engineering", draft-kompella-mpls-bundle-01.txt, Internet Draft, Work in Progress, June 2000. [saha-rsvp] D. Saha et al., "RSVP extensions for Signaling Optical Paths", draft-saha-rsvp-optical-signaling-00.txt, Internet Draft, Work in Progress, March 2000. 9. Acknowledgments The authors would like to thank Emmanuel Desmet, Sitaram Kalipatnapu and Gert Grammel for their constructive comments. 10. Author's Addresses Olivier Duroyon Alcatel USA 45195 Business Court Dulles Phone: (703) 654 8605 Email: olivier.d.duroyon@usa.alcatel.com Rudy Hoebeke Alcatel Bell Duroyon, Hoebeke, De Neve Expires: January 2001 Page 12 Internet Draft draft-duroyon-te-ip-optical-00.txt July 2000 Francis Wellesplein 1 2018 Antwerp, Belgium Phone: (32) 3/240.84.39 Email: rudy.hoebeke@alcatel.be Hans De Neve Alcatel Bell Francis Wellesplein 1 2018 Antwerp, Belgium Phone: (32) 3/240.76.94 Email: hans.de_neve@alcatel.be Duroyon, Hoebeke, De Neve Expires: January 2001 Page 13