Internet Engineering Task Force Olivier Duroyon Rudy Hoebeke Hans De Neve Dimitri Papadimitriou Internet Draft Alcatel Document: draft-duroyon-te-ip-optical-01.txt November 2000 Expiration Date: May 2001 G.LSP Service Model framework in an Optical G-MPLS network 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 for a non-packet switch capable optical network where G.LSPs are dynamically triggered by the IP layer and subsequently advertised for IP routing. The business 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. G-MPLS signaling (refer to [g-mpls]) with UNI support is assumed as underlying control plane protocol. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Duroyon et al. Expires May 2001 1 draft-duroyon-te-ip-optical-01.txt November 2000 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. 3. Introduction This draft introduces an end-to-end IP service model enabling the dynamic management of Generalized Label Switched Paths (G.LSP) by means of G-MPLS signaling with User-to-Network Interface (UNI) support. A G.LSP is a point-to-point connectivity with specified attributes (some of which are mandatory, while others are optional) established between two termination points in the optical network. A G.LSP could be a fiber switched path, a lambda switched path, a TDM switched path (circuit) or a packet-switch capable G.LSP. The scope of this draft is restricted to optical networks, which are by definition non-packet switch capable. Consequently, G.LSPs are restricted to non-packet switch capable G.LSPs, which we hereafter refer to as G.LSPs. For reasons of definiteness, the optical devices are always referred to as Optical Network Elements (ONE) and the IP devices as Client Network Elements (CNE). Boundary CNEs and boundary ONEs are interconnected through an UNI signaling and routing interface. The owner of the UNI interface in the optical domain (UNI-Network or UNI-N) is referred to as in the Boundary ONE Controller (ONE-C). Its counterpart in the Client Network (UNI-Client or UNI-C) is referred to the Boundary CNE Controller (CNE-C). The terminology used in the draft attempts to be in line with the definitions found in [ip-optical], [ouni-framework] and [OIF2000.125.2]. An overlay use of G-MPLS (UNI support) is appropriate for an untrusted environment where several IP service domains, representing different administrative entities, share the same optical backbone. Moreover, this model 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. To distinguish between trusted and untrusted peers, a separate definition for a Trusted and Untrusted network interfaces is proposed: - An Untrusted interface is defined when UNI (respectively NNI) interfaces belongs to distinct administrative authorities. For instance an UNI interface between a client network element and an optical network element belonging to distinct ISPs defines an untrusted relationship between the client and the optical network element. - A Trusted interface is defined when UNI (respectively NNI) interfaces belongs to the same administrative authority. For instance an NNI interface between two ONEs belonging to the same Duroyon et al. Expires May 2001 2 draft-duroyon-te-ip-optical-01.txt November 2000 optical carrier defines a trusted relationship between these optical networks elements. The service model further assumes that a decision point in the IP service domain, e.g., a Traffic Engineering tool (TE tool), will trigger a boundary CNE to issue a G.LSP request towards the optical domain. The decision point determines the need for a G.LSP on the basis of IP Service Level Agreements (IP SLAs) and related information, such as for instance load measurements in the IP service domain. The same TE-tool may also decide about the configuration of Traffic Engineering LSPs (TE-LSP), which are by definition Packet-switch capable LSPs. For the purpose of IP traffic engineering, TE-LSPs are in this case created on top of non-Packet-switch capable G.LSPs. 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 G.LSP requests. 4. IP service model description This section outlines the sequence of events that characterize our proposed IP service model. (1) Configuration Configuration consists of installing and configuring interfaces of the boundary ONEs and boundary CNEs. During this stage of end-points configuration, physical attributes of the end-point (as protection attributes of the drop side) are also configured. Configuration of the NNI interfaces of the ONEs is out of the scope of this draft. (2) Neighbor Discovery, Endpoint Registration and Service Discovery The objective of Neighbor Discovery is to provide the information needed to identify the neighbor identity and neighbor connectivity over each link interconnecting a boundary CNE to a boundary ONE. Endpoint registration is concerned with registering boundary CNE endpoints to the optical network. The registration information includes the resource capabilities, closed user group (CUG) identification, port reachability information, UNI protection capabilities etc. This set of information is critical to enable dynamic G.LSP services at the UNI. The endpoint registration mechanism enables the end system to register its critical set of information so that other end systems can identify its existence and network properties. Duroyon et al. Expires May 2001 3 draft-duroyon-te-ip-optical-01.txt November 2000 Service discovery is concerned with obtaining the essential information about services from the attached optical network that are available for the CNE. This information is used by CNEs to establish the service environment. The service discovery mechanism allows the network element to convey information about available services to the end system. After finishing neighbor discovery, endpoint registration and service discovery, each end system should establish the service environment and have sufficient information to generate G.LSP service request. These mechanisms complement each other and they do not depend on the establishment and use of signaling channels between the two parties. (3) Optical Service Level Agreements Next, the service model consists of negotiating Optical SLAs (O- SLA) at optical network-client network boundaries, or between optical networks. In case of an untrusted peering relationship (i.e. untrusted UNI, respectively NNI), each G.LSP request is authenticated and validated against the O-SLA. The validation process against an O- SLA includes checking whether the request is conforming to the restrictions (e.g., on scope) defined in the O-SLA. O-SLAs may also be defined at trusted interfaces as the optical domain to provision resources that could use them. Trusted in this context refers to the fact that you don't expect the CNE to violate this O-SLA, and as such requests received from trusted neighbors don't need to be validated against the O-SLA. (4) G.LSP service request The decision point of the client network determines the required connectivity through the optical domain based on service requirements as per the IP SLAs. It then triggers the boundary CNEs to send a G.LSP service request towards the associated boundary ONEs, using G-MPLS signaling with UNI support. This process is dynamic and may involve, amongst others, the creation of additional G.LSPs, the deletion of existing G.LSPs or the modification of existing G.LSPs. (5) Address resolution At the UNI, the G.LSP service request sent by the CNE needs to include the ONE source and destination termination-point identifiers (in case of trusted UNI interface) or the CNE source and destination termination-point identifiers (in case of untrusted UNI interface). CNE termination-points should also be considered when the G.LSP is established through several optical networks belonging to different administrative authorities. Duroyon et al. Expires May 2001 4 draft-duroyon-te-ip-optical-01.txt November 2000 Consequently, the source client needs to send an address resolution request to obtain the ONE destination termination-point ID or CNE termination-point ID corresponding to the CNE destination logical- address of the G.LSP service request. (6) Optical path selection In case a dedicated instance of an IGP is used inside the optical transport network, each boundary ONE learns the complete topology of the optical domain. A Constraint-based Shortest Path First (CSPF) algorithm can then be implemented in the boundary ONEs to calculate a route for the G.LSP in line with the constraints specified in the request. As an example, the route of a G.LSP may depend on the protection requirements or routing constraints specified in the G.LSP request. The latter may indicate that the requested G.LSP should be routed diversely from other G.LSPs. This CSPF algorithm is expected to be quite different from an IP CSPF algorithm because of optical networking specific considerations. (7) G.LSP advertisement to the IP layer As soon as the G.LSPs are lit up, they are advertised to the client network. The involved boundary CNEs 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. (8) 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 network by rearranging some G.LSPs. 5. UNI discovery and registration services In order to provide a flexible and end-to-end IP Service model, with a minimum set of local provisioning, specific mechanisms and procedures have to be defined at the boundary between the client and the optical network: - to discover neighbors identity and connectivity - to register client end-point identity - and to discover the supported UNI and network services. Transport mechanisms used for the UNI discovery and registration services are referenced in [OIF2000.125.2] and [OIF2000.200]. 5.1 Neighbor discovery at the UNI The key objective of Neighbor Discovery at the UNI is to provide the information needed to identify the neighbor identity (IP address associated to the corresponding UNI) and neighbor Duroyon et al. Expires May 2001 5 draft-duroyon-te-ip-optical-01.txt November 2000 connectivity over each link connecting the boundary CNE to the boundary ONE. Neighbor discovery process which is also referred to as the Termination-port identity process, provides the following information to the boundary CNE and ONE: - the ONE discovers the identity of the client CNE by automatically discovering the IPv4 address assigned to the UNI-C and the identity of each physical port connected to the CNE - the CNE discovers the identity of to the connected ONE by automatically discovering the IPv4 address assigned to the UNI-N and the identity of each physical port connected to the ONE If the signaling transport mechanism is not explicitly configured, the neighbor discovery process ends by the bootstrapping of the signaling control-channel used to exchange the information during the end-point registration and the service discovery processes. 5.2 End-point Registration and UNI Service Discovery The end-point registration process includes the exchange of information between the CNE and ONE for each of the ports and logical ports connecting the CNE to the ONE. A logical port defines the structure of a physical port by identifying for a given port each of the channels included within this port and sub-channels included within this channel. The UNI Service discovery process includes the exchange of resource-related information of the Framing and Bandwidth capacity of each of the ports and logical ports connecting the CNE to the ONE. Additional parameters, such as the UNI drop-side protection attributes (UNI client-side protection and UNI network-side protection) and the G.LSP Directionality support could also be exchanged during the resource discovery process. For SDH/Sonet interfaces, the Transparency levels (STE-C, LTE-C), the client support of Virtual Concatenation (VC) and the levels of Continuous Concatenation (CC). The end-point registration process includes also the address registration process [OIF2000.261.1]. The address registration process allows the CNE to register the CNE logical addresses attached to the CNE Termination-point ID to which corresponds an unique ONE Termination-point IDs. A CNE Termination-point ID includes the unique IP address associated with the client element and the logical-port ID. The logical-port ID comprises the port-ID, Channel-ID and Sub-channel-ID as defined in [OIF2000.125.2]. When the address registration is part of the end-point registration process, the CNE associates the CNE Termination-point ID with the corresponding logical address and ONE termination-point ID. When the CNE does not associate logical addresses with their interfaces, Duroyon et al. Expires May 2001 6 draft-duroyon-te-ip-optical-01.txt November 2000 the CNE termination-point ID resolution implies that the boundary ONE knows the mappings between the CNE termination-point ID and the ONE termination-point ID. This case is considered as a particular case where the CNE logical address fields are empty. In this case, the value of the logical address could correspond to the user-group identifier to which the G.LSP belongs; however, in this particular case, the address resolution is always based on the CNE termination-point ID. Other client identifiers could be exchanged during end-point registration process: - the CNE registers the Contract ID attached to a specific element and/or interface - the CNE registers the Closed User-Group (CUG) IDs (i.e. User- Group ID) attached to a specific client end-point or port 5.3 Network Service Discovery The network service Discovery consists of the G.LSP service-related discovery process and a policy related service discovery process. During the G.LSP-related service discovery process, the CNE registers and/or discovers the parameters related to - SDH/Sonet related services, i.e., the SDH/Sonet Transparency levels supported and the Continuous Concatenation levels supported - G.LSP Directionality support - Network-side Protection, i.e., the Protection-levels services provided by the internal optical network (Unprotected, Dedicated 1+1 Protection, Dedicated 1:1 and Shared Protection) - G.LSP Priority classes and Preemption levels supported by the optical network - G.LSP Diversity options supported by the optical network - Security levels support (IPSec or other authentication mechanism) within the signaling used on the control-plane throughout the optical network The discovery of the Policy-related service may include the following parameters: - Service-levels offered by optical network - Scheduling-related service supported by the optical transport network and/or the scheduling desired by the client - Billing-related service supported by the optical transport network and/or the billing method desired by the client - Vendor-related and Optional parameters 6. Address resolution As stated in section 4.5, the source client needs to send an address resolution request to obtain the ONE destination termination-point ID (trusted UNI interface) or CNE termination- Duroyon et al. Expires May 2001 7 draft-duroyon-te-ip-optical-01.txt November 2000 point ID (untrusted UNI interface) corresponding to the destination CNE logical-address. Consequently, at a trusted UNI interface, the G.LSP create message sent by the CNE to the ONE includes the source and destination ONE (or CNE) termination-point IDs requested for this G.LSP. This implies that the source ONE must perform a internal address-lookup toward a directory service or a local mapping table, in order to find the mapping between the destination CNE termination-point ID and the destination ONE termination-point ID. So, the optical network client only needs to know the CNE source and destination logical address and termination-point ID in order to request a G.LSP creation; any other topological information concerning the optical network termination-point identification is transparent for the client. This mechanism is also adapted for inter-domain G.LSP (cf. Section 9.1) since in this case only the autonomous-system (AS) boundary ONE termination-point to CNE termination-point mapping-list has to announced to the neighboring BGP AS's. 7. Optical Service Level Agreements An optical domain-IP service domain boundary coincides with a UNI with its associated O-SLA. Similarly, if there are multiple optical sub-networks in the optical domain, there will be O-SLAs negotiated at each optical sub-network boundary. An optical sub-network boundary then corresponds to an optical Network-to-Network Interface (NNI). In this draft, we limit the discussion to O-SLAs at the level of UNIs. As mentioned before, G.LSP requests issued by a boundary CNE are only accepted within the constraints of an O-SLA. This means that in case of an untrusted peering relationship, each G.LSP request is authenticated and validated against the O-SLA. It was already indicated that O-SLAs may also be defined at trusted interfaces. However, G.LSP requests received from trusted neighbors don't need to be validated against the O-SLA. In the scope of this draft, 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 Duroyon et al. Expires May 2001 8 draft-duroyon-te-ip-optical-01.txt November 2000 An ingress O-SLS may contain limits on the maximum number of G.LSPs 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 G.LSPs that the receiving IP service domain is willing to terminate. 2. Service performance parameters Examples are G.LSP setup and/or recovery admitted latency, supported protection/restoration options, availability, supported routing constraints, accessibility (i.e., G.LSP request blocking probability), responsiveness (specifying upper limits on the processing time of G.LSP requests), etc. 3. Constraints on the 'scope' of G.LSP 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 G.LSPs. In its simplest form, the O-SLS offers to accept any G.LSP 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 G.LSP. For example, the optical domain service provider might agree to the setup of G.LSPs, up to a certain maximum capacity, but only if these G.LSPs 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 G.LSP 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 G.LSP requests as per the O-SLS. This validation process can be implemented in the ONE-C. In this case, there exist several mechanisms to install an O-SLS in an ONE-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 G.LSP 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 G.LSP 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. Duroyon et al. Expires May 2001 9 draft-duroyon-te-ip-optical-01.txt November 2000 For each G.LSP 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 signaling channel on which the G.LSP 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 sub-networks. 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 G.LSP requests as per the negotiated O-SLS, referred to as O-SLS enforcement. 8. G.LSP triggers As stated in [ip-optical], the G.LSP 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 G.LSP triggering process is proposed at the end of this section to alleviate the shortcomings of the former method and is elaborated below. 8.1 Data-driven shortcut approach for G.LSPs The data-driven shortcut model would imply that the boundary CNEs use traffic measurements to autonomously control the number of G.LSPs that connect them with a set of remote boundary CNEs across the optical domain. For example, boundary CNE A could detect that some of its traffic is reaching boundary CNE B in a multi-hop way. If this traffic trunk is large enough, boundary CNE A might decide to set-up a G.LSP to boundary CNE B, relieving the IP forwarding at all intermediate CNEs on the multi-hop path. In an overlay model, once a G.LSP 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 implies that the TE entity in the IP service domain would then be constantly reacting to decisions of the boundary CNEs that are continuously changing the IP topology. Such a layered scheme of G.LSP requests and TE-LSP requests is inefficient and could also break the TE service model, when the Duroyon et al. Expires May 2001 10 draft-duroyon-te-ip-optical-01.txt November 2000 only available G.LSP between two boundary CNEs would be torn down. Such a decision might be based on the valid observation that the traffic pattern has changed such that the existing G.LSP is under- utilized and may be re-directed towards another boundary CNE. However, the G.LSP might still carry TE-LSPs. Turning off the G.LSP 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. 8.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. Depending on whether G.LSP is protected or not throughout the optical network, the following alternative is considered: - Protected G.LSP: if the turned-off G.LSP 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 G.LSP: 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. 8.1.2 Unprotected TE-LSPs If the TE-LSP was not protected, the source nodes of the TE-LSPs running over the turned-off G.LSP will start a CSPF calculation to find an alternative path. As all source nodes will be competing for the same resources, some G.LSP requests will be blocked and it might take a while before all G.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. 8.2 Integrated TE-LSP and G.LSP triggering process Given the above shortcoming, boundary CNEs should not autonomously decide to tear down a G.LSP. Yet, it may not always be appropriate to maintain an under-utilized G.LSP. However, a G.LSP should not be turned off until the TE-LSPs it carries, have been re-routed along an alternative path. This might even require an additional G.LSP setup between two other boundary CNEs. All of this calls for a coordinated TE-LSP and G.LSP triggering process, integrated in the Duroyon et al. Expires May 2001 11 draft-duroyon-te-ip-optical-01.txt November 2000 same decision point. This is possible since both responsibilities reside within the IP service domain. The ability to dynamically establish G.LSPs 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 modifying G.LSPs 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 G.LSPs and TE-LSPs. Several setup optimization strategies are possible depending on the business model in use between the IP Service domain and the optical domain, and also the assumptions taken on the pre-existing optical topology. The TE decision point has the complete knowledge of the IP Topology, all optical end-points, including their logical, and physical attributes (granularity, protection attributes, _). The different strategies may be chosen among the following: 1- Minimize the number of G.LSPs to be lit up This strategy fits in business models where the optical domain doesn't belong to the service domain, and as such each additional network G.LSP is an additional cost to the service domain. The TE decision point optimizes the number of G.LSPs to set up through the optical domain for a given IP traffic pattern. 2- Add capacity without rearranging optical topology Before triggering new G.LSPs, the TE decision point tries to rearrange TE-LSPs without rearranging the underlying optical topology. 3- Add capacity with specific explicit constraints Some environment may lead to some specific constraints to be taken into account during route computation. One simple example is a mixed ATM / IP network. In this example TE-LSP used by ATM and their underlying G.LSP must not be rearranged during the computation to add optical capacity. The TE decision point optimizes the number of G.LSP (and subsequently TE-LSP topology) with the possibility of pinning down some components (TE-LSP, G.LSP, _) Duroyon et al. Expires May 2001 12 draft-duroyon-te-ip-optical-01.txt November 2000 4- Optimize IP topology without any optical constraint TE decision point optimizes the IP topology without taking any constraint on number of G.LSPs setup. The only constraints taken are in this case coming from the end-points attributes. In addition to the computation algorithm strategy, the TE decision point also takes into account the sort of IP services to be achieved, in order to achieve a consistent restoration between protocol layers. One simple way is to define a linear hierarchy between IP services. 1.- Layer 1 protection - Non-PSC Level Protection This service only applies for IP link built between two PSC- capable end-points. The G.LSP connecting both end-points is totally protected. It means that it will be chosen from a pool of G.LSPs with source and destination drop-side protection (1+1, 1:1, Shared Protection). And in addition the G.LSP will request a network-protected path via the optical network. This service will be mainly seen in a traditional environment where the service domain lies on a very reliable transport layer, dedicated to any fast restoration mechanism. 2.- Diverse Layer 2 _ PSC Level Protection This service also only applies for a G.LSP built between two PSC-capable end-points (for instance, an IP link connection). Two G.LSPs are requested to the optical cloud via the same CNE-to-ONE interface, using source and destination drop-side protected G.LSPs. No optical or SDH/Sonet network protection are required for the G.LSPs. But diverse optical paths are requested for both G.LSPs. This service makes sense in a network architecture where the CNE is locally connected to an ONE, and so the diverse path routing must start at the first ONE of the optical network. 3. Diverse Layer 2 - Network Level Protection This service applies indifferently in a mixed PSC-capable (and particularly for IP services) and non-PSC capable optical environment, and not necessarily at the boundary CNE. Two G.LSPs are requested from the IP service domain using two diverse paths. In this case when the G.LSP request reaches the optical cloud boundary, there is no specific protection requirements towards the optical cloud. Duroyon et al. Expires May 2001 13 draft-duroyon-te-ip-optical-01.txt November 2000 4. No G.LSP protection This service applies when the restoration mechanisms don't rely on pre-existing backup paths. In this case on protection constraints have to be taken into account at the optical layer. As described in this paragraph, in order to create a consistent end-to-end IP Service Model, network devices and TE decision point have to synchronize each other to setup and maintain the adequate and optimal set of G.LSPs and TE-LSPs. The resulting topology is based on IP services requirements (Protection scheme, _) and computation strategies (Business models, _). This leads to needs for potential new standardization items, as information exchange between routers and TE decision point (in case of G.LSP setup failure, _). This will be tackle via subsequent studies. 9. G.LSP advertisement to the IP layer The decision point may thus trigger the set-up of an additional G.LSP to an already connected boundary CNE. Alternatively, it may trigger a rearrangement of existing G.LSPs, or the establishment of a G.LSP to a boundary CNE that could previously not be reached through the optical domain. It might very well be that the decision point triggers a boundary CNE to drop a G.LSP 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 the G.LSP create requests, the routing protocol parameters should be dynamically configurable as well. This section outlines a proposal to achieve a seamless integration of a new G.LSP within the IP service domain for the overlay model by means of automatic configuration. As soon as a G.LSP to a particular boundary CNE has been lit up, it is assumed that it is promoted to an operational IP link. In case of, e.g., regular SDH/SONET framing, this is achieved by running PPP protocol on the newly established G.LSP. 9.1 G.LSP set-up to a previously unreachable boundary CNE The draft [ompls-ospf] defines the different facets of the creation of an IP link in case of a peer-to-peer 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 CNEs. Indeed, once the first G.LSP is established between two boundary CNEs and promoted as IP link, it is to be advertised as a point-to-point link for IP routing in order to Duroyon et al. Expires May 2001 14 draft-duroyon-te-ip-optical-01.txt November 2000 initiate the IP connectivity between the two boundary CNEs. And subsequently it will allow IP reachability between the associated IP service domains. Two cases must be considered. The G.LSP is promoted to an IP link connecting: - two boundary CNEs of the same Autonomous System (IGP peering), or, - two boundary CNEs 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 G.LSP be bi-directional, because IGP protocols require a bi-directional transport layer. Bi-directional G.LSP setup is further detailed within [g-mpls] and [onni-framework]. From an addressing point of view, the Packet switch capable end- points can be unnumbered (and, e.g., identified by the Router Id of the boundary CNE), or numbered through initial configuration, but different from the IP address assigned to the UNI signaling agents (UNI-Client and UNI-Network) terminating the signaling channel. It has to be noticed again that within the overlay model, the signaling channel identification is neither known nor advertised throughout the IP service domain. 9.1.1 IGP support Once the first IP link is established between two boundary CNEs and configured to support an IGP peer, the boundary CNEs 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. These parameters have to be accessible and are automatically configured (prior to or at the time of G.LSP establishment) by the Duroyon et al. Expires May 2001 15 draft-duroyon-te-ip-optical-01.txt November 2000 decision point of the IP service domain to efficiently deploy the IP service on top of the G.LSP. 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 CNE pairs. The decision point should be allowed to overwrite those parameters at the setup time of the G.LSP. 9.1.2 eBGP peering In the case of an inter-domain G.LSP, static route configuration specifying the BGP peer (most probably a virtual interface of the remote boundary CNE) should be configured in the local boundary CNE 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 G.LSPs. As opposed to the IGP peering case, triggering of inter-domain G.LSPs will very likely not arise from an automated process because of the BGP peering negotiation procedure. 9.2 Set-up of an additional G.LSP In addition to the option described in 9.1 (creation of a new stand-alone IP link with the new G.LSP and advertisement to the routing protocol), a second option is now possible, which is to create an additional G.LSP to an existing IP link that forms a bundled link [mpls-bundle]. In this case there is no new configuration necessary for the IGP or BGP routing layer but only interactions internal to the boundary CNEs. This bundle is advertised as a single IP link. The G.LSP in itself may be unidirectional, and hence the bundle could have an asymmetric bandwidth. - The boundary CNE upgrades the bandwidth of the bundle link based on the characteristics of this new G.LSP. - The new G.LSP is included in the load balancing mechanism that distributes the traffic amongst the component G.LSPs of the bundled link, e.g., proportional to their bandwidth. - The addition of a new G.LSP to a bundle does not impact the routing topology. Only the new bandwidth of the IP link is advertised within the IP service domain. The other characteristics of the IP link, e.g., the resource classes, remain unchanged. Duroyon et al. Expires May 2001 16 draft-duroyon-te-ip-optical-01.txt November 2000 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 G.LSP is to be added. 9.3 Rearrangement of an existing G.LSP Within the optical network, two alternatives could be considered for the rearrangement of an existing G.LSP: - Either the non-destructive modification of an already established G.LSP. In this case, the source and destination termination-points of the G.LSP can not be changed, but other parameters such as bandwidth and network protection could be modified without disrupting the working G.LSP. - Or the destructive modification of an already established G.LSP. This case is the straightforward combination of G.LSP tear-down followed by a new G.LSP set-up towards a different destination. 10. References [diffserv-framework] Y.Bernet et al, "A Framework for Differentiated Services", Internet Draft, draft-ietf-diffserv- framework-03.txt, February 1999. [g-mpls] Peter Ashwood-Smith et al., "Generalized MPLS _ Signaling Functional Description", Internet draft, draft-ietf-mpls- generalized-signaling-00.txt, October 2000. [ip-optical] James Luciani et al., " IP over Optical Networks _ A Framework", Internet draft, draft-ip-optical-framework-00.txt, February 2000. [ompls-isis] K. Kompella et al., "IS-IS Extensions in Support of MPL(ambda)S", Internet Draft, draft-kompella-isis-ompls-extensions- 00.txt, July 2000. [ompls-ospf] K. Kompella et al., "OSPF Extensions in Support of MPL(ambda)S", Internet Draft, draft-kompella-ospf-ompls-extensions- 00.txt, July 2000. [mpls-bundle] K. Kompella et al., "Link Bundling in MPLS Traffic Engineering", Internet Draft, draft-kompella-mpls-bundle-02.txt, July 2000. [onni-framework] D.Papadimitriou et al,. "Optical NNI Framework and Signaling Requirements", Work in progress, draft-papadimitriou- onni-framework-00.txt, November 2000. [ouni-framework] B.Rajagopalan et al., `Signaling Requirements at the Optical UNI', Internet Draft, draft-bala-mpls-optical-uni- signaling-00.txt, July 2000. Duroyon et al. Expires May 2001 17 draft-duroyon-te-ip-optical-01.txt November 2000 [OIF2000.125.2] B. Rajagopalan et al., "User Network Interface v1.0 Proposal", OIF Contribution 125.2, October 2000. [OIF2000.200] D. Pendarakis et al., "Signaling Transport Mechanisms for UNI 1.0", OIF Contribution 200, September 2000. [OIF2000.261.1] D. Papadimitriou et al., "Address Registration and Resolution", OIF Contribution 261, November 2000. 11. Acknowledgments The authors would like to thank Emmanuel Desmet, Sitaram Kalipatnapu and Gert Grammel for their constructive comments. 12. Author's Addresses Olivier Duroyon Alcatel USA 15036 Conference Center Drive Chantilly, VA, 20151 Phone: (703) 679 6415 Email: olivier.d.duroyon@usa.alcatel.com Rudy Hoebeke Alcatel Bell 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 Dimitri Papadimitriou Alcatel NSG-NA Francis Wellesplein 1 2018 Antwerp, Belgium Phone: (32) 3/240.84.91 Email: dimitri.papadimitriou@alcatel.be Duroyon et al. Expires May 2001 18