Network Working Group D. Papadimitriou Document: draft-papadimitriou-enhanced-lsps-02.txt J. Jones Category: Internet Draft Alcatel Expiration Date: August 2001 February 2001 Enhanced LSP Services 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 This document describes the LSP parameters and attributes as well as the enhanced services they support. In the scope of the domain service model, the main objective of this proposal is to integrate within these parameters the Optical Multicast concept, the Shared Risk Link Group (SRLG) Inference model, the Virtual Private optical Network (VPoN) model, the Class-of-Priorities and the Class-of- Service (CoS) augmented model; but also enhanced protection and restorations mechanisms (in optical meshed networks) as well as signalling security levels. This draft covers the User-to-Network Interface (UNI) parameters and the specific parameters used within Network-to-Network Interface (NNI) signalling. In order to structure these services, we also propose to group the corresponding parameters in three distinct groups: LSP Identification parameters, LSP Service parameters and Policy parameters. Papadimitriou et al. Expires August 2001 1 draft-papadimitriou-enhanced-lsps-02.txt February 2001 1. Introduction Current IP protocols extensions for services (Integrated or Differentiated), for traffic-engineering (Multi-Protocol Label Switching), for privacy (Virtual Private Networks), for multicast applications (IP Multicast protocols) and for security (IPSec Protocol) results 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 proposal is to include within the LSP parameters used within signalling and routing protocols the Virtual Private optical Network (VPoN) model, the Class-of-Priorities (CoP) and the Class-of-Service (CoS) augmented model and the optical multicast trees. Enhancement considered in this document cover also the protection/restoration and fault-tolerance mechanisms as well as signalling security levels. In order to structure the integration of these features within the signalling and routing protocols, we propose a classification separating the parameters distributed within an optical sub-network (Identification and Service parameters) from the one centralized on directory service (Policy-related parameters). 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 which could in turn increase the setup time of a LSP. The remainder of the document is organized as follows: Sections 2 û 4 describe the details of the attributes for Identification, Service and Policy groups, respectively. Section 5 describes result and status codes. Annex 1 defines the terminology used in the contribution. Note that from the previous version of this memo, we remove the parameter values already defined in other IETF drafts, in particular [GMPLS-RSVPTE] and [GMPLS-CRLDP]. 2. Identification parameters The following identification-related parameters are considered. 2.1 Connection termination-point identification parameters Papadimitriou et al. Expires August 2001 2 draft-papadimitriou-enhanced-lsps-02.txt February 2001 Within the scope of the Domain Service model, the concepts developed within this section are also related to the address registration and allocation mechanisms. 2.1.1 Parameters definition The following identification parameters are related to the physical- level interfaces of an Optical Network Element (ONE): - Port ID: integer indicating and identifying a port within an Optical Network Element (ONE) - Channel ID: integer indicating and identifying a channel within a given port ID - Sub-Channel ID: integer indicating a sub-channel within a given Channel ID - Logical-port ID: identifies a logical port; concatenation of the port-ID, the Channel-ID and the Sub-channel-ID. The Logical-port ID is not used anymore in [OIF2000.125.3], however the concept to which it refers is still valid and might be useful for next developments. Two types of addresses have been defined the Client Optical Network Administered Address (ONA Address) and the Optical Network Element (ONE) Address. Currently, their values are defined as IPv4 addresses. For more details about the related concepts (address registration and allocation mechanisms) we refer to [OIF2001.119] and [OIF2001.121]. 2.2 Optical network identification parameters - The Carrier ID (CID) is an integer defining the identity of the carrier to which the ONE element belongs. - The Privacy ID (PrID) determines whether a UNI or a NNI interface is untrusted (i.e. public) or trusted (i.e. private). Hence, from this point-of-view, we consider four types of interfaces: trusted UNI, untrusted UNI, trusted NNI and untrusted NNI interfaces. These identifiers are provisioned by the administrative authority of the optical network and are exchanged during the neighbor identity discovery process as described in [IPO-ONNI]. The Carrier ID uniquely determines the owner of a signalling message when travelling over inter-domain NNI signalling channels between optical networks. Papadimitriou et al. Expires August 2001 3 draft-papadimitriou-enhanced-lsps-02.txt February 2001 The Privacy ID makes the distinction between trusted and untrusted NNI interfaces. Generally, there is a trust relationship between intra-domain NNI interfaces and an untrusted relationship between inter-domain NNI interfaces. 2.3 Client identification parameters 2.3.1 Parameters definition The client identification parameters include the Client Identifier (Client ID) and the VPN Identifier (VPN ID). - Client ID: 32-bit integer (provided by the client) which uniquely identifies a client (i.e. a group of client CNE belonging to the same administrative authority) against the optical network domain. This parameter should not have any complex semantic nor meaning and could be useful when considering optical broadcast and multicast applications. Note that the client identifier is not equivalent to the Contract ID parameter defined in [OIF2000.61.6] and [IPO-UNIR]. In this proposal, the Contract ID parameter is defined in section 4.3. - VPN ID: 7-bytes field structure based on the VPN identifiers as defined in [VPN-ID] The source and destination ONE 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 CNE to accept the LSP create request if the destination CNE is part of the signaled and authenticated VPN. Since a boundary ONE can potentially be connected to multiple client CNEs, or a given client CNE can potentially request LSP for different VPNs, this identifier defines the possibility to setup Virtual Private optical Networks (VPoN). The corresponding models are described in the next section. 2.3.2 VPoN Models The VPoN - Virtual Private optical Network models 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) Papadimitriou et al. Expires August 2001 4 draft-papadimitriou-enhanced-lsps-02.txt February 2001 The first model considers the Client-ID as a potential VPoN identifier in addition to the VPN ID and the second one considers only the VPN ID as a VPoN identifier. If we consider the Client-ID as a potential 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 potential 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. 2.3.3 VPoN and Address Space Uniqueness If we consider one unique address space per optical network, this 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 [RFC2547], 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 also that [RFC2547] 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 second case is most flexible since it permits to connect client having overlapping address spaces. However, this also requires for the optical network to maintain one mapping table per Client ID. Papadimitriou et al. Expires August 2001 5 draft-papadimitriou-enhanced-lsps-02.txt February 2001 2.4 LSP identification parameters The LSP Identifier (LSP ID) is the unique identifier of the LSP assigned by the optical network. The LSP ID is coded as a 64-bit field obtained from the concatenation of two fields uniquely identifying the LSP within an optical network: - IPv4 address of the source ONE considered as an unique IP address inside a given optical network - An integer assigned by the source ONE that is locally unique within a given ONE LSP ID is assigned by the source ONE in response to a LSP create request. Within the LSP create message (sent by the client CNE), the UNSPECIFIED value is assigned to the LSP ID. However, an additional distinction could be suitable when considering untrusted interfaces. In this case, the Carrier ID replaces the IPv4 address in order to hide the ONE identifier (ONE IPv4 address) from the client network. LSP ID reserved values could be defined as follows: - UNSPECIFIED value: 0x0...0 referring to a not-specified LSP ID - ALL value: 0xF...F referring to all the LSP IDs 3. Services parameters Concerning the LSP services, the basic LSP services, the LSP protection and LSP routing parameters are considered. 3.1 LSP services parameters The parameters considered within this sub-section, offers the possibility to implement the enhanced services proposed as main objective of this proposal. 3.1.1 Framing-Bandwidth The Framing-Bandwidth parameter is defined as an integer specifying the format and the associated bandwidth of the signal transported across the UNI and represents the framing and bandwidth of the service requested through the optical network. The Framing-type (or LSP Encoding Type [GMPLS-SIG]) possible values are defined as follows: - Sonet - SDH - Ethernet - Digital Wrapper - Clear Channels Papadimitriou et al. Expires August 2001 6 draft-papadimitriou-enhanced-lsps-02.txt February 2001 The Bandwidth possible values are defined with respect to the Framing-type where the SONET/SDH framing includes the overhead termination types: - SONET Framing: Possible values are OC- where N = 1 (OC-1) to 3072 (OC-3072) Or encoded as explicit discrete values VT1.5, VT2, VT3, VT6, OC-1, OC-3c, OC-12c, OC-48c, OC-192c, OC-48 Line, OC-48 Section, OC-192 Line, OC-192 Section. - SDH Framing: Possible values are coded as STM- where N = 1 (STM-1) to N=1024 (STM-1024) Or encoded as explicit discrete values VC-11, VC-12, VC-2, VC-3, VC-4, VC-4-4c, VC-4-16c, VC-4-64c, MS-16, MS-64, RS-16, RS-64 - Ethernet Framing: Possible values are 10Mbps, 100Mbps, 1 Gbps and 10 Gbps - Digital Wrapper: Possible values are 2.5 Gbps, 10 Gbps and 40 Gbps Note: Digital Wrapper refers to Standard Digital Wrapper layer as proposed by the ITU-T G.709 v0.83 recommendation which has been integrated within GMPLS Signalling in [GMPLS-G709]. - Clear Channels (Photonic channels): possible values are OC- where N = 0x001 (OC-1) to N = 0xC00 (OC-3072) 3.1.2 SDH/Sonet Connection Service The SDH/Sonet parameter applies only to SDH/Sonet framing (i.e. LSP Encoding Type). This parameter includes the Transparency levels and the Concatenation types. Transparency value could take one of the following values: - No transparency - Default-value - Regeneration section/Section OH (RSOH/SOH) bytes Transparency - RSOH/SOH and Multiplex Section/Line OH (MSOH/LOH) Transparency - Specific OH bytes Transparency such as J0, K1/K2, etc. In PLR-Circuits, all SDH/Sonet overhead bytes are left unchanged when transported between clients over the optical network. STE- Circuits preserves all SDH/Sonet Line overhead bytes between clients but the section overhead bytes are not required to be preserved. LTE-Circuits preserves the SDH/Sonet payload but the Section and Line overhead bytes are required to be preserved. However, as proposed here above, a finest granularity (per overhead byte and on- demand) transparency should be defined in order to cover the current equipment needs. Papadimitriou et al. Expires August 2001 7 draft-papadimitriou-enhanced-lsps-02.txt February 2001 Concatenation could take one of the following values: - Default-value (no concatenation) - Virtual Concatenation - Standard Contiguous Concatenation - Arbitrary Contiguous Concatenation More details concerning the emulated Transparency and Concatenation could be found in [GMPLS-SDH], [GMPLS-G709] and [GMPLS-SIG]. 3.1.3 All-Optical Connection Service The optical parameter is related to all-optical network. Since SDH/Sonet framing is currently the key consideration, this parameter should be not included within the LSP service requests (even optionally). This parameter is divided in two parts; both defines the maximum admitted value for an optical signal technology-related parameter: - Bit Error Rate: integer defining the exponent of the maximum BER admitted for a given optical signal (default value is zero) - Jitter: integer defining the maximum jitter admitted for a given optical signal (default value is zero) also referred to as jitter tolerance As currently defined in optical transport systems, there are 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 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 - Propagation Delay: integer specifying an upper limit for the maximum acceptable propagation delay (units in microseconds) acceptable for the optical signal. The default value of the Propagation Delay is infinite. The Propagation Delay parameter can be used as an additive metric (or additive weighted metric) for constraint-based path computation. Other optical physical-level parameters can be defined as OSNR and PMD. Up to now, the need of optical parameter during the lightpath creation process is not needed but future packet-over-wavelength switched networks might rapidly evolve such that this parameter becomes mandatory. 3.1.4 Connection Directionality and Multicast Service The directionality parameter is an integer indicating the directionality of the LSP. If this optional parameter is omitted, Papadimitriou et al. Expires August 2001 8 draft-papadimitriou-enhanced-lsps-02.txt February 2001 the LSP is assumed to be bi-directional. However, as described in [GMPLS-SIG], bi-directionality of an LSP is implicitly defined by the use of a suggested label within the LSP create request. Possible values are: - unidirectional - bi-directional (default value) - multi-directional (optical multicast) Multi-directionality concept is related to point-to-multipoint LSPs established throughout the optical network. In this case, one source could have many destinations. Optical multicast is detailed in [IPO- MULT] as well as the related signalling considerations. - Multicast Service û As described in [IPO-MULT], the optical multicast concept can be applied to numerous client- layer applications covering Optical Storage Area Networks (O-SAN), Optical Broadband Multimedia (for instance, video and HDTV), etc. Optical multicast offers advantages in the following critical aspects of all-optical networks: - Efficient optical (1+1) all-optical protection - Improved performance (no store and forward) compared to packet- oriented multicast technology - Reduction of the total number of transceivers in the all-optical network. - Overall network throughput improvement by reducing the number of wavelengths used per fiber link (i.e. minimizing the overall bandwidth usage per fiber link) 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 (described by the Steiner Tree Problem and applied to communication networks) is NP-Complete. [IPO-MULT] also describes the diverse possibilities that can be used to extend the currently defined (or under-definition) multicast signalling protocols. 3.1.5 Priority-Preemption and CoS Augmented Model The priority-preemption is an optional parameter defined as a 16-bit integer including the setup priority (8-bit integer field) and the hold priority (8-bit integer field) and preemption level (8-bit integer field) of an LSP. 1. Priority The Priority specification (as described in [MPLS-CRLDP]) includes Papadimitriou et al. Expires August 2001 9 draft-papadimitriou-enhanced-lsps-02.txt February 2001 the setup and the recovery priority. The corresponding encoding is defined as a 8-bit integer indicating the priority of the LSP: - 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 (8 LS bits) within a given priority-class ranges from 0xEE (higher priority) to 0x11 (lower priority). 2. Preemption Preemption is a 4-bit integer indicating the preemptability of an LSP. This parameter specifies whether a given LSP can be preempted by a LSP of higher priority if the resource used by the lower- priority LSP need to be used during the setup and/or the recovery of this higher priority LSP. The possible values for the preemption (4 MS bits û 4 LS bits are reserved for future use) are: - Setup and Recovery preemptability: 0x00 (Class 1) - Recovery preemptability : 0x10 (Class 2 to 7) - Setup preemptability : 0x20 (Class 8 to D) - No_preemptability : 0x30 (Class E) 3. CoS Augmented Model The CoS augmented model, described in [IPO-COS] and based on [DIFF- ARCH] specification, is build upon the following principle: at the boundary CNE, 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 Papadimitriou et al. Expires August 2001 10 draft-papadimitriou-enhanced-lsps-02.txt February 2001 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 UNI during the LSP creation. In this case, the priority value setting is performed through the following rules: - Class 1 defines a priority ranging from 0x110 to 0x1EF - Class 2 to 7 defines a priority ranging from 0x210 to 0x7EF - Class 8 to D defines a priority ranging from 0x810 to 0xDEF - Class E defines a priority ranging from 0xE10 to 0xEEF Application of this model will enable to have a selection mechanism at the boundary CNE (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 service class within the optical network. This technique enables the direct mapping of finer granularity Packet-based LSP to coarser granularity Lambda-switched LSPs without any disruption in the end-to-end QoS offered to the client layer networks. 4. VPoN Model The relationship between the Priority/Preemption and the CoS and VPoN model is based on the resource isolation concept described in section 2.3. Two VPoN models have been defined (using the Client ID or not, respectively), 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 a potential 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 a potential 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) 3.1.6 Bundles The corresponding encoding and semantic is left for further study. Note the concept has been considered in [IPO-BUNDLE] and [GMPLS- BUNDLE]. 3.2 LSP protection parameters Papadimitriou et al. Expires August 2001 11 draft-papadimitriou-enhanced-lsps-02.txt February 2001 Protection parameter indicates the protection level desired for the LSP inside to the optical network (internal protection) or at the UNI (source- and destination-side protection levels) which the protection level requested between both side of the client-to- network connection. This optional parameter indicates the location (i.e. the scope) of the protection requested by the client device: - the optical network: internal network protection - the source drop-side: source-side protection - the destination drop-side: destination-side protection - no protection (default-value) For each of these protection types, the protection levels (8-bit integer) defined are the following: - Internal Protection (or Network path-level protection): . Unprotected (default value) . Dedicated 1+1 Protection . Dedicated 1:1 Protection . Shared Protection M:N (particular case 1:N) . Enhanced Protection (ring-based protection) . Restoration (path-level re-routing) - Source-Side Protection (protection between CNE and ONE on source side): . Unprotected (default value) . Dedicated 1+1 Protection . Dedicated 1:1 Protection . Shared Protection M:N (particular case 1:N) . Enhanced Protection (ring-based protection) - Destination-Side Protection (protection of between CNE and ONE on destination side): . Unprotected (default value) . Dedicated 1+1 Protection . Dedicated 1:1 Protection . Shared Protection M:N (particular case 1:N) . 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 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. Papadimitriou et al. Expires August 2001 12 draft-papadimitriou-enhanced-lsps-02.txt February 2001 3.3 LSP routing parameters LSP routing parameters are from one side related to the path disjointness during the CSPF route computation and from the other side related to constraint-based routing (explicit and record route concepts). 3.3.1 Routing Diversity The routing diversity service is based on the Shared Risk Link Group (SRLG) concept. It is commonly admitted [IPO-FRAME] and [IPO-BUNDLE] 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. [IPO-BUNDLE] extends the SRLGs concept 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] and [GMPLS-ISIS] 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 one 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 Papadimitriou et al. Expires August 2001 13 draft-papadimitriou-enhanced-lsps-02.txt February 2001 concepts introduced in [IPO-FRAME]. 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) - Channel (or Wavelength) - 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 zone. Note however, that in the domain service model, when a client ONE 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 ONE 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 NNI interface where the outgoing ONE (belonging to the BGP AS i) does only knows about the LSPs he has already established to the incoming ONE (belonging to the BGP AS j). Consequently, the outgoing ONE can only reference a LSP M from which the new LSP N should be diverse. 3.3.2 Explicit Route Papadimitriou et al. Expires August 2001 14 draft-papadimitriou-enhanced-lsps-02.txt February 2001 Explicit route parameter applies only at the NNI. However, this parameter could be used at the UNI within the scope of the Domain Specific Routing model. The semantic of the explicit route parameter for optical networks is detailed in [IPO-ONNI]. 3.3.3 Record Route Record route parameter applies only at the NNI. However, this parameter could also be used at the UNI within the scope of the Domain Specific Routing model. The semantic of the record route parameter for optical networks is detailed in [IPO-ONNI]. 4. Policy parameters Policy-related parameters are related to directory services provided to the client CNE through the UNI services. These parameters include the following items: - Service-Level parameters - Schedule parameters - Contract parameters - Billing parameters - Optional parameters By receiving such kind of parameters the source boundary ONE needs to forward the content of these request through the NMI interface (interface between the ONE and a management server) to a centralized directory service or de-centralized service in combination with a distributed connection admission control. 4.1 Service-level parameters 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: - Priority and Preemption - Propagation Delay - Protection parameters - Routing parameters - Signaling security levels For instance, value 0x1xxx might indicate through a request to a directory service, a best-effort service: - unprotected LSP Papadimitriou et al. Expires August 2001 15 draft-papadimitriou-enhanced-lsps-02.txt February 2001 - default priority - infinite propagation delay - no routing diversity - no signalling authentication Value ranging from 0x2xxx to 0x7xxx to might indicate through a request to a directory service, a bronze service: - M:N protected LSP - low-priority - infinite propagation delay - no routing diversity - signalling authentication (no signalling encryption) Value ranging from 0x8xxx to 0xDxxx to might indicate through a request to a directory service, a silver service: - M:N protected LSP - medium-priority - infinite propagation delay - no routing diversity - signalling authentication (no signalling encryption) Value 0xExxx might indicate through a request to a directory service, a gold service: - 1:1 protected LSP - high-priority - finite propagation delay - global routing diversity - signalling authentication and encryption 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. 4.2 Schedule parameters 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 the scheduling function 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 Papadimitriou et al. Expires August 2001 16 draft-papadimitriou-enhanced-lsps-02.txt February 2001 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 to be executed only once - the number of recurrence intervals equals zero 4.3 Contract parameters The contract parameter is defined as an identifier (Contract ID) whose value corresponds to a string defined in [OIF2000.61.5]. The semantic proposed for this parameter refers to the policy parameters defined in this section. Note that a given Client ID could have more than one Contract ID. 4.4 Billing parameters 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 (a Client ID) may 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 (0 û 255) are reserved for future inter-operability agreements. The remaining values are carrier specific. 4.5 Optional parameters Optional parameters could include Vendor-specific parameters, etc. The definition of the corresponding mechanisms lead us to two options that seems feasible for this purpose: - either the client CNE knows the content of the policy-related parameters without any additional information coming from the optical network - or the client CNE 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 ONE. In future release of this memo, we will refer to this as service discovery service (SDS) at the UNI. 5. Security Considerations By including within the service-level parameter the signalling Papadimitriou et al. Expires August 2001 17 draft-papadimitriou-enhanced-lsps-02.txt February 2001 security level, the proposed document, as detailed in section 4, takes into account the security of the client signalling request in a build-in manner. 6. 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. 7. 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. [GMPLS-SIG] P.Ashwood-Smith et al., æGeneralized MPLS - Signaling Functional DescriptionÆ, Internet Draft, draft-ietf-mpls- generalized-signalling-01.txt, November 2000. 4. [GMPLS-CRLDP] P.Ashwood-Smith et al., æGeneralized MPLS û Signaling Functional DescriptionÆ, Internet Draft, draft-ietf- mpls-generalized-rsvp-te-00.txt, November 2000. 5. [GMPLS-G709] M.Fontana and D.Papadimitriou, æGeneralized MPLS Control for G.709 û Functional DescriptionÆ, Internet Draft, draft-fontana-gmpls-control-g709-00.txt, February 2001. 6. [GMPLS-RSVPTE] P.Ashwood-Smith et al., æGeneralized MPLS û Signaling Functional DescriptionÆ, Internet Draft, draft-ietf- mpls-generalized-cr-ldp-00.txt, November 2000. 7. [IPO-COS] D.Papadimitriou et al., æOptical Class-of-Services û An Augmented ApproachÆ, Work in Progress, draft-papadimitriou-ipo- cos-00.txt, February 2001. 8. [IPO-MULT] D.Papadimitriou, D.Ooms and J.Jones, æOptical Multicast û A FrameworkÆ, Internet Draft, draft-poj-optical- multicast-00.txt, February 2001. 9. [IPO-ONNI] D.Papadimitriou et al., æOptical NNI Framework and Signaling RequirementsÆ, Internet Draft, draft-papadimitriou- onni-frame-02.txt, February 2001. 10.[IPO-OPM] D.Papadimitriou et al., æOptical Signal Performance Measurement,Æ Work in progress, draft-papadimitriou-optical-opm- 00.txt, February 2001. 11.[IPO-OUNI] B.Rajagopalan et al., æSignaling Requirements at Papadimitriou et al. Expires August 2001 18 draft-papadimitriou-enhanced-lsps-02.txt February 2001 the Optical UNIÆ, Internet Draft, draft-bala-mpls-optical-uni- signalling-01.txt, November 2000. 12.[IPO-SRLG] D.Papadimitriou et al., æInference of SRLGsÆ, Internet Draft, draft-many-inference-srlg-00.txt, February 2001. 13.[IPO-TEIP] O.Duroyon et al., æLSP Service Model framework in an Optical G-MPLS networkÆ, Internet Draft, draft-duroyon-te-ip- optical-01.txt, November 2000. 14.[OIF2000.125.3] B.Rajagopalan et al., æUser Network Interface (UNI) 1.0 ProposalÆ, OIF Contribution, December 2000. 15.[OIF2000.061.6] J.Yates et al., æUser to Network Interface (UNI) Service Definition and Lightpath AttributesÆ, OIF Contribution 61, December 2000. 16.[OIF2000.188] R.Barry, æLightpath Attributes ProposalÆ, OIF Contribution 188, August 2000. 17.[OIF2000.197] J.Heiles, æAlignment of the UNI with ITU-T TerminologyÆ, OIF Contribution 197, September 2000. 18.[OIF2001.119] D.Pendarakis et al., æUNI Addressing: Overview of Areas of Concern, Comments, and ProposalsÆ, OIF Contribution 119, January 2001 19.[OIF2001.121] D.Pendarakis, æUNI addressing sub-group break-out meeting recommendations 20.[VPN-ID] B.Fox and B.Gleeson, æVPN IdentifiersÆ, Internet RFC 2685. 8. Author's Addresses Dimitri Papadimitriou Alcatel IPO-NSG 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 Appendix 1: Terminology Papadimitriou et al. Expires August 2001 19 draft-papadimitriou-enhanced-lsps-02.txt February 2001 The following terms are used in this document. These definitions take into account the terminology already defined by the IETF for some of the concepts defined here and some are adapted from the OIF Forum terminology. - Optical Network: a collection of optical sub-networks constituted by optical network elements - Optical Network Element (ONE): a network element belonging to the optical network. An optical network device could be an Optical Cross-Connect (OXC), Optical ADM (OADM), etc. - Boundary ONE: an optical network element (ONE) belonging to the optical network and including an UNI-N interface. - Internal ONE: an optical network element internal to the optical network (also referred as a termination incapable device) which does not include a UNI-N interface. - Client Network Element (CNE): a network element belonging to the client network. A client network element could be a SONET/SDH ADM, a SONET/SDH Cross-connect, an ATM Switch, an Ethernet switch, an IP router, etc. - Label Switched Path (LSP): point-to-point optical layer connectivity with specified attributes (mandatory and optional) established between two ONE termination-points in the optical network. LSPs are considered as bi-directional (and in a first phase as symmetric). A LSP could be a Fiber Switched path, Lambda Switched path or TDM Switched path (Circuit). - UNI Client (UNI-C): signalling and routing interface between a Boundary CNE and a boundary ONE belonging to an optical network. - UNI Network (UNI-N): signalling and routing interface between a Boundary ONE and a boundary CNE belonging to a client network. - UNI Services: the services defined at the UNI are the following: - Neighbor discovery service - Service discovery service - LSP signalling services (create/delete/modify/status) - NMI interface: the interface between the ONE controller and the centralized management server. Papadimitriou et al. Expires August 2001 20 draft-papadimitriou-enhanced-lsps-02.txt February 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. Papadimitriou et al. Expires August 2001 21