Network Working Group D. Papadimitriou Document: draft-papadimitriou-enhanced-lsps-04.txt J. Jones Category: Internet Draft Alcatel Expiration Date: January 2002 July 2001 Enhanced LSP Services in Optical Networks draft-papadimitriou-enhanced-lsps-04.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. 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 [1]. Abstract In the scope of the domain service model as defined in [IPO-FRM], the main objective of this document is to integrate within the set of services covered by this model Virtual Private optical Networks (VPoN), Connection Survivability by using the Shared Risk Link Group (SRLG) inference model, Class-of-Priorities and Class-of-Service (CoS) as well as Waveband and Optical Multicast connection services. Papadimitriou et al. Expires January 2002 1 draft-papadimitriou-enhanced-lsps-04.txt July 2001 1. Introduction Current IP protocols extensions for Integrated or Differentiated services, for Traffic-Engineering (Multi-Protocol Label Switching), for privacy (Virtual Private Networks), for multicast applications (IP Multicast protocols) and for security (IPSec Protocol) result from the short-term perspective when the IP protocol was defined at the beginning of the eighties. Now, the current developments on optical networking are challenging the same problem: if these features are not included from the beginning within the signalling and routing protocols used in optical networking, future needs wonÆt be covered by the current developments. The main objective of this memo is to include within the LSP connection services provided currently when using GMPLS-based signalling and routing protocols, the following connections services: the Virtual Private optical Network (VPoN), the Class-of- Service (CoS), Waveband and Optical Multicast connection services. Such services are really the ones (additional services can be defined in the future) that will provide added value comparing to the current situation in traditional optical networks. In order to structure the integration of these services within the signalling and routing protocols, we propose to separate the types of information enabling the optical network to provide these services. For an optical network controlled through a distributed IP-based control plane optical sub-network we suggest here to differentiate the identification and connection service information available on each Optical LSR (OLSR) from the centralized information (for instance, related to the network policy) available through directory services. This means that we consider for scalability, convergence and performance reasons that keeping all the policy-related parameters would result in an overflow of information to be distributed throughout the optical network giving rise to an increasing convergence time of the optical network routing database. 2. Optical Networks Foundation This section briefly describes two examples of widely used optical technologies that can provide enhanced LSP Services through the use of an IP-based distributed control plane (such as the one defined by the Generalized MPLS protocol suite) with a Domain Service Model. The latter in described in section 2.2. 2.1 Transport Technologies for Optical Networking The Optical Transport Network (OTN) defined in G.872 [ITUT-G872] and G.709 [ITUT-G709] enables optical transmission of various client signal types through the use of Forward Error Correction (FEC) bytes. ITU-T G.872 defines a functional architecture for an optical Papadimitriou et al. Expires January 2002 2 draft-papadimitriou-enhanced-lsps-04.txt July 2001 transport network that supports the transport of digital client signals. ITU-T G.709 recommendation specifies the data plane transport structure and allocates overhead bytes for the OTN control plane. It defines the digital path structure to be transported into optical channels. In the below sub-sections section, we describe shortly the G.709 Digital and Optical Transport Hierarchies (OTH) defined at the ITU- T. This by taking into account that today the most widely deployed legacy transmission networks (in particular in Wide Area Networks - WAN) are based on SDH and SONET. More details on OTN and Pre-OTN developments can be found in [G709-FRM]. 2.1.1 Pre-OTN DWDM Development ITU-T G.709 describes pre-OTN development (also referred to as DWDM development) for backward compatibility with the current DWDM system deployment. Pre-OTN DWDM systems (which were not defined at the ITU prior to the G.709 recommendation) have been developed during the last years in order to overcome the bandwidth limitations and increase the bit-rate per fiber until several Tbps per fiber. In the future, pre-OTN DWDM systems will provide up to hundred of wavelengths per fiber. These developments include the definition of point-to-point DWDM optical channels on top of a mesh optical topology including Optical Cross-Connects (OXC) or Photonic Cross-Connects (PXC). A PXC is defined as an all-optical device (i.e. no O/E/O interface conversion) so that 1R optical amplification can be provided by such interfaces. Conversely, an OXC is defined as a non-transparent device providing O/E/O conversion at each interface (also referred to as 3R for Reamplification, Reshaping and Retiming) such devices are capable to switch a whole STM-N/OC-N signal or MSn/STS-N signal. Thus the Regenerator Section or the Multiplex Section is respectively terminated (at least for certain overhead bytes) by the switch interfaces. This means that such devices donÆt provide the so-called VC-4/STS-1 SPE re-grooming capability. On the contrary, an Opaque OXC is defined in the scope of this document as a VC-4/STS-1 SPE SDH/Sonet cross-connect, which is therefore strictly equivalent to a DXC with optical transceivers on its line interfaces. The current bandwidth bottleneck is overcome by the use of DWDM systems. Today, DWDM systems allow the multiplexing of more than 160 wavelengths of 10 Gbps (1.6 Tbps per fiber with a 25 GHz spacing) using the C-band and the L-band. Recent optical technology improvements enable channel spacing of 12.5 GHz for 2.5 Gbps signals. Consequently, it will be possible to house 320 wavelengths of 2.5 Gbps in a single fiber. A complementary method for increasing the effective capacity of a DWDM system is to include the 1480nm (Short Band) and 1650nm (Ultra-Long Band) bands by providing fibers covering ultra-wide optical bands from 1460 to 1675nm. Papadimitriou et al. Expires January 2002 3 draft-papadimitriou-enhanced-lsps-04.txt July 2001 In the pre-OTN application, client signals are either directly mapped on the wavelength (i.e. optical channel) or mapped through by using an intermediate mapping-framing variable-length layer also referred to as a digital wrapper layer. The former direct mapping is defined for STM-N/OC-N (and Gigabit Ethernet) client signal while the latter is mainly used for packet client layers such as IP and ATM. This means that such developments do not include G.709 client- signal mapping specification through the definition of a dedicated framing procedure. Moreover, additional standard Transparency levels to the one defined for SONET/SDH networks can be specified for Pre- OTN networks. 2.1.2 Optical Transport Networks (OTN) Optical networks comprise a set of functionality providing transport, multiplexing, routing, supervision and survivability of client signals that are processed predominantly in the optical domain. Optical signals are characterized by wavelength and may be processed per wavelength or as a wavelength division multiplexed group of wavelengths. The OTN model is decomposed into independent (transport) network layers where each layer can be separately partitioned in a way that reflects its internal structure. Thus, the OTN model refers to a layered structure comprising a Digital and an Optical Transport Hierarchy (OTH). The development of a digital and an optical transport hierarchy (i.e. networking layer) is required for the following reasons: - It is the next step (after TDM - SDH/SONET) to support ever growing data driven needs for bandwidth and emergence of new broadband services - To support next generation Terabit/second per fiber via DWDM lines at the transport level as well as optical channels at 2.5 Gbps, 10 Gbps and 40 Gbps bit rates at wire speed level (and in the future 160 Gbps currently under definition) - To provide network operational management, planning, administration, survivability, and finally cost of maintenance limited only to the OTUk/ODUk rates of transmission without caring about the granularity of the client signal. In the optical domain, the following network layers are currently defined, they constitute the Optical Transport Hierarchy: - Optical Transmission Section (OTS) layer: This network layer provides functionality for transmission of optical signals on optical media of various types. This layer ensures the integrity and maintenance of the optical transmitted signal by overhead processing. - Optical Multiplex Section (OMS) layer: This network layer provides functionality for networking of a multi-wavelength optical signal. A "multi-wavelength" signal includes the case of just one optical channel. This layer ensures the integrity and maintenance of the Papadimitriou et al. Expires January 2002 4 draft-papadimitriou-enhanced-lsps-04.txt July 2001 multi-wavelength signal by overhead processing. - Optical Channel (OCh) layer: this network layer provides end-to- end networking of optical channels for transparently conveying client information of various formats (e.g. SDH STM-N, Sonet OC-N, ATM, IP, etc.). The capabilities of this network layer concern connection re-arrangement for flexible routing, overhead processing, administration and maintenance functions. For the three layers specified above, non-associated overhead is transported via the Optical Supervisory Channel (OSC) in order to manage the optical connectivity. It has to be noted that these three layers are common to both pre-OTN and OTN applications. STM-N GbE ATM GFP | | | | | | | | v v v v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ======================== | OCh Payload Unit (OPUk) | STM-N GbE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------------------------ | | | OCh Data Unit (ODUk) | Digital Path Layer | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------------------------ v v | OCh Transport Unit (OTUk) | Digital Section Layer +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ======================== | Optical Channel Layer (OCh) | +-----------------------------------------+ Optical Channel Layer | Optical Channel Multiplexing | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ======================== | Optical Multiplex Section OMS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optical Physical Section | Optical Transmission Section OTS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ======================== As far as the client signal handling is concerned, the Digital Wrapper layer is further layered as follows: - The Optical Channel Transport Unit (OTUk) provides FEC capabilities and optical section protection and monitoring capabilities. - The Optical Channel Data Unit (ODUk) layer provides client independent connectivity, connection protection and monitoring (also without the need to terminate the overhead information, the ODUk overhead may be monitored non-intrusively). - Clients signals i.e. STM-N signals, IP packets, ATM cells and Ethernet frames are mapped (meaning digitally wrapped) into a new structured frame defined as Optical Channel Payload Unit (OPUk). For each of the three layers specified above, an associated (in- band) overhead carrying the management information is added inside the framed structure itself. Notice, that only the ODUk (k= 1, 2, 3) and OCh are defined today as networking layers. The OPUk, ODUk and OTUk layers constitute the Digital Transport Hierarchy also referred to as the Digital Wrapper Layer. Papadimitriou et al. Expires January 2002 5 draft-papadimitriou-enhanced-lsps-04.txt July 2001 2.2 Service Models for Optical Networking Two service models are generally considered for the services at the boundary between distinct administrative entities (sometimes corresponding to separate technological domain or clouds): the domain service and the unified service model. The former is largely covered in [GMPLS-ARCH] and [IPO-FRM] while the latter is discussed more extensively in this section in particular from the connection service perspective. Under the domain service model, the transport network primarily offers high bandwidth connectivity in the form of Lambda Switched LSP (L-LSP). The client LSR when requesting the following connection services uses standardized signalling protocols across the domain service interface: LSP creation/deletion/modification (non- disruptive) and status enquiry. Moreover LSP tracing from the source to the destination (as provided today by a TraceRoute function in the IP domain) or simply ICMP-like commands must be provided to the client LSR in order to check the integrity of the connections. Remember here that LSPs are non-packet LSPs meaning that under definition MPLS (tunnel) tracing methods are not applicable as such to verify the status of a connection. An end-system discovery procedure (also referred to as neighbor discovery) may be used over the boundary interface (the domain service interface) to verify local port connectivity between the optical network and client LSR. Finally, a service discovery procedure can be executed to obtain details about the connection services offered by the optical network. The protocol (or extensions) defined for neighbor discovery purposes are different from the signaling protocol itself. They can be implemented for instance through the use of LMP (see [MPLS-LMP]) or BGP (see [RFC- 1771]). The set of connection services is offered across the domain service interface such that the signaling protocol must provide a few messages with certain edge-to-edge dedicated attributes only significant between the client LSR and the optical network. Such a protocol can be based on RSVP-TE [MPLS-RSVP] or CR-LDP [MPLS-LDP] as defined today in [GMPLS-SIG] extended to RSVP-TE [GMPLS-RSVP] and CR-LDP [GMPLS-CRLDP]. The domain services model does not deal with the type and nature of routing protocols within the optical network. However, the use of an IGP routing protocol extended to include Traffic-Engineering attributes such as [GMPLS-OSPF-TE] and [GMPLS-ISIS-TE] is certainly the best solution. Furthermore, the integration of multiple, sub- networks across inter-domain interface could require the specification of extensions to inter-domain routing protocols such as BGP. The domain services model would then result in the Papadimitriou et al. Expires January 2002 6 draft-papadimitriou-enhanced-lsps-04.txt July 2001 establishment of an LSP topology (in the context of this memo, Lambda-LSP and Fiber-LSP) and between client LSRs located at the edge of the optical network. 3. Connection Identification The connection services provided by the optical network are closely related to the connection end-point identification. The following LSR interface (referred here to as non-PSC interface) identification parameters are considered from the client and network perspective. 3.1 Client and Optical LSR Interfaces An Optical LSR (OLSR) refers to either an Optical Cross-Connect (OXC) or a Photonic Cross-Connect (PXC) while a Client LSR refers usually to a router, an SDH/Sonet or an OXC. In the context of this memo and as usually agreed an OXC is defined as an O-E-O capable device while a PXC is defined as an O-O capable device. 3.1.1 Non-PSC Interfaces Optical and Client LSRs include devices where the forwarding decision is based on time slots, wavelengths, or physical ports. So, the set of Optical LSRs interfaces is defined as including the following classes of interfaces in addition to the Packet Switch Capable (PSC) interfaces and Layer-2 Switch Capable (L2SC) interfaces: - Time-Division Multiplex Capable (TDM) interfaces: Interfaces that forward data based on the data's time slot in a repeating cycle. Such interfaces belong mainly to SDH/SONET Cross-Connect (XC), Add-Drop Multiplexer (ADM) and G.709 Cross- Connect (operating at the Digital Transport Layer). - Lambda Switch Capable (LSC) interfaces: Interfaces that forward data based on the wavelength on which the data is received. Such interfaces belong mainly to Photonic Cross- Connect (PXC), Optical Cross-Connect (OXC) and G.709 Cross-Connect operating at the optical channel layer. - Fiber-Switch Capable (FSC) interfaces: Interfaces that forward data based on a position of the data in the real world physical spaces. Such interfaces belong mainly to (Multi-Service) Cross-Connects capable to switch the content of a whole fiber. To each of these interface types corresponds a Label Switched Papadimitriou et al. Expires January 2002 7 draft-papadimitriou-enhanced-lsps-04.txt July 2001 Path (LSP) type. Consequently, the following LSP types are defined: TDM-LSP, Lambda-LSP (L-LSP) and Fiber LSP (F-LSP). LSPs can be established only between, or through, interfaces of the same type. The concept of nested LSP (LSP within LSP) facilitates building of an LSP hierarchy. This hierarchy of LSPs can occur on the same interface or between different interfaces. Therefore nesting can also occur between interfaces belonging to distinct layers. The following diagram illustrates the LSP nesting concept and the LSP hierarchy. P-LSP P-LSP | | | | V | +------------+ | ----| LOVC TDM |--------- | TDM-LSP| +------------+ TDM-LSP | | --->| HOVC TDM |------ | | +------------+ | | | | | | | | | | V V V | | +-------------+ TDM-LSP| ------>| LSC | | +-------------+ | | V |L-LSP +------------+ | | FSC |<--------- +------------+ Needless to say, that this memo is mainly focused on Lambda-LSP (L- LSP) services either standard (G.709 OTN based) or non-standard (including pre-OTN developments). 3.1.2 Non-PSC Interfaces Address Space We consider here that any transport and control addressing scheme uses IPv4 and/or IPv6 addresses. Other categories of addressing schemes such as NSAP are not considered in this memo. This because as described in [GMPLS-ARCH], it would imply a modification of the already existing signaling and routing protocols (included in the Generalized MPLS protocol suite) that uses IPv4 and/or IPv6 addresses. The fact that IPv4 and/or IPv6 addresses are the only considered doesn't imply at all that they should be allocated in the same addressing space than public IPv4 and/or IPv6 addresses used for the Internet. Papadimitriou et al. Expires January 2002 8 draft-papadimitriou-enhanced-lsps-04.txt July 2001 Each network layer could have a different administrative authority responsible for address allocation and re-using the full addressing space, completely independently though this does not seem to be the most efficient way to allocate and manage the address space(s). While private IP addresses can be used if they don't require to be exchanged with any other operator, public IP addresses are otherwise required. As part of the Domain Service Model and as described in [IPO-RTG], reachability information exchange through the Domain Service interface, using eBGP protocol for instance, is considered as a must within the scope of this document. 3.1.3 Non-PSC Interface Identifier Space The following parameters are related to the physical-level interfaces identification of Client and Optical LSR. Identifier space value is purely local to each node. Therefore these values are not used for routing purposes: - Port ID: integer indicating and identifying a port within an Optical LSR (OLSR) - Channel ID: integer indicating and identifying a channel (i.e. a wavelength) within a given port ID - Logical-port ID: identifies a logical port whose identifier is defined as the concatenation of the Port ID and the Channel-ID. These definitions can be extended to identify the client network element (client LSR) interfaces also simply referred to as LSR interfaces. 3.2 Optical Network Identification The optical network identification parameters can be defined, as a Carrier Identifier (Carrier ID) is an integer defining the identity of the carrier to which the OLSR element belongs. The Carrier ID uniquely determines the owner of a signalling message when travelling over inter-domain interface signalling channels between optical networks. Typically the Carrier ID will be assigned to the BGP AS number (2 bytes). This identifier is provisioned by the administrative authority of the optical network and can be exchanged during the neighbor discovery process or any other inter-domain routing protocol exchange such as BGP [RFC-1771]. 3.3 Client Network identification Papadimitriou et al. Expires January 2002 9 draft-papadimitriou-enhanced-lsps-04.txt July 2001 The client network identification parameters include additionally to the Client LSR logical-port ID, the Client Network Identifier (Client Network ID) and the VPN Identifier (VPN ID): - Client Network ID: identifier uniquely defining a client network (or a group of client LSR belonging to the same administrative authority) with respect to a given optical network domain. This parameter should not have any complex semantic nor meaning and could be useful when considering optical broadcast and multicast applications. The Client Network ID (or simply Client- ID) will be typically the BGP AS number (2 bytes) of the client Network or simply the Client device Node ID (for instance, an IPv4 loopback address taken from the public IPv4 address space). - VPN ID: VPN identifiers as defined in [RFC-2685] The VPN ID is equivalent to the VPoN ID (Virtual Private optical Network), however since the corresponding model does not apply only to optical networks but also to SDH/SONET or any kind of ôlayeredö transport network, we donÆt refer to VPoN identifiers in this document. In absence of a centralized network authority, the source and destination OLSR are responsible for authentication of VPN IDs and for call acceptance policies. In the absence of a pre-determined policy, the default behavior is for the destination client LSR to accept the LSP create request if the destination client LSR is part of the signaled and authenticated VPoN. Since a boundary OLSR can potentially be connected to multiple client LSR, or a given client LSR can potentially request LSP for several VPoNs, this identifier defines the possibility to setup Virtual Private optical Networks (VPoN). The corresponding models are described in Section 3.4. The association of the client source address (and by extension the OLSR address) with the logical-port ID (LPID) is used in the context of the VPoN model. This implies the VPoNs services are defined at the optical channel level and not only at the port level meaning that the granularity of the VPoN can be finer than the one classically defined for the so-called layer-1 VPNs. The association of an (Client or OLSR) address and an LPID is referred to as a connection termination-point identifier (CTID). Typically, the Client and OLSR address space is IPv4. Mappings between Client and OLSR termination point identifier [;] are then associated through the domain service interface signalling to the VPN ID to which the LSP connection requests refers. The ingress (and egress) OLSR need only to maintain a mapping table where this information is stored per VPN ID. This approach easily provides Papadimitriou et al. Expires January 2002 10 draft-papadimitriou-enhanced-lsps-04.txt July 2001 VPoN service to the client network. 3.4 VPoN Model The VPoN - Virtual Private optical Network model considered here are based on the following concepts: - the Client ID defines the identification of an optical network client (for instance, an ISP) - the VPN ID defines the identification of a group defined within this optical network client (for instance an ISP client) The first model considers the Client ID as a VPoN identifier in addition to the VPN ID while the second one considers only the VPN ID as a VPoN identifier. If we consider the Client ID as a VPoN identifier, then the following alternative could be considered: - isolation of the resources within a given VPoN (for instance, a given ISP client) - isolation of the resources between VPoNs within a given Client- ID (for instance, between ISP clients belonging to the same ISP) - no-isolation of the resources i.e. sharing of the resource between clients within the optical network In this example, the optical network has several clients (i.e. ISPs identified by a unique Client ID) and each of the optical network clients has several clients (i.e. ISP clients identified by a unique VPN ID). If we only consider the VPN ID as a VPoN identifier, then the following alternative could be considered: - isolation of the resources within a given VPoN (for instance, a given ISP) - no-isolation of the resources i.e. sharing of the resource between VPoNs within the optical network In this example, the optical network has several clients (i.e. ISPs identified by a unique VPN ID) and there is no dependence of the isolation regarding the owner of the VPoN. If we consider a unique address space per optical network, it means that any address belonging to any VPoN must be unique. Otherwise, if we consider on address space per VPoN (for instance, per Client ID), then the address uniqueness is limited to this VPoN. As specified in [RFC-2685], a VPoN may use a private address space, which may overlap with the address space of another VPN or the Internet public networks. A VPoN may span multiple optical domains (BGP AS) meaning that an IP address only has meaning within the VPN in which it exists. For this reason, it is necessary to identify the VPoN in which a particular address space is meaningful. Note Papadimitriou et al. Expires January 2002 11 draft-papadimitriou-enhanced-lsps-04.txt July 2001 also that [RFC-2685] recognized the advantage of identifying any particular VPoN at any layer and at any location in which it exists using ideally the same VPoN identifier. Consequently, the case with address space uniqueness per VPoN is most flexible since it permits to connect clients having overlapping address spaces. However, this also requires for the optical network to maintain a mapping table per VPN ID. 4. Optical Connection Services Optical Connection Services include LSP Connection Services, LSP Protection and LSP Routing. 4.1 Basic LSP Connection Services Basic LSP connection services are provided through the exchange of the parameters considered within this sub-section. They offer the possibility to implement the basic connection (i.e. LSP) service requests through the domain service interface. These parameters are mainly the framing, the bandwidth, the directionality and the network protection level. 4.1.1 Framing The Framing parameter specifies the encoding format of the signal for the requested connection. The Framing represents the networking layer at which the requested connection will operate throughout the optical network. The Framing-type (referred to as LSP Encoding Type in [GMPLS-SIG]) for LSP established throughout an optical network could be one of the following: - Ethernet: LAN Ethernet (LAN PHY) and WAN Ethernet (WAN PHY) - TDM: SDH (ITU-T G.707) and SONET (ANSI T1.105) - Digital Wrapper: ITU-T G.709 Digital Path and Proprietary - Optical: ITU-T G.709 Optical Channels and Non-standard Lambda 4.1.2 Bandwidth The Bandwidth values are defined with respect to the Framing-type. Signal Types extend bandwidth values since the latter can take only discrete values for non-packet LSP: TDM-LSP (i.e. SDH/SONET LSP), L- LSP (i.e. G.709 Optical Channel LSP). We refer here to [GMPLS-SIG], [GSMPL-SDH] and [GMPLS-G709] for more details concerning the Signal Types definition and their respective value space for SDH/SONET and G.709 OTN. 4.1.3 Directionality Papadimitriou et al. Expires January 2002 12 draft-papadimitriou-enhanced-lsps-04.txt July 2001 As described in [GMPLS-SIG], bi-directionality of an LSP is defined by the use of an upstream label within the LSP create request. 4.1.4 Network Protection Signalling the network protection requested for an L-LSP can be performed in two ways: either explicitly or implicitly. 1. Explicit Protection indication The Protection parameter specifies the protection level desired for the requested LSP inside the optical network (i.e. internal network protection). Notice that protection at the domain service interface (source- and destination-side protection) levels is not covered since the domain service model implies that the protection of the L- LSP initiated by the client is up to the corresponding networking layer. The corresponding LSP nesting can be illustrated as follows: ++++++++++++++++++++++++++++++ + + C1 ----------- N1 ----- N2 ----- N3 ------------ C2 | -> A + | / \ | + -> A | | + | / \ | + | | + | / \ | + | ------------ N4 -------------- N5 ------------- -> B + + -> B ++++++++++++++++++++++++++++++ Protection at the Network layer: - Client Request: C1 to C2 Protected LSP - Network Request: Primary LSP using [N1 û N2 û N3] Secondary LSP using [N1 û N4 û N5 û N3] Protection at the Client layer: - Client Request: C1 to C2 LSP (Primary LSP) through path A - Client Request: C1 to C2 LSP (Secondary LSP) through path B Several network protection services (or network edge-to-edge LSP protection) can be defined: - Extra-Traffic (preemptable) - Unprotected (default value) - Re-routing (path-level edge-to-edge restoration) - Multi-Group Shared Protection M:N (particular case 1:N) - Group Shared Protection M:N (particular case 1:N) - Dedicated 1:1 Protection - Dedicated 1+1 Protection - Enhanced Protection (ring-based protection) Related to these protection types and levels, a reversion strategy could be defined: - a revertive strategy means that a LSP gets restored to its original route after a failure has been recovered (or Papadimitriou et al. Expires January 2002 13 draft-papadimitriou-enhanced-lsps-04.txt July 2001 restored) - a non-revertive strategy means that a LSP does not get restored to its original route after a failure has been recovered (or restored) The network protection mechanisms are extensively detailed in [IPO- RES] together with the required signalling protocol extensions. Enhanced protection (i.e. ring-based protection) concepts and mechanisms are detailed in [IPO-RFR]. 2. Implicit Protection indication There is another way to specify within a connection service request the protection level desired; this by indicating the Class of Service to which the requested LSP belongs. The Class-of-Services (CoS) are detailed in section 5.4. 4.2 Pre-OTN Connection Service Pre-OTN LSPs are also referred to as optical SDH/SONET connections. Since the SDH/SONET parameters applies only to SDH/SONET framing (i.e. LSP Encoding Type), Pre-OTN connection service includes the Transparency levels supported by the optical non-transparent network. Transparency levels currently supported in such optical networks are: - Path OH transparency: the network can transparently transport HOVC/STS-SPE connections (in that case the corresponding LSP is equivalent to a TDM-LSP) - Multiplex Section/Line OH (MSOH/LOH) Transparency: the network can transparently transport MSn/STS-N connections - Regenerator Section/Section OH (RSOH/SOH) Transparency: the network can transparently transport STM-N/OC-N connections (such transparency service is supported by default throughout G.709 OTN networks) Semi-transparent levels can also be defined with respect to the Client Signal; in that case, the network transparency levels are referred to as OverHead tunneling levels: - Specific MSOH/LOH bytes Transparency such as MS/Line DCC (D4 - D12) or K1/K2 bytes: the network can non transparently transport MSn/STS-N connections while keeping the MS/Line DCC or other MSOH/LOH bytes unchanged - Specific RSOH/SOH bytes Transparency such as RS/Section DCC (D1 û D3) or J0 bytes: the network can non transparently transport MSn/STS-N connections while keeping the MS/Line DCC or other MSOH/LOH bytes unchanged Such transparency service provides for instance in-fiber/in-band signalling transport mechanism across the optical network for SDH/SONET client networks. Consequently, the optical network does Papadimitriou et al. Expires January 2002 14 draft-papadimitriou-enhanced-lsps-04.txt July 2001 not use anymore the corresponding MSOH/LOH and/or RSOH/SOH overhead bytes to provide its internal signalling transport mechanism. 4.3 OTN Connection Service As described in Section 2.1 based, the OTN connection service is based on the G.709 specification [ITUT-G709]. However, today most of the client LSR interfaces donÆt support G.709 specification (in particular when client LSR are routers) so that at the domain service interface client-to-network interconnection is provided through the use of Pre-OTN interfaces supporting STM-N/OC-N signals. The client signal is terminated at the ingress Optical LSR (OLSR) and then either tunneled or simply continued within the optical network. This suggests the definition of an interworking function OTN<->Pre- OTN at the Domain Service Interface (i.e. ingress and egress OLSR). GMPLS Signalling for OTN connection service is defined in [GMPLS- G709]. Such service provides also the full transparency of the client signal (see Section 4.2). 4.4 All-Optical Connection Service The distinction between the OTN and the All-Optical connection service is made for the following reasons. First the OTN compliance refer to an Optical Transport Hierarchy (OTH) as described in [G709- FRM]. Then, OTN compliance implies the implementation of intra- domain optical signal control and monitoring capabilities through a specific implementation of the control plane using non-associated overhead at the OTH level. Therefore, the optical signal control and monitoring capabilities can be provided either by using the G.709 non-associated OverHead (naOH) through the Optical Supervisory Channel (OSC) or by using non-standardized methods. The latter refers to methods using technology such as optical signal Sub-Carrier Multiplexing (SCM). More details about this technology are available in [IPO-SCM]. 4.4.1 All-optical Connection Service - Overview When considering a Domain Service Model, the key issue concerning all-optical connection service is that the client optical signal must be terminated at the ingress AND at the egress of the optical domain (which includes only PXC nodes except at the edge interfaces toward the client network). Otherwise, it would be impossible for the optical network to control and monitor the connection service provided to the client network. This independently to the fact that the client LSR interfaces must be either colored otherwise wavelength conversion has to be provided at the ingress of the optical network. Papadimitriou et al. Expires January 2002 15 draft-papadimitriou-enhanced-lsps-04.txt July 2001 The alternative is to provide all-optical connection services from the source to the destination client network without terminating the optical channel at the ingress and egress of the network. However, such approach requires providing to the client LSR an access to the optical control plane since clients nodes must now have the capability to perform their own L-LSP connection management. This would in turn require the definition of Virtual Private control Networks (VPcN) in order to guarantee some privacy. Notice here the difference between a VPoN and VPcN: the VPoN is a private network defined at the transport plane level while the VPcN is defined at the control plane level. 4.4.2 All-Optical Connection Parameters These parameters are related to all-optical networking connection services. These parameters can be sub-divided into two groups. First, the ones used to monitor the optical signal quality such as the Bit Error Rate (BER). Then, the optical parameters used for optical routing purposes (commonly referred to as optical routing impairments) such as the Optical Signal-to-Noise Ratio (OSNR), Polarization Mode Dispersion (PMD). The optical signal performance monitoring is achieved by measuring (through methods not defined in this document) the BER. As parameters, the BER is defined the exponent of the maximum BER admitted for a given optical signal (default value is zero). Real- time measurements allow performing signal quality monitoring and therefore on-line measurements. In turn, this method enables to determine whether or not the current optical signal quality meets the optical connection Service Level Specification (SLS). Concerning optical routing impairments, linear parameters such as Optical SNR (OSNR) and Polarization Mode Dispersion (PMD) are considered in [IPO-ORI] for sub-optimal optical routing. Amplified Spontaneous Emission (ASE) influence the Optical SNR (OSNR), which determines an upper bound to the maximum number of spans that an L- LSP can traverse. The PMD determines an upper bound to the maximum optical span length that an L-LSP can traverse. More details about optical routing linear impairments can be additionally found in [IEEE-ORL]. Nevertheless, these linear parameters constitutes a subset of the optical routing impairments that have to be considered for Long Haul optical transmission (> 2000 km). We refer to [IPO- NLRI], where non-linear optical routing impairments are considered. For non-transparent optical transport networks, one has to take into account the Jitter parameter in addition to the Bit Error Rate (BER). This parameter is defined as the maximum jitter admitted for a given optical signal (default value is zero) also referred to as Jitter Tolerance. There are currently three types of jitter specifications: - jitter tolerance: the peak-to-peak amplitude of sinusoidal jitter applied on the input signal that causes a 1dB power Papadimitriou et al. Expires January 2002 16 draft-papadimitriou-enhanced-lsps-04.txt July 2001 penalty - jitter generation: the process whereby jitter appears at the output port û transmission û in absence of input jitter - jitter transfer: a measure of the quantity of input jitter attenuation with respect to the output signal 5. Enhanced Optical Connection Services This section covers the connection services such as Optical Multicast, Waveband Switching, Optical Class-of-Services and VPoN services. 5.1 Multicast Service Today, as described in [GMPLS-SIG], an LSP request can translate either a unidirectional unicast connection or a bi-directional unicast connection. Optical multicast connection service provides the capability to establish point-to-multipoint LSPs throughout the optical network. In this case, the ingress client and optical LSR could have many destinations in common therefore reducing the number of wavelengths used per fiber link. Optical multicast is detailed in [IPO-OMF] as well as the related signalling considerations. We briefly summarize here the rationale and key associated concepts. The optical multicast concept can be applied to numerous client- layer applications covering mainly Optical Broadband applications, Multimedia, Video and HDTV. When extended to the optical domain, the multicast concept offers the following advantages: - Efficient optical 1+1 (dedicated) protection - Improved performance (no store and forward) compared to packet- oriented multicast technology - Overall network throughput improvement by reducing the number of wavelengths used per fiber link (i.e. minimizing the overall bandwidth usage per fiber link) - Reduction of the total number of transceivers in all- optical networks. However, the major drawback to overcome in optical multicast-capable networks is to compensate the power penalty introduced during the optical signal splitting. Moreover, the multicast problem in communication networks is NP-Complete (since described by the Steiner Tree Problem applied to communication networks). [IPO-OMF] also extensively details the diverse possibilities that can be considered to extend the currently defined (or under- definition) multicast signalling protocols. 5.2 Waveband Switching Service Papadimitriou et al. Expires January 2002 17 draft-papadimitriou-enhanced-lsps-04.txt July 2001 Waveband Switching refers to the switching of a non-contiguous set of identical optical channels which are to be routed, switched and protected as an individual entity. This service can be useful for inverse multiplexing where high bandwidth client signal is partitioned into multiple lower rate optical channels. For instance a 10 Gbps client signal partitioned into four 2.5 Gbps optical channels. It is desirable that each optical channel use the same physical resources, with identical propagation delay (if O/E/O conversion is needed) and protection schemes, thus minimizing the segmentation and reassembly within the client domain. Waveband Switching underlying concepts are extensively covered in [IPO-WBS] where we demonstrate the benefits from the introduction in optical networks of the optical multi-granularity concept. LetÆs briefly examine the key drivers and advantages provided by the waveband switching services. Today, optical switches are able to handle different switching granularities from wavelength to fiber and especially wavebands. Taking benefits from these technologies, switching larger granularities reduce at the same time the complexity of control operations, the amount of hardware in the optical layer, and in addition relax some physical constraints. Gains expected from the approach are partly function of the efficiency of the grooming of wavelengths into larger granularities. In particular, intelligent intermediate grooming makes the multi- granularity concept even more attractive since reducing the required size of optical switching matrix typically by a factor of two or more. Optical switching allows the transmission capacity of point to point links to scale up to the predicted traffic requirements of multiple Tbps. Hence the switching capacity of backbone nodes has to scale up to thousands of Wavelength Switching Capable (WBSC) interfaces. To overcome the bottleneck of electronic switching, wavelength cross- connects have been introduced. Optical switching can also be extended to switch larger granularities such as bands of wavelengths (also referred to as wavebands) and fibers (also referred to as spatial switching). By considering that optical networks will not experience a significant evolution of their topology properties (connectivity, number of nodes), these new granularities will easily support the traffic growth with limited impact on efficiency. Therefore, the main issue is to find the optimum way to arrange the spatial distribution of traffic flows on the topology in order to create connections at the different optical granularities (i.e. different LSP bandwidth). The intrinsic properties of a typical backbone network give us good perspectives to achieve the goal of dynamically creating LSPs at these granularities. The relatively limited number of nodes (tens of nodes) and the relative small connectivity (3 to 8 neighbors per node) allow us to assume that Papadimitriou et al. Expires January 2002 18 draft-papadimitriou-enhanced-lsps-04.txt July 2001 there will be a strong correlation between flows of traffic inside the network. In other terms, it means that, assuming an efficient planning, numerous flows (e.g. STM-N/OC-N or IP flows) have to be processed in the same way in the nodes. Thus, this should give the opportunity to establish wavelength, waveband and fiber connections, and process most of the traffic using optical granularities as large as possible. This will alleviate some capacity bottlenecks and above all reduce the network cost. In [IPO-WBS], we propose to use this concept of multiple optical granularities in association with grooming strategies and GMPLS integration requirements. Among possible optical switching granularities, waveband is an attractive trade-off for foreseen traffic volumes in next few years and will be particularly considered in the following. For this purpose, waveband-switching layer is introduced as an additional sub-layer between the Lambda and the Fiber layer i.e. between corresponding Lambda-LSP (wavelength switching) and Fiber- LSP (spatial switching). However, this sub-layer does not introduce either a new type of interface or a new class of Forwarding Adjacencies (FA) class since we consider a Lambda LSP (L-LSP) as a particular case of a more generic Waveband-LSP (WB-LSP). In terms of grooming strategies, we also propose to have both end- to-end and intermediate grooming at waveband and fiber levels to make the concept more attractive. Intermediate grouping is referred to as the aggregation of traffic with different source nodes and/or different destination nodes but with a common sub-path at the optical layer. End-to-end grooming (i.e. between source and destination OLSR) is a particular case of intermediate grooming where the sub-path in the optical layer is the entire Lambda-LSP (L- LSP) between source and destination OLSR. 5.3 Priority-Preemption The priority-preemption is a service offering prioritization of the connection requested during the LSP setup with respect to the provisioned priorities of the optical network resources (links, paths, etc.). Then the priority of the connection is used to define a preemptability level of the connection with respect to the setup and/or recovery of other LSPs already provisioned or dynamically established within the optical network. 5.3.1 Priority The Priority specification (as described in [MPLS-CRLDP] for instance) includes the setup and the hold priority. The priority field is defined as an (8-bit) integer indicating the priority of the requested L-LSP: Papadimitriou et al. Expires January 2002 19 draft-papadimitriou-enhanced-lsps-04.txt July 2001 - Default value: from 0xE (higher) to 0x1 (lower) - Priorities from 0xF is reserved - Priorities from 0x0 is reserved Where (4 MS bits) defines the priority-class: C ranges from 1 to E Class 1 is considered as the default class and Class 0 and Class F are reserved priority-classes. The priority value (4 LS bits) within a given priority-class ranges from 0xE (higher priority) to 0x1 (lower priority). 5.3.2 Preemption Preemption is defined as a (4-bit) integer indicating the preemptability behavior of an L-LSP. This parameter specifies whether a given LSP can be preempted by a L-LSP of higher priority if the resource used by the lower-priority L-LSP need to be used during the setup and/or the recovery of this higher priority L-LSP. The possible values for the preemption behavior can be defined as: - Setup and Recovery preemptability: 0x0 (Class 1) - Recovery preemptability : 0x1 (Class 2 to 7) - Setup preemptability : 0x2 (Class 8 to D) - No_preemptability : 0x3 (Class E) 5.4 Class-of-Services The Class-of-Services (CoS), described in [IPO-COS] and based on [DIFF-ARCH] specification, are build upon the following principle: at the (ingress) client LSR, if we consider Packet-Switch Capable(PSC) interfaces, the DiffServ Codepoint (DSCP) [DIFF-DSF] defining the Per Hop Behaviour (PHB) [DIFF-PHB], are mapped to the LSP priority class. For this purpose, we propose the following rules: - Class 1 corresponds to Best-Effort service - Class 2 to D corresponds to Assured Forwarding (AF) services . Class AF1 ranges from 2 to 4 . Class AF2 ranges from 5 to 7 . Class AF3 ranges from 8 to A . Class AF4 ranges from B to D - Class E corresponds to Expedited Forwarding (EF) service These DiffServ classes are related within the optical network to the service-level defined in section 3: - Class 1 defines a best-effort service - Class 2 to 7 defines a bronze service - Class 8 to D defines a silver service - Class E defines a gold service Within our definition of LSP, the analogy between the drop precedence in DiffServ and the priority class could also be related to the preemption setting at the domain service interface during the Papadimitriou et al. Expires January 2002 20 draft-papadimitriou-enhanced-lsps-04.txt July 2001 LSP creation. In this case, the priority value setting is performed through the following rules: - Class 1 defines a priority ranging from 0x11 to 0x1E - Class 2 to 7 defines a priority ranging from 0x21 to 0x7E - Class 8 to D defines a priority ranging from 0x81 to 0xDE - Class E defines a priority ranging from 0xE1 to 0xEE Application of this model will enable to have a selection mechanism at the boundary client LSR (in most of the cases, it will be a router) providing LSP multiplexing based on the mapping between the DiffServ Code Points (DSCP) and the LSP Class-of-Services provided by the optical network. Moreover, this technique enables the direct mapping of finer granularity Packet-based LSP to coarser granularity L-LSPs without any disruption in the end-to-end QoS offered to the client network connections. 5.5 VPoN Service The relationship between the Priority/Preemption and the CoS and VPoN model is based on the resource isolation concept. Two VPoN models have been defined (depending on the usage of the Client ID) so that the Priority/Preemption levels considered here are directly related to these models and the resource isolation concept. If we consider the Client ID as an identifier, then we have the following options concerning the preemption levels: - preemption within a given VPoN (i.e. within VPoN belonging to the same optical network client) - preemption within a given Client ID (i.e. between VPoN belonging to the same optical network client) - preemption between Client IDs (i.e. between optical network clients) If we do not consider the Client ID as an identifier, then we have the following options concerning the preemption levels: - preemption within a given VPoN (i.e. within VPoN belonging to the same optical network client) - preemption between VPoNs (i.e. between VPoN belonging to the separate optical network client) 5.6 LSP Monitoring TBD. 5.7 LSP Routing Diversity From the optical network viewpoint, LSP routing diversity is related to the path disjointness provided by the constraint-based route computation at the ingress optical LSR. Routing diversity can be related to link, node, path and Shared Risk Link Group (SRLG). Here, we focus on the disjointness of the LSP explicit route with respect to SRLGs. Papadimitriou et al. Expires January 2002 21 draft-papadimitriou-enhanced-lsps-04.txt July 2001 It is commonly admitted [IPO-FRM] that SRLGs identifiers are exchanged between nodes belonging to the same optical domain to prevent the use of shared resources that can affect all links belonging to this group in case of shared resource failure. For instance, as described in [IPO-SRLG], two LSPs flowing through the same fiber link in the same fiber trunk. The SRLG concept has been extended by demonstrating that a given link could belong to more than one SRLG, and two links belonging to a given SRLG may individually belong to two other SRLGs. Many proposals already include the SRLG concept when considering the constraint-based path computation of optical channel routes. In optical domains this concept of SRLG is used for deriving a path, which is disjoint from the physical resource and logical topology point-of-view. However, the definition of SRLG in the current format as described in [GMPLS-OSPF-TE] and [GMPLS-ISIS-TE] does not provide: - the relationship between logical structures or physical resources (for example, a fiber could be part of a sequence of fiber segments, which is included in a given geographical region), and - the risk assessment during path computation implying the allocation of a conditional failure probabilities with the SRLGs - the analysis of the specifications of constraint-based path computation and path re-optimization taking SRLG information into account. The model proposed in [IPO-SRLG] document proposes a technique to compute the SRLG with respect to a given risk type. This is achieved by identifying for a given physical layer the resources belonging to an SRLG. The proposed model also permits to compute the dependencies of these resources into the resources belonging to lower physical layers. The result of the computation also enables OLSR to determine the risk associated to each of the SRLGs. 1. Hierarchical Model The SRLG model defined in [IPO-SRLG] includes two hierarchies: the physical hierarchy and the logical hierarchy. The physical hierarchy is related to the fiber topology (more generally the physical resources) of the optical network including the wavelengths build on top of this physical topology. The network (physical) resource model considered in [IPO-SRLG] is based on concepts introduced in [IPO-FRM]. The concepts around network resource hierarchy developed within this document are based on the following components: - Sub-Channel (TDM circuit û only applicable for SDH/SONET networks) - Optical Channel (or Wavelength) Papadimitriou et al. Expires January 2002 22 draft-papadimitriou-enhanced-lsps-04.txt July 2001 - Fiber Link - Fiber Segment - Fiber Sub-segment - Fiber Trunks The Logical hierarchy is related to the geographical topology of the network. The definition of the logical hierarchical structure covers an increasing extended logical structure partitioning of the area covered by the optical network. For that purposes the concept of node, zone and region are defined in [IPO-SRLG]. 2. Risk Assessment Risk assessment is defined as the evaluation of the potential risk associated to the inclusion of a given resource (this resource belongs to a given resource type located within a given logical structure such as a geographical location). Since the SRLG computation is performed with respect to a given risk type associated to a given network resource, a failure probability is assigned to the network resources instances included within the same logical structure. So, in the approach described in [IPO-SRLG] there is a direct mapping between the risk type and the resource type as well as the failure probability associated to this resource type within a given logical structure. 3. Inference Model The model described in [IPO-SRLG] is provided to automate the discovery of the Shared Risk Link Groups (SRLGs) at a given layer for a given physical resource type. This resource type could be located within a given region and OLSR. Note however, that in the domain service model, when a client OLSR sends an LSP service request it can only reference about the LSPs it has already established. Consequently, it can only reference an LSP M from which the new LSP N should be diverse. The OLSR will interpret this request by considering the Shared Risk Link Group (SRLG) of the LSP M and find a physical route for the LSP N whose SRLG is diverse from. The same process applies at the inter-domain interface where the outgoing OLSR (belonging to the BGP AS[i]) does only knows about the LSPs he has already established to the incoming OLSR (belonging to the BGP AS[j], AS[i] =/= AS[j]). Consequently, the outgoing OLSR can only reference an LSP M from which the new LSP N should be diverse. 6. Connection Service Policy Policy-related parameters are related to directory services provided to the client client LSR through the domain service interface services. These parameters include the following items: - Service-Level parameters Papadimitriou et al. Expires January 2002 23 draft-papadimitriou-enhanced-lsps-04.txt July 2001 - Schedule parameters - Contract parameters - Billing parameters - Optional parameters By receiving such kind of parameters the source boundary OLSR needs to forward the content of these request through the NMI interface (interface between the OLSR and a management server) to a centralized directory service or de-centralized service in combination with a distributed connection admission control. 6.1 Service-level Specification Service level (i.e. service-level specification) parameter could be implemented as a 16-bit integer which refer to parameters detailed in the previous sub-section (service-related parameters). This parameter indicates the class-of-service offered by the optical network carrier. The first 256 values (0 û 255) are reserved for future inter- operability agreements between carriers and service providers. The remaining values are carrier specific. The service-level parameter could include the following attributes: - Optical Signal Quality - Protection parameters - Priority and Preemption - Routing parameters - Signaling security levels For instance, value 0x1x might indicate through a request to a directory service, a best-effort service: - unprotected LSP - default priority - no routing diversity - no signalling authentication Value ranging from 0x2x to 0x7x to might indicate through a request to a directory service, a bronze service: - M:N protected LSP - low-priority - no routing diversity - signalling authentication (no signalling encryption) Value ranging from 0x8x to 0xDx to might indicate through a request to a directory service, a silver service: - M:N protected LSP - medium-priority - no routing diversity - signalling authentication (no signalling encryption) Papadimitriou et al. Expires January 2002 24 draft-papadimitriou-enhanced-lsps-04.txt July 2001 Value 0xEx might indicate through a request to a directory service, a gold service: - 1:1 protected LSP - high-priority - global routing diversity - signalling authentication and encryption The optical signal quality levels need to be defined while a low signal quality does not have to necessarily correspond to a Best- Effort service. Consequently, this means that the client knows the meaning of the service-level prior to the corresponding LSP service request. Within the LSP request, explicit parameter values take precedence over service-level. The definition of the corresponding mechanisms lead us to two options that seems feasible for this purpose: - either the client LSR knows the content of the policy-related parameters without any additional information coming from the optical network - or the client LSR initiates an LSP service request (or even a dedicated request) with appropriate extensions to request the policy-related parameters values to the optical network. So the client learns dynamically the service-level offered by the optical network through a directory service before initiate a LSP create request to the ingress OLSR. In future release of this memo, we will refer to this as Service Discovery Service (SDS) at the domain service interface. 6.2 Scheduling Service Scheduling refers to the possibility to create, delete or modify LSP through a given time-of-day, day-to-day, day-to-week, etc. scheduling plan. For a given plan, the scheduling functions could be start, stop and repeat. The attributes of these scheduling functions could be: - the start/stop time at which the function has to be executed/stopped - the start/stop date at which the function has to be executed/stopped - the recurrence interval between two repeated execution of the function - the number of recurrence intervals The default values of the schedule parameter regarding the LSP requested service: - the start time is the current time (start now) - the start date is the current date (start now) - the recurrence interval is infinite since the LSP request has Papadimitriou et al. Expires January 2002 25 draft-papadimitriou-enhanced-lsps-04.txt July 2001 to be executed only once - the number of recurrence intervals equals zero 6.3 Billing Service The billing parameter refers to the billing client identifier onto which the requested services will be charged. A given client ID could have more than one billing client identifier. An optical network client (identified by a Client ID) could have several clients (i.e. VPN IDs) and assign to each of them a dedicated billing identifier. This parameter is implemented as a 16-bit integer. The first 256 values (from 0 to 255) are reserved for future inter-operability agreements. The remaining values are carrier specific so left with unspecified semantic. 7. Security Considerations By including within the service-level parameter the signalling security level, the proposed document, as detailed in section 6, takes into account the security of the client signalling request in a build-in manner. 8. Acknowledgments The authors would like to thank Bernard Sales, Emmanuel Desmet, Hans De Neve, Fabrice Poppe, Stefan Ansorge and Gert Grammel for their constructive comments and inputs. 9. References 1. [DIFF-DSF] S.Nichols et al., æDefinition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 HeadersÆ, RFC 2474, December 1998. 2. [DIFF-ARCH] S.Blake et al., æAn Architecture for Differentiated ServicesÆ, RFC 2475, December 1998. 3. [G709-FRM] A.Bellato, D.Papadimitriou, et al., æGeneralized MPLS Control Framework for G.709 Optical Transport NetworksÆ, Internet Draft, Work in progress, draft-bellato-ccamp-g709-framework-00.txt, June 2001. 4. [GMPLS-ARCH] E.Mannie et al., æGeneralized MPLS ArchitectureÆ, Internet Draft, Work in progress, draft-ietf-ccamp-gmpls- architecture-00.txt, June 2001. 5. [GMPLS-CRLDP] P.Ashwood-Smith, L.Berger et al., æGeneralized MPLS û Signaling Functional DescriptionÆ, Internet Draft, Work in progress, draft-ietf-mpls-generalized-cr-ldp-03.txt, May 2001. Papadimitriou et al. Expires January 2002 26 draft-papadimitriou-enhanced-lsps-04.txt July 2001 6. [GMPLS-G709] M.Fontana, D.Papadimitriou, et al., æGeneralized MPLS Control for G.709 û Functional DescriptionÆ, Internet Draft, Work in progress, draft-fontana-ccamp-gmpls-g709-00.txt, June 2001. 7. [GMPLS-ISIS-TE] K. Kompella et al., æIS-IS Extensions in Support of MPL(ambda)S,Æ Internet Draft, draft-ietf-isis-gmpls-extensions- 01.txt, March 2001. 8. [GMPLS-OSPF-TE] K. Kompella et al., æOSPF Extensions in Support of MPL(ambda)S,Æ Internet Draft, draft-kompella-ospf-gmpls- extensions-01.txt, February 2001. 9. [GMPLS-RSVP] P.Ashwood-Smith, L.Berger et al., æGeneralized MPLS û Signaling Functional DescriptionÆ, Internet Draft, Work in progress, draft-ietf-mpls-generalized-rsvp-te-03.txt, May 2001. 10. [GMPLS-SIG] P.Ashwood-Smith, L.Berger et al., æGeneralized MPLS - Signaling Functional DescriptionÆ, Internet Draft, Work in progress, draft-ietf-mpls-generalized-signalling-04.txt, March 2001. 11. [GMPLS-SDH] E.Mannie et al., æGeneralized MPLS Extensions for SONET and SDH ControlÆ, Internet Draft, Work in progress, draft-ietf- ccamp-gmpls-sonet-sdh-01.txt, June 2001. 12. [IPO-COS] D.Papadimitriou et al., æOptical Class-of-Services for Lambda LSPÆ, Internet Draft, Work in Progress, draft-papadimitriou- ipo-lambda-lsp-cos-00.txt, July 2001. 13. [IPO-FRM] B.Rajagopalan, J.Luciani et al., æIP Optical Frameworkö, Internet Draft, Work in Progress, draft-many-optical- framework-03.txt, March 2001. 14. [IPO-NLRI] D.Papadimitriou et al., æOptical Non-Linear Routing Impairments in Wavelength Switched Optical NetworksÆ, Internet Draft, Work in progress, draft-papadimitriouùipo-non-linear- impairmnets-00.txt, July 2001. 15. [IPO-OMF] D.Papadimitriou, D.Ooms and J.Jones, æOptical Multicast û A FrameworkÆ, Internet Draft, Work in progress, draft- poj-optical-multicast-01.txt, July 2001. 16. [IPO-RES] J.Hahm, D.Griffith, R.Hartani and D.Papadimitriou, æRestoration Mechanisms and Signalling Extensions in Optical NetworksÆ, Internet Draft, Work in progress, draft-many-optical- restoration-01.txt, July 2001. 17. [IPO-RFR] H.Ghani, P.Bonenfant, D.Papadimitriou and S.Dharanikota, æOptical Architectural Framework for Automatic Protection Provisioning In Dynamic Optical RingsÆ, Internet Draft, Work in progress, draft-ghani-optical-rings-01.txt, March 2001. Papadimitriou et al. Expires January 2002 27 draft-papadimitriou-enhanced-lsps-04.txt July 2001 18. [IPO-SCM] D.Blumenthal et al., æOptical Performance Monitoring in Reconfigurable WDM Optical Networks Using Sub-Carrier MultiplexingÆ, Journal of Lightwave Technology, Volume 18, Number 12, December 2000. 19. [IPO-SRLG] D.Papadimitriou et al., æInference of Shared Risk Link GroupsÆ, Internet Draft, Work in progress, draft-many- inference-srlg-01.txt, July 2001. 20. [IPO-WBS] E.Dotaro et al., æOptical Multi-Granularity û Architectural FrameworkÆ, Internet Draft, Work in progress, draft- dotaro-ipo-multi-granularity-00.txt, July 2001. 21. [RFC-1771] Y.Rekther et al., æA Border Gateway Protocol 4 (BGP- 4)Æ, Internet Standard Track, RFC 1771. 22. [RFC-2685] B.Fox and B.Gleeson, æVPN IdentifiersÆ, Internet Standard Track, RFC 2685. 10. Author's Addresses Dimitri Papadimitriou (Editor) Senior R&D Engineer û Optical Networking Alcatel IPO NSG-NA Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-84-91 Email: Dimitri.Papadimitriou@alcatel.be Jim Jones Alcatel TND-USA 3400 W. Plano Parkway, Plano, TX 75075, USA Phone: +1 972 519-27-44 Email: Jim.D.Jones1@usa.alcatel.com Papadimitriou et al. Expires January 2002 28 draft-papadimitriou-enhanced-lsps-04.txt July 2001 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Papadimitriou et al. Expires January 2002 29