idnits 2.17.1 draft-papadimitriou-enhanced-lsps-04.txt: -(56): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(487): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(907): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1368): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1373): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1374): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1385): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1386): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1389): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1390): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1394): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1397): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1411): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 55 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 7) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([IPO-FRM]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == Unrecognized Status in 'Category: Internet Draft', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2001) is 8321 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 35 == Missing Reference: 'ITUT-G872' is mentioned on line 93, but not defined == Missing Reference: 'ITUT-G709' is mentioned on line 739, but not defined == Missing Reference: 'MPLS-LMP' is mentioned on line 291, but not defined == Missing Reference: 'MPLS-RSVP' is mentioned on line 298, but not defined == Missing Reference: 'MPLS-LDP' is mentioned on line 298, but not defined == Missing Reference: 'IPO-RTG' is mentioned on line 423, but not defined == Missing Reference: 'GSMPL-SDH' is mentioned on line 619, but not defined == Missing Reference: 'IPO-ORI' is mentioned on line 819, but not defined == Missing Reference: 'IEEE-ORL' is mentioned on line 825, but not defined == Missing Reference: 'MPLS-CRLDP' is mentioned on line 994, but not defined == Missing Reference: 'DIFF-PHB' is mentioned on line 1030, but not defined == Unused Reference: 'GMPLS-SDH' is defined on line 1393, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. 'DIFF-ARCH') == Outdated reference: A later version (-01) exists of draft-bellato-ccamp-g709-framework-00 -- Possible downref: Normative reference to a draft: ref. 'G709-FRM' == Outdated reference: A later version (-07) exists of draft-ietf-ccamp-gmpls-architecture-00 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-generalized-cr-ldp-03 == Outdated reference: A later version (-03) exists of draft-fontana-ccamp-gmpls-g709-00 -- Possible downref: Normative reference to a draft: ref. 'GMPLS-G709' == Outdated reference: A later version (-19) exists of draft-ietf-isis-gmpls-extensions-01 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-gmpls-extensions (ref. 'GMPLS-ISIS-TE') == Outdated reference: A later version (-02) exists of draft-kompella-ospf-gmpls-extensions-01 -- Possible downref: Normative reference to a draft: ref. 'GMPLS-OSPF-TE' == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-rsvp-te-03 -- No information found for draft-ietf-mpls-generalized-signalling - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'GMPLS-SIG' == Outdated reference: A later version (-08) exists of draft-ietf-ccamp-gmpls-sonet-sdh-01 -- No information found for draft-papadimitriou-ipo-lambda-lsp-cos - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IPO-COS' -- No information found for draft-many-optical-framework - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IPO-FRM' -- No information found for draft-papadimitriou - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IPO-NLRI' == Outdated reference: A later version (-02) exists of draft-poj-optical-multicast-01 -- Possible downref: Normative reference to a draft: ref. 'IPO-OMF' -- Possible downref: Normative reference to a draft: ref. 'IPO-RES' -- Possible downref: Normative reference to a draft: ref. 'IPO-RFR' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPO-SCM' == Outdated reference: A later version (-02) exists of draft-many-inference-srlg-01 -- Possible downref: Normative reference to a draft: ref. 'IPO-SRLG' == Outdated reference: A later version (-01) exists of draft-dotaro-ipo-multi-granularity-00 -- Possible downref: Normative reference to a draft: ref. 'IPO-WBS' ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) Summary: 10 errors (**), 0 flaws (~~), 27 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Papadimitriou 3 Document: draft-papadimitriou-enhanced-lsps-04.txt J. Jones 4 Category: Internet Draft Alcatel 5 Expiration Date: January 2002 6 July 2001 8 Enhanced LSP Services in Optical Networks 10 draft-papadimitriou-enhanced-lsps-04.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. Internet-Drafts are draft documents valid for a maximum of 21 six months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Conventions used in this document: 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC-2119 [1]. 36 Abstract 38 In the scope of the domain service model as defined in [IPO-FRM], 39 the main objective of this document is to integrate within the set 40 of services covered by this model Virtual Private optical Networks 41 (VPoN), Connection Survivability by using the Shared Risk Link Group 42 (SRLG) inference model, Class-of-Priorities and Class-of-Service 43 (CoS) as well as Waveband and Optical Multicast connection services. 45 Papadimitriou et al. Expires January 2002 1 46 1. Introduction 48 Current IP protocols extensions for Integrated or Differentiated 49 services, for Traffic-Engineering (Multi-Protocol Label Switching), 50 for privacy (Virtual Private Networks), for multicast applications 51 (IP Multicast protocols) and for security (IPSec Protocol) result 52 from the short-term perspective when the IP protocol was defined at 53 the beginning of the eighties. Now, the current developments on 54 optical networking are challenging the same problem: if these 55 features are not included from the beginning within the signalling 56 and routing protocols used in optical networking, future needs won�t 57 be covered by the current developments. 59 The main objective of this memo is to include within the LSP 60 connection services provided currently when using GMPLS-based 61 signalling and routing protocols, the following connections 62 services: the Virtual Private optical Network (VPoN), the Class-of- 63 Service (CoS), Waveband and Optical Multicast connection services. 64 Such services are really the ones (additional services can be 65 defined in the future) that will provide added value comparing to 66 the current situation in traditional optical networks. 68 In order to structure the integration of these services within the 69 signalling and routing protocols, we propose to separate the types 70 of information enabling the optical network to provide these 71 services. For an optical network controlled through a distributed 72 IP-based control plane optical sub-network we suggest here to 73 differentiate the identification and connection service information 74 available on each Optical LSR (OLSR) from the centralized 75 information (for instance, related to the network policy) available 76 through directory services. This means that we consider for 77 scalability, convergence and performance reasons that keeping all 78 the policy-related parameters would result in an overflow of 79 information to be distributed throughout the optical network giving 80 rise to an increasing convergence time of the optical network 81 routing database. 83 2. Optical Networks Foundation 85 This section briefly describes two examples of widely used optical 86 technologies that can provide enhanced LSP Services through the use 87 of an IP-based distributed control plane (such as the one defined by 88 the Generalized MPLS protocol suite) with a Domain Service Model. 89 The latter in described in section 2.2. 91 2.1 Transport Technologies for Optical Networking 93 The Optical Transport Network (OTN) defined in G.872 [ITUT-G872] and 94 G.709 [ITUT-G709] enables optical transmission of various client 95 signal types through the use of Forward Error Correction (FEC) 96 bytes. ITU-T G.872 defines a functional architecture for an optical 98 Papadimitriou et al. Expires January 2002 2 99 transport network that supports the transport of digital client 100 signals. ITU-T G.709 recommendation specifies the data plane 101 transport structure and allocates overhead bytes for the OTN control 102 plane. It defines the digital path structure to be transported into 103 optical channels. 105 In the below sub-sections section, we describe shortly the G.709 106 Digital and Optical Transport Hierarchies (OTH) defined at the ITU- 107 T. This by taking into account that today the most widely deployed 108 legacy transmission networks (in particular in Wide Area Networks - 109 WAN) are based on SDH and SONET. More details on OTN and Pre-OTN 110 developments can be found in [G709-FRM]. 112 2.1.1 Pre-OTN DWDM Development 114 ITU-T G.709 describes pre-OTN development (also referred to as DWDM 115 development) for backward compatibility with the current DWDM system 116 deployment. Pre-OTN DWDM systems (which were not defined at the ITU 117 prior to the G.709 recommendation) have been developed during the 118 last years in order to overcome the bandwidth limitations and 119 increase the bit-rate per fiber until several Tbps per fiber. In the 120 future, pre-OTN DWDM systems will provide up to hundred of 121 wavelengths per fiber. 123 These developments include the definition of point-to-point DWDM 124 optical channels on top of a mesh optical topology including Optical 125 Cross-Connects (OXC) or Photonic Cross-Connects (PXC). A PXC is 126 defined as an all-optical device (i.e. no O/E/O interface 127 conversion) so that 1R optical amplification can be provided by such 128 interfaces. Conversely, an OXC is defined as a non-transparent 129 device providing O/E/O conversion at each interface (also referred 130 to as 3R for Reamplification, Reshaping and Retiming) such devices 131 are capable to switch a whole STM-N/OC-N signal or MSn/STS-N signal. 132 Thus the Regenerator Section or the Multiplex Section is 133 respectively terminated (at least for certain overhead bytes) by the 134 switch interfaces. This means that such devices don�t provide the 135 so-called VC-4/STS-1 SPE re-grooming capability. On the contrary, an 136 Opaque OXC is defined in the scope of this document as a VC-4/STS-1 137 SPE SDH/Sonet cross-connect, which is therefore strictly equivalent 138 to a DXC with optical transceivers on its line interfaces. 140 The current bandwidth bottleneck is overcome by the use of DWDM 141 systems. Today, DWDM systems allow the multiplexing of more than 160 142 wavelengths of 10 Gbps (1.6 Tbps per fiber with a 25 GHz spacing) 143 using the C-band and the L-band. Recent optical technology 144 improvements enable channel spacing of 12.5 GHz for 2.5 Gbps 145 signals. Consequently, it will be possible to house 320 wavelengths 146 of 2.5 Gbps in a single fiber. A complementary method for increasing 147 the effective capacity of a DWDM system is to include the 1480nm 148 (Short Band) and 1650nm (Ultra-Long Band) bands by providing fibers 149 covering ultra-wide optical bands from 1460 to 1675nm. 151 Papadimitriou et al. Expires January 2002 3 152 In the pre-OTN application, client signals are either directly 153 mapped on the wavelength (i.e. optical channel) or mapped through by 154 using an intermediate mapping-framing variable-length layer also 155 referred to as a digital wrapper layer. The former direct mapping is 156 defined for STM-N/OC-N (and Gigabit Ethernet) client signal while 157 the latter is mainly used for packet client layers such as IP and 158 ATM. This means that such developments do not include G.709 client- 159 signal mapping specification through the definition of a dedicated 160 framing procedure. Moreover, additional standard Transparency levels 161 to the one defined for SONET/SDH networks can be specified for Pre- 162 OTN networks. 164 2.1.2 Optical Transport Networks (OTN) 166 Optical networks comprise a set of functionality providing 167 transport, multiplexing, routing, supervision and survivability of 168 client signals that are processed predominantly in the optical 169 domain. Optical signals are characterized by wavelength and may be 170 processed per wavelength or as a wavelength division multiplexed 171 group of wavelengths. 173 The OTN model is decomposed into independent (transport) network 174 layers where each layer can be separately partitioned in a way that 175 reflects its internal structure. Thus, the OTN model refers to a 176 layered structure comprising a Digital and an Optical Transport 177 Hierarchy (OTH). 179 The development of a digital and an optical transport hierarchy 180 (i.e. networking layer) is required for the following reasons: 181 - It is the next step (after TDM - SDH/SONET) to support ever 182 growing data driven needs for bandwidth and emergence of new 183 broadband services 184 - To support next generation Terabit/second per fiber via DWDM lines 185 at the transport level as well as optical channels at 2.5 Gbps, 10 186 Gbps and 40 Gbps bit rates at wire speed level (and in the future 187 160 Gbps currently under definition) 188 - To provide network operational management, planning, 189 administration, survivability, and finally cost of maintenance 190 limited only to the OTUk/ODUk rates of transmission without caring 191 about the granularity of the client signal. 193 In the optical domain, the following network layers are currently 194 defined, they constitute the Optical Transport Hierarchy: 195 - Optical Transmission Section (OTS) layer: This network layer 196 provides functionality for transmission of optical signals on 197 optical media of various types. This layer ensures the integrity 198 and maintenance of the optical transmitted signal by overhead 199 processing. 200 - Optical Multiplex Section (OMS) layer: This network layer provides 201 functionality for networking of a multi-wavelength optical signal. 202 A "multi-wavelength" signal includes the case of just one optical 203 channel. This layer ensures the integrity and maintenance of the 205 Papadimitriou et al. Expires January 2002 4 206 multi-wavelength signal by overhead processing. 207 - Optical Channel (OCh) layer: this network layer provides end-to- 208 end networking of optical channels for transparently conveying 209 client information of various formats (e.g. SDH STM-N, Sonet OC-N, 210 ATM, IP, etc.). The capabilities of this network layer concern 211 connection re-arrangement for flexible routing, overhead 212 processing, administration and maintenance functions. 214 For the three layers specified above, non-associated overhead is 215 transported via the Optical Supervisory Channel (OSC) in order to 216 manage the optical connectivity. It has to be noted that these three 217 layers are common to both pre-OTN and OTN applications. 219 STM-N GbE ATM GFP 220 | | | | 221 | | | | 222 v v v v 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ======================== 224 | OCh Payload Unit (OPUk) | 225 STM-N GbE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------------------------ 226 | | | OCh Data Unit (ODUk) | Digital Path Layer 227 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------------------------ 228 v v | OCh Transport Unit (OTUk) | Digital Section Layer 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ======================== 230 | Optical Channel Layer (OCh) | 231 +-----------------------------------------+ Optical Channel Layer 232 | Optical Channel Multiplexing | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ======================== 234 | Optical Multiplex Section OMS | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optical Physical Section 236 | Optical Transmission Section OTS | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ======================== 239 As far as the client signal handling is concerned, the Digital 240 Wrapper layer is further layered as follows: 241 - The Optical Channel Transport Unit (OTUk) provides FEC 242 capabilities and optical section protection and monitoring 243 capabilities. 244 - The Optical Channel Data Unit (ODUk) layer provides client 245 independent connectivity, connection protection and monitoring 246 (also without the need to terminate the overhead information, 247 the ODUk overhead may be monitored non-intrusively). 248 - Clients signals i.e. STM-N signals, IP packets, ATM cells and 249 Ethernet frames are mapped (meaning digitally wrapped) into a new 250 structured frame defined as Optical Channel Payload Unit (OPUk). 252 For each of the three layers specified above, an associated (in- 253 band) overhead carrying the management information is added inside 254 the framed structure itself. Notice, that only the ODUk (k= 1, 2, 3) 255 and OCh are defined today as networking layers. The OPUk, ODUk and 256 OTUk layers constitute the Digital Transport Hierarchy also referred 257 to as the Digital Wrapper Layer. 259 Papadimitriou et al. Expires January 2002 5 260 2.2 Service Models for Optical Networking 262 Two service models are generally considered for the services at the 263 boundary between distinct administrative entities (sometimes 264 corresponding to separate technological domain or clouds): the 265 domain service and the unified service model. The former is largely 266 covered in [GMPLS-ARCH] and [IPO-FRM] while the latter is discussed 267 more extensively in this section in particular from the connection 268 service perspective. 270 Under the domain service model, the transport network primarily 271 offers high bandwidth connectivity in the form of Lambda Switched 272 LSP (L-LSP). The client LSR when requesting the following connection 273 services uses standardized signalling protocols across the domain 274 service interface: LSP creation/deletion/modification (non- 275 disruptive) and status enquiry. Moreover LSP tracing from the source 276 to the destination (as provided today by a TraceRoute function in 277 the IP domain) or simply ICMP-like commands must be provided to the 278 client LSR in order to check the integrity of the connections. 279 Remember here that LSPs are non-packet LSPs meaning that under 280 definition MPLS (tunnel) tracing methods are not applicable as such 281 to verify the status of a connection. 283 An end-system discovery procedure (also referred to as neighbor 284 discovery) may be used over the boundary interface (the domain 285 service interface) to verify local port connectivity between the 286 optical network and client LSR. Finally, a service discovery 287 procedure can be executed to obtain details about the connection 288 services offered by the optical network. The protocol (or 289 extensions) defined for neighbor discovery purposes are different 290 from the signaling protocol itself. They can be implemented for 291 instance through the use of LMP (see [MPLS-LMP]) or BGP (see [RFC- 292 1771]). 294 The set of connection services is offered across the domain service 295 interface such that the signaling protocol must provide a few 296 messages with certain edge-to-edge dedicated attributes only 297 significant between the client LSR and the optical network. Such a 298 protocol can be based on RSVP-TE [MPLS-RSVP] or CR-LDP [MPLS-LDP] as 299 defined today in [GMPLS-SIG] extended to RSVP-TE [GMPLS-RSVP] and 300 CR-LDP [GMPLS-CRLDP]. 302 The domain services model does not deal with the type and nature of 303 routing protocols within the optical network. However, the use of an 304 IGP routing protocol extended to include Traffic-Engineering 305 attributes such as [GMPLS-OSPF-TE] and [GMPLS-ISIS-TE] is certainly 306 the best solution. Furthermore, the integration of multiple, sub- 307 networks across inter-domain interface could require the 308 specification of extensions to inter-domain routing protocols such 309 as BGP. The domain services model would then result in the 311 Papadimitriou et al. Expires January 2002 6 312 establishment of an LSP topology (in the context of this memo, 313 Lambda-LSP and Fiber-LSP) and between client LSRs located at the 314 edge of the optical network. 316 3. Connection Identification 318 The connection services provided by the optical network are closely 319 related to the connection end-point identification. The following 320 LSR interface (referred here to as non-PSC interface) identification 321 parameters are considered from the client and network perspective. 323 3.1 Client and Optical LSR Interfaces 325 An Optical LSR (OLSR) refers to either an Optical Cross-Connect 326 (OXC) or a Photonic Cross-Connect (PXC) while a Client LSR refers 327 usually to a router, an SDH/Sonet or an OXC. In the context of this 328 memo and as usually agreed an OXC is defined as an O-E-O capable 329 device while a PXC is defined as an O-O capable device. 331 3.1.1 Non-PSC Interfaces 333 Optical and Client LSRs include devices where the forwarding 334 decision is based on time slots, wavelengths, or physical ports. So, 335 the set of Optical LSRs interfaces is defined as including the 336 following classes of interfaces in addition to the Packet Switch 337 Capable (PSC) interfaces and Layer-2 Switch Capable (L2SC) 338 interfaces: 340 - Time-Division Multiplex Capable (TDM) interfaces: 342 Interfaces that forward data based on the data's time slot in a 343 repeating cycle. Such interfaces belong mainly to SDH/SONET 344 Cross-Connect (XC), Add-Drop Multiplexer (ADM) and G.709 Cross- 345 Connect (operating at the Digital Transport Layer). 347 - Lambda Switch Capable (LSC) interfaces: 349 Interfaces that forward data based on the wavelength on which the 350 data is received. Such interfaces belong mainly to Photonic Cross- 351 Connect (PXC), Optical Cross-Connect (OXC) and G.709 Cross-Connect 352 operating at the optical channel layer. 354 - Fiber-Switch Capable (FSC) interfaces: 356 Interfaces that forward data based on a position of the data in 357 the real world physical spaces. Such interfaces belong mainly to 358 (Multi-Service) Cross-Connects capable to switch the content of a 359 whole fiber. 361 To each of these interface types corresponds a Label Switched 363 Papadimitriou et al. Expires January 2002 7 364 Path (LSP) type. Consequently, the following LSP types are defined: 365 TDM-LSP, Lambda-LSP (L-LSP) and Fiber LSP (F-LSP). LSPs can be 366 established only between, or through, interfaces of the same type. 368 The concept of nested LSP (LSP within LSP) facilitates building of 369 an LSP hierarchy. This hierarchy of LSPs can occur on the same 370 interface or between different interfaces. Therefore nesting can 371 also occur between interfaces belonging to distinct layers. The 372 following diagram illustrates the LSP nesting concept and the LSP 373 hierarchy. 375 P-LSP P-LSP 376 | | 377 | | 378 V | 379 +------------+ | 380 ----| LOVC TDM |--------- | 381 TDM-LSP| +------------+ TDM-LSP | | 382 --->| HOVC TDM |------ | | 383 +------------+ | | | 384 | | | | | 385 | | V V V 386 | | +-------------+ 387 TDM-LSP| ------>| LSC | 388 | +-------------+ 389 | | 390 V |L-LSP 391 +------------+ | 392 | FSC |<--------- 393 +------------+ 395 Needless to say, that this memo is mainly focused on Lambda-LSP (L- 396 LSP) services either standard (G.709 OTN based) or non-standard 397 (including pre-OTN developments). 399 3.1.2 Non-PSC Interfaces Address Space 401 We consider here that any transport and control addressing scheme 402 uses IPv4 and/or IPv6 addresses. Other categories of addressing 403 schemes such as NSAP are not considered in this memo. This because 404 as described in [GMPLS-ARCH], it would imply a modification of the 405 already existing signaling and routing protocols (included in the 406 Generalized MPLS protocol suite) that uses IPv4 and/or IPv6 407 addresses. 409 The fact that IPv4 and/or IPv6 addresses are the only considered 410 doesn't imply at all that they should be allocated in the same 411 addressing space than public IPv4 and/or IPv6 addresses used for the 412 Internet. 414 Papadimitriou et al. Expires January 2002 8 415 Each network layer could have a different administrative authority 416 responsible for address allocation and re-using the full addressing 417 space, completely independently though this does not seem to be the 418 most efficient way to allocate and manage the address space(s). 419 While private IP addresses can be used if they don't require to be 420 exchanged with any other operator, public IP addresses are otherwise 421 required. 423 As part of the Domain Service Model and as described in [IPO-RTG], 424 reachability information exchange through the Domain Service 425 interface, using eBGP protocol for instance, is considered as a must 426 within the scope of this document. 428 3.1.3 Non-PSC Interface Identifier Space 430 The following parameters are related to the physical-level 431 interfaces identification of Client and Optical LSR. Identifier 432 space value is purely local to each node. Therefore these values are 433 not used for routing purposes: 435 - Port ID: integer indicating and identifying a port within an 436 Optical LSR (OLSR) 438 - Channel ID: integer indicating and identifying a channel (i.e. a 439 wavelength) within a given port ID 441 - Logical-port ID: identifies a logical port whose identifier is 442 defined as the concatenation of the Port ID and the Channel-ID. 444 These definitions can be extended to identify the client network 445 element (client LSR) interfaces also simply referred to as LSR 446 interfaces. 448 3.2 Optical Network Identification 450 The optical network identification parameters can be defined, as a 451 Carrier Identifier (Carrier ID) is an integer defining the identity 452 of the carrier to which the OLSR element belongs. 454 The Carrier ID uniquely determines the owner of a signalling message 455 when travelling over inter-domain interface signalling channels 456 between optical networks. Typically the Carrier ID will be assigned 457 to the BGP AS number (2 bytes). 459 This identifier is provisioned by the administrative authority of 460 the optical network and can be exchanged during the neighbor 461 discovery process or any other inter-domain routing protocol 462 exchange such as BGP [RFC-1771]. 464 3.3 Client Network identification 466 Papadimitriou et al. Expires January 2002 9 467 The client network identification parameters include additionally to 468 the Client LSR logical-port ID, the Client Network Identifier 469 (Client Network ID) and the VPN Identifier (VPN ID): 471 - Client Network ID: identifier uniquely defining a client network 472 (or a group of client LSR belonging to the same administrative 473 authority) with respect to a given optical network domain. 475 This parameter should not have any complex semantic nor meaning 476 and could be useful when considering optical broadcast and 477 multicast applications. The Client Network ID (or simply Client- 478 ID) will be typically the BGP AS number (2 bytes) of the client 479 Network or simply the Client device Node ID (for instance, an IPv4 480 loopback address taken from the public IPv4 address space). 482 - VPN ID: VPN identifiers as defined in [RFC-2685] 484 The VPN ID is equivalent to the VPoN ID (Virtual Private optical 485 Network), however since the corresponding model does not apply 486 only to optical networks but also to SDH/SONET or any kind of 487 �layered� transport network, we don�t refer to VPoN identifiers in 488 this document. 490 In absence of a centralized network authority, the source and 491 destination OLSR are responsible for authentication of VPN IDs and 492 for call acceptance policies. In the absence of a pre-determined 493 policy, the default behavior is for the destination client LSR to 494 accept the LSP create request if the destination client LSR is 495 part of the signaled and authenticated VPoN. 497 Since a boundary OLSR can potentially be connected to multiple 498 client LSR, or a given client LSR can potentially request LSP 499 for several VPoNs, this identifier defines the possibility to 500 setup Virtual Private optical Networks (VPoN). The corresponding 501 models are described in Section 3.4. 503 The association of the client source address (and by extension the 504 OLSR address) with the logical-port ID (LPID) is used in the 505 context of the VPoN model. This implies the VPoNs services are 506 defined at the optical channel level and not only at the port 507 level meaning that the granularity of the VPoN can be finer than 508 the one classically defined for the so-called layer-1 VPNs. 510 The association of an (Client or OLSR) address and an LPID 511 is referred to as a connection termination-point 512 identifier (CTID). Typically, the Client and OLSR address space is 513 IPv4. Mappings between Client and OLSR termination point 514 identifier [;] are then 515 associated through the domain service interface signalling to the 516 VPN ID to which the LSP connection requests refers. The ingress 517 (and egress) OLSR need only to maintain a mapping table where this 518 information is stored per VPN ID. This approach easily provides 520 Papadimitriou et al. Expires January 2002 10 521 VPoN service to the client network. 523 3.4 VPoN Model 525 The VPoN - Virtual Private optical Network model considered here are 526 based on the following concepts: 527 - the Client ID defines the identification of an optical network 528 client (for instance, an ISP) 529 - the VPN ID defines the identification of a group defined 530 within this optical network client (for instance an ISP client) 532 The first model considers the Client ID as a VPoN identifier in 533 addition to the VPN ID while the second one considers only the VPN 534 ID as a VPoN identifier. 536 If we consider the Client ID as a VPoN identifier, then the 537 following alternative could be considered: 538 - isolation of the resources within a given VPoN (for instance, a 539 given ISP client) 540 - isolation of the resources between VPoNs within a given Client- 541 ID (for instance, between ISP clients belonging to the same 542 ISP) 543 - no-isolation of the resources i.e. sharing of the resource 544 between clients within the optical network 546 In this example, the optical network has several clients (i.e. ISPs 547 identified by a unique Client ID) and each of the optical network 548 clients has several clients (i.e. ISP clients identified by a unique 549 VPN ID). 551 If we only consider the VPN ID as a VPoN identifier, then the 552 following alternative could be considered: 553 - isolation of the resources within a given VPoN (for instance, a 554 given ISP) 555 - no-isolation of the resources i.e. sharing of the resource 556 between VPoNs within the optical network 558 In this example, the optical network has several clients (i.e. ISPs 559 identified by a unique VPN ID) and there is no dependence of the 560 isolation regarding the owner of the VPoN. 562 If we consider a unique address space per optical network, it means 563 that any address belonging to any VPoN must be unique. Otherwise, if 564 we consider on address space per VPoN (for instance, per Client ID), 565 then the address uniqueness is limited to this VPoN. 567 As specified in [RFC-2685], a VPoN may use a private address space, 568 which may overlap with the address space of another VPN or the 569 Internet public networks. A VPoN may span multiple optical domains 570 (BGP AS) meaning that an IP address only has meaning within the VPN 571 in which it exists. For this reason, it is necessary to identify 572 the VPoN in which a particular address space is meaningful. Note 574 Papadimitriou et al. Expires January 2002 11 575 also that [RFC-2685] recognized the advantage of identifying any 576 particular VPoN at any layer and at any location in which it exists 577 using ideally the same VPoN identifier. 579 Consequently, the case with address space uniqueness per VPoN is 580 most flexible since it permits to connect clients having overlapping 581 address spaces. However, this also requires for the optical network 582 to maintain a mapping table per VPN ID. 584 4. Optical Connection Services 586 Optical Connection Services include LSP Connection Services, LSP 587 Protection and LSP Routing. 589 4.1 Basic LSP Connection Services 591 Basic LSP connection services are provided through the exchange of 592 the parameters considered within this sub-section. They offer the 593 possibility to implement the basic connection (i.e. LSP) service 594 requests through the domain service interface. These parameters are 595 mainly the framing, the bandwidth, the directionality and the 596 network protection level. 598 4.1.1 Framing 600 The Framing parameter specifies the encoding format of the signal 601 for the requested connection. The Framing represents the networking 602 layer at which the requested connection will operate throughout the 603 optical network. 605 The Framing-type (referred to as LSP Encoding Type in [GMPLS-SIG]) 606 for LSP established throughout an optical network could be one of 607 the following: 608 - Ethernet: LAN Ethernet (LAN PHY) and WAN Ethernet (WAN PHY) 609 - TDM: SDH (ITU-T G.707) and SONET (ANSI T1.105) 610 - Digital Wrapper: ITU-T G.709 Digital Path and Proprietary 611 - Optical: ITU-T G.709 Optical Channels and Non-standard Lambda 613 4.1.2 Bandwidth 615 The Bandwidth values are defined with respect to the Framing-type. 616 Signal Types extend bandwidth values since the latter can take only 617 discrete values for non-packet LSP: TDM-LSP (i.e. SDH/SONET LSP), L- 618 LSP (i.e. G.709 Optical Channel LSP). We refer here to [GMPLS-SIG], 619 [GSMPL-SDH] and [GMPLS-G709] for more details concerning the Signal 620 Types definition and their respective value space for SDH/SONET and 621 G.709 OTN. 623 4.1.3 Directionality 625 Papadimitriou et al. Expires January 2002 12 626 As described in [GMPLS-SIG], bi-directionality of an LSP is defined 627 by the use of an upstream label within the LSP create request. 629 4.1.4 Network Protection 631 Signalling the network protection requested for an L-LSP can be 632 performed in two ways: either explicitly or implicitly. 634 1. Explicit Protection indication 636 The Protection parameter specifies the protection level desired for 637 the requested LSP inside the optical network (i.e. internal network 638 protection). Notice that protection at the domain service interface 639 (source- and destination-side protection) levels is not covered 640 since the domain service model implies that the protection of the L- 641 LSP initiated by the client is up to the corresponding networking 642 layer. The corresponding LSP nesting can be illustrated as follows: 644 ++++++++++++++++++++++++++++++ 645 + + 646 C1 ----------- N1 ----- N2 ----- N3 ------------ C2 647 | -> A + | / \ | + -> A | 648 | + | / \ | + | 649 | + | / \ | + | 650 ------------ N4 -------------- N5 ------------- 651 -> B + + -> B 652 ++++++++++++++++++++++++++++++ 654 Protection at the Network layer: 655 - Client Request: C1 to C2 Protected LSP 656 - Network Request: Primary LSP using [N1 � N2 � N3] 657 Secondary LSP using [N1 � N4 � N5 � N3] 659 Protection at the Client layer: 660 - Client Request: C1 to C2 LSP (Primary LSP) through path A 661 - Client Request: C1 to C2 LSP (Secondary LSP) through path B 663 Several network protection services (or network edge-to-edge LSP 664 protection) can be defined: 665 - Extra-Traffic (preemptable) 666 - Unprotected (default value) 667 - Re-routing (path-level edge-to-edge restoration) 668 - Multi-Group Shared Protection M:N (particular case 1:N) 669 - Group Shared Protection M:N (particular case 1:N) 670 - Dedicated 1:1 Protection 671 - Dedicated 1+1 Protection 672 - Enhanced Protection (ring-based protection) 674 Related to these protection types and levels, a reversion strategy 675 could be defined: 676 - a revertive strategy means that a LSP gets restored 677 to its original route after a failure has been recovered (or 679 Papadimitriou et al. Expires January 2002 13 680 restored) 681 - a non-revertive strategy means that a LSP does not 682 get restored to its original route after a failure has been 683 recovered (or restored) 685 The network protection mechanisms are extensively detailed in [IPO- 686 RES] together with the required signalling protocol extensions. 687 Enhanced protection (i.e. ring-based protection) concepts and 688 mechanisms are detailed in [IPO-RFR]. 690 2. Implicit Protection indication 692 There is another way to specify within a connection service request 693 the protection level desired; this by indicating the Class of 694 Service to which the requested LSP belongs. The Class-of-Services 695 (CoS) are detailed in section 5.4. 697 4.2 Pre-OTN Connection Service 699 Pre-OTN LSPs are also referred to as optical SDH/SONET connections. 700 Since the SDH/SONET parameters applies only to SDH/SONET framing 701 (i.e. LSP Encoding Type), Pre-OTN connection service includes the 702 Transparency levels supported by the optical non-transparent network. 704 Transparency levels currently supported in such optical networks 705 are: 706 - Path OH transparency: the network can transparently 707 transport HOVC/STS-SPE connections (in that case the 708 corresponding LSP is equivalent to a TDM-LSP) 709 - Multiplex Section/Line OH (MSOH/LOH) Transparency: the network 710 can transparently transport MSn/STS-N connections 711 - Regenerator Section/Section OH (RSOH/SOH) Transparency: the 712 network can transparently transport STM-N/OC-N connections 713 (such transparency service is supported by default throughout 714 G.709 OTN networks) 716 Semi-transparent levels can also be defined with respect to the 717 Client Signal; in that case, the network transparency levels are 718 referred to as OverHead tunneling levels: 719 - Specific MSOH/LOH bytes Transparency such as MS/Line DCC (D4 720 - D12) or K1/K2 bytes: the network can non transparently 721 transport MSn/STS-N connections while keeping the MS/Line DCC 722 or other MSOH/LOH bytes unchanged 723 - Specific RSOH/SOH bytes Transparency such as RS/Section DCC (D1 724 � D3) or J0 bytes: the network can non transparently 725 transport MSn/STS-N connections while keeping the MS/Line DCC 726 or other MSOH/LOH bytes unchanged 728 Such transparency service provides for instance in-fiber/in-band 729 signalling transport mechanism across the optical network for 730 SDH/SONET client networks. Consequently, the optical network does 732 Papadimitriou et al. Expires January 2002 14 733 not use anymore the corresponding MSOH/LOH and/or RSOH/SOH overhead 734 bytes to provide its internal signalling transport mechanism. 736 4.3 OTN Connection Service 738 As described in Section 2.1 based, the OTN connection service is 739 based on the G.709 specification [ITUT-G709]. However, today most of 740 the client LSR interfaces don�t support G.709 specification (in 741 particular when client LSR are routers) so that at the domain 742 service interface client-to-network interconnection is provided 743 through the use of Pre-OTN interfaces supporting STM-N/OC-N signals. 744 The client signal is terminated at the ingress Optical LSR (OLSR) 745 and then either tunneled or simply continued within the optical 746 network. 748 This suggests the definition of an interworking function OTN<->Pre- 749 OTN at the Domain Service Interface (i.e. ingress and egress OLSR). 751 GMPLS Signalling for OTN connection service is defined in [GMPLS- 752 G709]. Such service provides also the full transparency of the 753 client signal (see Section 4.2). 755 4.4 All-Optical Connection Service 757 The distinction between the OTN and the All-Optical connection 758 service is made for the following reasons. First the OTN compliance 759 refer to an Optical Transport Hierarchy (OTH) as described in [G709- 760 FRM]. Then, OTN compliance implies the implementation of intra- 761 domain optical signal control and monitoring capabilities through a 762 specific implementation of the control plane using non-associated 763 overhead at the OTH level. 765 Therefore, the optical signal control and monitoring capabilities 766 can be provided either by using the G.709 non-associated OverHead 767 (naOH) through the Optical Supervisory Channel (OSC) or by using 768 non-standardized methods. The latter refers to methods using 769 technology such as optical signal Sub-Carrier Multiplexing (SCM). 770 More details about this technology are available in [IPO-SCM]. 772 4.4.1 All-optical Connection Service - Overview 774 When considering a Domain Service Model, the key issue concerning 775 all-optical connection service is that the client optical signal 776 must be terminated at the ingress AND at the egress of the optical 777 domain (which includes only PXC nodes except at the edge interfaces 778 toward the client network). Otherwise, it would be impossible for 779 the optical network to control and monitor the connection service 780 provided to the client network. This independently to the fact that 781 the client LSR interfaces must be either colored otherwise 782 wavelength conversion has to be provided at the ingress of the 783 optical network. 785 Papadimitriou et al. Expires January 2002 15 786 The alternative is to provide all-optical connection services from 787 the source to the destination client network without terminating the 788 optical channel at the ingress and egress of the network. However, 789 such approach requires providing to the client LSR an access to the 790 optical control plane since clients nodes must now have the 791 capability to perform their own L-LSP connection management. This 792 would in turn require the definition of Virtual Private control 793 Networks (VPcN) in order to guarantee some privacy. Notice here the 794 difference between a VPoN and VPcN: the VPoN is a private network 795 defined at the transport plane level while the VPcN is defined at 796 the control plane level. 798 4.4.2 All-Optical Connection Parameters 800 These parameters are related to all-optical networking connection 801 services. These parameters can be sub-divided into two groups. 802 First, the ones used to monitor the optical signal quality such as 803 the Bit Error Rate (BER). Then, the optical parameters used for 804 optical routing purposes (commonly referred to as optical routing 805 impairments) such as the Optical Signal-to-Noise Ratio (OSNR), 806 Polarization Mode Dispersion (PMD). 808 The optical signal performance monitoring is achieved by measuring 809 (through methods not defined in this document) the BER. As 810 parameters, the BER is defined the exponent of the maximum BER 811 admitted for a given optical signal (default value is zero). Real- 812 time measurements allow performing signal quality monitoring and 813 therefore on-line measurements. In turn, this method enables to 814 determine whether or not the current optical signal quality meets 815 the optical connection Service Level Specification (SLS). 817 Concerning optical routing impairments, linear parameters such as 818 Optical SNR (OSNR) and Polarization Mode Dispersion (PMD) are 819 considered in [IPO-ORI] for sub-optimal optical routing. Amplified 820 Spontaneous Emission (ASE) influence the Optical SNR (OSNR), which 821 determines an upper bound to the maximum number of spans that an L- 822 LSP can traverse. The PMD determines an upper bound to the maximum 823 optical span length that an L-LSP can traverse. More details about 824 optical routing linear impairments can be additionally found in 825 [IEEE-ORL]. Nevertheless, these linear parameters constitutes a 826 subset of the optical routing impairments that have to be considered 827 for Long Haul optical transmission (> 2000 km). We refer to [IPO- 828 NLRI], where non-linear optical routing impairments are considered. 830 For non-transparent optical transport networks, one has to take into 831 account the Jitter parameter in addition to the Bit Error Rate 832 (BER). This parameter is defined as the maximum jitter admitted for 833 a given optical signal (default value is zero) also referred to as 834 Jitter Tolerance. There are currently three types of jitter 835 specifications: 836 - jitter tolerance: the peak-to-peak amplitude of sinusoidal 837 jitter applied on the input signal that causes a 1dB power 839 Papadimitriou et al. Expires January 2002 16 840 penalty 841 - jitter generation: the process whereby jitter appears at the 842 output port � transmission � in absence of input jitter 843 - jitter transfer: a measure of the quantity of input jitter 844 attenuation with respect to the output signal 846 5. Enhanced Optical Connection Services 848 This section covers the connection services such as Optical 849 Multicast, Waveband Switching, Optical Class-of-Services and VPoN 850 services. 852 5.1 Multicast Service 854 Today, as described in [GMPLS-SIG], an LSP request can translate 855 either a unidirectional unicast connection or a bi-directional 856 unicast connection. Optical multicast connection service provides 857 the capability to establish point-to-multipoint LSPs throughout the 858 optical network. In this case, the ingress client and optical LSR 859 could have many destinations in common therefore reducing the number 860 of wavelengths used per fiber link. Optical multicast is detailed in 861 [IPO-OMF] as well as the related signalling considerations. We 862 briefly summarize here the rationale and key associated concepts. 864 The optical multicast concept can be applied to numerous client- 865 layer applications covering mainly Optical Broadband applications, 866 Multimedia, Video and HDTV. 868 When extended to the optical domain, the multicast concept offers 869 the following advantages: 870 - Efficient optical 1+1 (dedicated) protection 871 - Improved performance (no store and forward) compared to packet- 872 oriented multicast technology 873 - Overall network throughput improvement by reducing the number 874 of wavelengths used per fiber link (i.e. minimizing the overall 875 bandwidth usage per fiber link) 876 - Reduction of the total number of transceivers in all- 877 optical networks. 879 However, the major drawback to overcome in optical multicast-capable 880 networks is to compensate the power penalty introduced during the 881 optical signal splitting. Moreover, the multicast problem in 882 communication networks is NP-Complete (since described by the 883 Steiner Tree Problem applied to communication networks). 885 [IPO-OMF] also extensively details the diverse possibilities that 886 can be considered to extend the currently defined (or under- 887 definition) multicast signalling protocols. 889 5.2 Waveband Switching Service 891 Papadimitriou et al. Expires January 2002 17 892 Waveband Switching refers to the switching of a non-contiguous set 893 of identical optical channels which are to be routed, switched and 894 protected as an individual entity. This service can be useful for 895 inverse multiplexing where high bandwidth client signal is 896 partitioned into multiple lower rate optical channels. For instance 897 a 10 Gbps client signal partitioned into four 2.5 Gbps optical 898 channels. It is desirable that each optical channel use the same 899 physical resources, with identical propagation delay (if O/E/O 900 conversion is needed) and protection schemes, thus minimizing the 901 segmentation and reassembly within the client domain. 903 Waveband Switching underlying concepts are extensively covered in 904 [IPO-WBS] where we demonstrate the benefits from the introduction in 905 optical networks of the optical multi-granularity concept. 907 Let�s briefly examine the key drivers and advantages provided by the 908 waveband switching services. Today, optical switches are able to 909 handle different switching granularities from wavelength to fiber 910 and especially wavebands. Taking benefits from these technologies, 911 switching larger granularities reduce at the same time the 912 complexity of control operations, the amount of hardware in the 913 optical layer, and in addition relax some physical constraints. 914 Gains expected from the approach are partly function of the 915 efficiency of the grooming of wavelengths into larger granularities. 916 In particular, intelligent intermediate grooming makes the multi- 917 granularity concept even more attractive since reducing the required 918 size of optical switching matrix typically by a factor of two or 919 more. 921 Optical switching allows the transmission capacity of point to point 922 links to scale up to the predicted traffic requirements of multiple 923 Tbps. Hence the switching capacity of backbone nodes has to scale up 924 to thousands of Wavelength Switching Capable (WBSC) interfaces. To 925 overcome the bottleneck of electronic switching, wavelength cross- 926 connects have been introduced. 928 Optical switching can also be extended to switch larger 929 granularities such as bands of wavelengths (also referred to as 930 wavebands) and fibers (also referred to as spatial switching). By 931 considering that optical networks will not experience a significant 932 evolution of their topology properties (connectivity, number of 933 nodes), these new granularities will easily support the traffic 934 growth with limited impact on efficiency. 936 Therefore, the main issue is to find the optimum way to arrange the 937 spatial distribution of traffic flows on the topology in order to 938 create connections at the different optical granularities (i.e. 939 different LSP bandwidth). The intrinsic properties of a typical 940 backbone network give us good perspectives to achieve the goal of 941 dynamically creating LSPs at these granularities. The relatively 942 limited number of nodes (tens of nodes) and the relative small 943 connectivity (3 to 8 neighbors per node) allow us to assume that 945 Papadimitriou et al. Expires January 2002 18 946 there will be a strong correlation between flows of traffic inside 947 the network. 949 In other terms, it means that, assuming an efficient planning, 950 numerous flows (e.g. STM-N/OC-N or IP flows) have to be processed in 951 the same way in the nodes. Thus, this should give the opportunity to 952 establish wavelength, waveband and fiber connections, and process 953 most of the traffic using optical granularities as large as 954 possible. This will alleviate some capacity bottlenecks and above 955 all reduce the network cost. 957 In [IPO-WBS], we propose to use this concept of multiple optical 958 granularities in association with grooming strategies and GMPLS 959 integration requirements. Among possible optical switching 960 granularities, waveband is an attractive trade-off for foreseen 961 traffic volumes in next few years and will be particularly 962 considered in the following. 964 For this purpose, waveband-switching layer is introduced as an 965 additional sub-layer between the Lambda and the Fiber layer i.e. 966 between corresponding Lambda-LSP (wavelength switching) and Fiber- 967 LSP (spatial switching). However, this sub-layer does not introduce 968 either a new type of interface or a new class of Forwarding 969 Adjacencies (FA) class since we consider a Lambda LSP (L-LSP) as a 970 particular case of a more generic Waveband-LSP (WB-LSP). 972 In terms of grooming strategies, we also propose to have both end- 973 to-end and intermediate grooming at waveband and fiber levels to 974 make the concept more attractive. Intermediate grouping is referred 975 to as the aggregation of traffic with different source nodes and/or 976 different destination nodes but with a common sub-path at the 977 optical layer. End-to-end grooming (i.e. between source and 978 destination OLSR) is a particular case of intermediate grooming 979 where the sub-path in the optical layer is the entire Lambda-LSP (L- 980 LSP) between source and destination OLSR. 982 5.3 Priority-Preemption 984 The priority-preemption is a service offering prioritization of the 985 connection requested during the LSP setup with respect to the 986 provisioned priorities of the optical network resources (links, 987 paths, etc.). Then the priority of the connection is used to define 988 a preemptability level of the connection with respect to the setup 989 and/or recovery of other LSPs already provisioned or dynamically 990 established within the optical network. 992 5.3.1 Priority 994 The Priority specification (as described in [MPLS-CRLDP] for 995 instance) includes the setup and the hold priority. The priority 996 field is defined as an (8-bit) integer indicating the priority of the 997 requested L-LSP: 999 Papadimitriou et al. Expires January 2002 19 1000 - Default value: from 0xE (higher) to 0x1 (lower) 1001 - Priorities from 0xF is reserved 1002 - Priorities from 0x0 is reserved 1004 Where (4 MS bits) defines the priority-class: C ranges from 1 to 1005 E Class 1 is considered as the default class and Class 0 and Class F 1006 are reserved priority-classes. The priority value (4 LS bits) within 1007 a given priority-class ranges from 0xE (higher priority) to 0x1 1008 (lower priority). 1010 5.3.2 Preemption 1012 Preemption is defined as a (4-bit) integer indicating the 1013 preemptability behavior of an L-LSP. This parameter specifies 1014 whether a given LSP can be preempted by a L-LSP of higher priority 1015 if the resource used by the lower-priority L-LSP need to be used 1016 during the setup and/or the recovery of this higher priority L-LSP. 1018 The possible values for the preemption behavior can be defined as: 1019 - Setup and Recovery preemptability: 0x0 (Class 1) 1020 - Recovery preemptability : 0x1 (Class 2 to 7) 1021 - Setup preemptability : 0x2 (Class 8 to D) 1022 - No_preemptability : 0x3 (Class E) 1024 5.4 Class-of-Services 1026 The Class-of-Services (CoS), described in [IPO-COS] and based on 1027 [DIFF-ARCH] specification, are build upon the following principle: 1028 at the (ingress) client LSR, if we consider Packet-Switch 1029 Capable(PSC) interfaces, the DiffServ Codepoint (DSCP) [DIFF-DSF] 1030 defining the Per Hop Behaviour (PHB) [DIFF-PHB], are mapped to the 1031 LSP priority class. For this purpose, we propose the following 1032 rules: 1033 - Class 1 corresponds to Best-Effort service 1034 - Class 2 to D corresponds to Assured Forwarding (AF) services 1035 . Class AF1 ranges from 2 to 4 1036 . Class AF2 ranges from 5 to 7 1037 . Class AF3 ranges from 8 to A 1038 . Class AF4 ranges from B to D 1039 - Class E corresponds to Expedited Forwarding (EF) service 1041 These DiffServ classes are related within the optical network to the 1042 service-level defined in section 3: 1043 - Class 1 defines a best-effort service 1044 - Class 2 to 7 defines a bronze service 1045 - Class 8 to D defines a silver service 1046 - Class E defines a gold service 1048 Within our definition of LSP, the analogy between the drop 1049 precedence in DiffServ and the priority class could also be related 1050 to the preemption setting at the domain service interface during the 1052 Papadimitriou et al. Expires January 2002 20 1053 LSP creation. In this case, the priority value setting is performed 1054 through the following rules: 1055 - Class 1 defines a priority ranging from 0x11 to 0x1E 1056 - Class 2 to 7 defines a priority ranging from 0x21 to 0x7E 1057 - Class 8 to D defines a priority ranging from 0x81 to 0xDE 1058 - Class E defines a priority ranging from 0xE1 to 0xEE 1060 Application of this model will enable to have a selection mechanism 1061 at the boundary client LSR (in most of the cases, it will be a 1062 router) providing LSP multiplexing based on the mapping between the 1063 DiffServ Code Points (DSCP) and the LSP Class-of-Services provided 1064 by the optical network. Moreover, this technique enables the direct 1065 mapping of finer granularity Packet-based LSP to coarser granularity 1066 L-LSPs without any disruption in the end-to-end QoS offered to the 1067 client network connections. 1069 5.5 VPoN Service 1071 The relationship between the Priority/Preemption and the CoS and 1072 VPoN model is based on the resource isolation concept. Two VPoN 1073 models have been defined (depending on the usage of the Client ID) 1074 so that the Priority/Preemption levels considered here are directly 1075 related to these models and the resource isolation concept. 1077 If we consider the Client ID as an identifier, then we have the 1078 following options concerning the preemption levels: 1079 - preemption within a given VPoN (i.e. within VPoN belonging 1080 to the same optical network client) 1081 - preemption within a given Client ID (i.e. between VPoN 1082 belonging to the same optical network client) 1083 - preemption between Client IDs (i.e. between optical network 1084 clients) 1086 If we do not consider the Client ID as an identifier, then we have 1087 the following options concerning the preemption levels: 1088 - preemption within a given VPoN (i.e. within VPoN belonging 1089 to the same optical network client) 1090 - preemption between VPoNs (i.e. between VPoN belonging to 1091 the separate optical network client) 1093 5.6 LSP Monitoring 1095 TBD. 1097 5.7 LSP Routing Diversity 1099 From the optical network viewpoint, LSP routing diversity is related 1100 to the path disjointness provided by the constraint-based route 1101 computation at the ingress optical LSR. Routing diversity can be 1102 related to link, node, path and Shared Risk Link Group (SRLG). Here, 1103 we focus on the disjointness of the LSP explicit route with respect 1104 to SRLGs. 1106 Papadimitriou et al. Expires January 2002 21 1107 It is commonly admitted [IPO-FRM] that SRLGs identifiers are 1108 exchanged between nodes belonging to the same optical domain to 1109 prevent the use of shared resources that can affect all links 1110 belonging to this group in case of shared resource failure. For 1111 instance, as described in [IPO-SRLG], two LSPs flowing through the 1112 same fiber link in the same fiber trunk. The SRLG concept has been 1113 extended by demonstrating that a given link could belong to more 1114 than one SRLG, and two links belonging to a given SRLG may 1115 individually belong to two other SRLGs. 1117 Many proposals already include the SRLG concept when considering the 1118 constraint-based path computation of optical channel routes. In 1119 optical domains this concept of SRLG is used for deriving a path, 1120 which is disjoint from the physical resource and logical topology 1121 point-of-view. However, the definition of SRLG in the current format 1122 as described in [GMPLS-OSPF-TE] and [GMPLS-ISIS-TE] does not 1123 provide: 1124 - the relationship between logical structures or physical 1125 resources (for example, a fiber could be part of a sequence of 1126 fiber segments, which is included in a given geographical 1127 region), and 1128 - the risk assessment during path computation implying the 1129 allocation of a conditional failure probabilities with the 1130 SRLGs 1131 - the analysis of the specifications of constraint-based path 1132 computation and path re-optimization taking SRLG information 1133 into account. 1135 The model proposed in [IPO-SRLG] document proposes a technique to 1136 compute the SRLG with respect to a given risk type. This is achieved 1137 by identifying for a given physical layer the resources belonging to 1138 an SRLG. The proposed model also permits to compute the dependencies 1139 of these resources into the resources belonging to lower physical 1140 layers. The result of the computation also enables OLSR to determine 1141 the risk associated to each of the SRLGs. 1143 1. Hierarchical Model 1145 The SRLG model defined in [IPO-SRLG] includes two hierarchies: the 1146 physical hierarchy and the logical hierarchy. 1148 The physical hierarchy is related to the fiber topology (more 1149 generally the physical resources) of the optical network including 1150 the wavelengths build on top of this physical topology. The network 1151 (physical) resource model considered in [IPO-SRLG] is based on 1152 concepts introduced in [IPO-FRM]. The concepts around network 1153 resource hierarchy developed within this document are based on the 1154 following components: 1155 - Sub-Channel (TDM circuit � only applicable for SDH/SONET 1156 networks) 1157 - Optical Channel (or Wavelength) 1159 Papadimitriou et al. Expires January 2002 22 1160 - Fiber Link 1161 - Fiber Segment 1162 - Fiber Sub-segment 1163 - Fiber Trunks 1165 The Logical hierarchy is related to the geographical topology of the 1166 network. The definition of the logical hierarchical structure covers 1167 an increasing extended logical structure partitioning of the area 1168 covered by the optical network. For that purposes the concept of 1169 node, zone and region are defined in [IPO-SRLG]. 1171 2. Risk Assessment 1173 Risk assessment is defined as the evaluation of the potential risk 1174 associated to the inclusion of a given resource (this resource 1175 belongs to a given resource type located within a given logical 1176 structure such as a geographical location). Since the SRLG 1177 computation is performed with respect to a given risk type 1178 associated to a given network resource, a failure probability is 1179 assigned to the network resources instances included within the same 1180 logical structure. So, in the approach described in [IPO-SRLG] there 1181 is a direct mapping between the risk type and the resource type as 1182 well as the failure probability associated to this resource type 1183 within a given logical structure. 1185 3. Inference Model 1187 The model described in [IPO-SRLG] is provided to automate the 1188 discovery of the Shared Risk Link Groups (SRLGs) at a given layer 1189 for a given physical resource type. This resource type could be 1190 located within a given region and OLSR. 1192 Note however, that in the domain service model, when a client OLSR 1193 sends an LSP service request it can only reference about the LSPs it 1194 has already established. Consequently, it can only reference an LSP 1195 M from which the new LSP N should be diverse. The OLSR will 1196 interpret this request by considering the Shared Risk Link Group 1197 (SRLG) of the LSP M and find a physical route for the LSP N whose 1198 SRLG is diverse from. 1200 The same process applies at the inter-domain interface where the 1201 outgoing OLSR (belonging to the BGP AS[i]) does only knows about the 1202 LSPs he has already established to the incoming OLSR (belonging to 1203 the BGP AS[j], AS[i] =/= AS[j]). Consequently, the outgoing OLSR can 1204 only reference an LSP M from which the new LSP N should be diverse. 1206 6. Connection Service Policy 1208 Policy-related parameters are related to directory services provided 1209 to the client client LSR through the domain service interface 1210 services. These parameters include the following items: 1211 - Service-Level parameters 1213 Papadimitriou et al. Expires January 2002 23 1214 - Schedule parameters 1215 - Contract parameters 1216 - Billing parameters 1217 - Optional parameters 1219 By receiving such kind of parameters the source boundary OLSR needs 1220 to forward the content of these request through the NMI interface 1221 (interface between the OLSR and a management server) to a 1222 centralized directory service or de-centralized service in 1223 combination with a distributed connection admission control. 1225 6.1 Service-level Specification 1227 Service level (i.e. service-level specification) parameter could be 1228 implemented as a 16-bit integer which refer to parameters detailed 1229 in the previous sub-section (service-related parameters). This 1230 parameter indicates the class-of-service offered by the optical 1231 network carrier. 1233 The first 256 values (0 � 255) are reserved for future inter- 1234 operability agreements between carriers and service providers. The 1235 remaining values are carrier specific. 1237 The service-level parameter could include the following attributes: 1238 - Optical Signal Quality 1239 - Protection parameters 1240 - Priority and Preemption 1241 - Routing parameters 1242 - Signaling security levels 1244 For instance, value 0x1x might indicate through a request to a 1245 directory service, a best-effort service: 1246 - unprotected LSP 1247 - default priority 1248 - no routing diversity 1249 - no signalling authentication 1251 Value ranging from 0x2x to 0x7x to might indicate through a request 1252 to a directory service, a bronze service: 1253 - M:N protected LSP 1254 - low-priority 1255 - no routing diversity 1256 - signalling authentication (no signalling encryption) 1258 Value ranging from 0x8x to 0xDx to might indicate through a request 1259 to a directory service, a silver service: 1260 - M:N protected LSP 1261 - medium-priority 1262 - no routing diversity 1263 - signalling authentication (no signalling encryption) 1265 Papadimitriou et al. Expires January 2002 24 1266 Value 0xEx might indicate through a request to a directory service, 1267 a gold service: 1268 - 1:1 protected LSP 1269 - high-priority 1270 - global routing diversity 1271 - signalling authentication and encryption 1273 The optical signal quality levels need to be defined while a low 1274 signal quality does not have to necessarily correspond to a Best- 1275 Effort service. 1277 Consequently, this means that the client knows the meaning of the 1278 service-level prior to the corresponding LSP service request. Within 1279 the LSP request, explicit parameter values take precedence over 1280 service-level. 1282 The definition of the corresponding mechanisms lead us to two 1283 options that seems feasible for this purpose: 1284 - either the client LSR knows the content of the policy-related 1285 parameters without any additional information coming from the 1286 optical network 1287 - or the client LSR initiates an LSP service request (or 1288 even a dedicated request) with appropriate extensions to 1289 request the policy-related parameters values to the optical 1290 network. So the client learns dynamically the service-level 1291 offered by the optical network through a directory service 1292 before initiate a LSP create request to the ingress OLSR. In 1293 future release of this memo, we will refer to this as Service 1294 Discovery Service (SDS) at the domain service interface. 1296 6.2 Scheduling Service 1298 Scheduling refers to the possibility to create, delete or modify LSP 1299 through a given time-of-day, day-to-day, day-to-week, etc. 1300 scheduling plan. 1302 For a given plan, the scheduling functions could be start, stop and 1303 repeat. The attributes of these scheduling functions could be: 1304 - the start/stop time at which the function has to be 1305 executed/stopped 1306 - the start/stop date at which the function has to be 1307 executed/stopped 1308 - the recurrence interval between two repeated execution of the 1309 function 1310 - the number of recurrence intervals 1312 The default values of the schedule parameter regarding the LSP 1313 requested service: 1314 - the start time is the current time (start now) 1315 - the start date is the current date (start now) 1316 - the recurrence interval is infinite since the LSP request has 1318 Papadimitriou et al. Expires January 2002 25 1319 to be executed only once 1320 - the number of recurrence intervals equals zero 1322 6.3 Billing Service 1324 The billing parameter refers to the billing client identifier onto 1325 which the requested services will be charged. A given client ID 1326 could have more than one billing client identifier. 1328 An optical network client (identified by a Client ID) could have 1329 several clients (i.e. VPN IDs) and assign to each of them a 1330 dedicated billing identifier. 1332 This parameter is implemented as a 16-bit integer. The first 256 1333 values (from 0 to 255) are reserved for future inter-operability 1334 agreements. The remaining values are carrier specific so left with 1335 unspecified semantic. 1337 7. Security Considerations 1339 By including within the service-level parameter the signalling 1340 security level, the proposed document, as detailed in section 6, 1341 takes into account the security of the client signalling request 1342 in a build-in manner. 1344 8. Acknowledgments 1346 The authors would like to thank Bernard Sales, Emmanuel Desmet, 1347 Hans De Neve, Fabrice Poppe, Stefan Ansorge and Gert Grammel for 1348 their constructive comments and inputs. 1350 9. References 1352 1. [DIFF-DSF] S.Nichols et al., �Definition of the Differentiated 1353 Services Field (DS Field) in the IPv4 and IPv6 Headers�, RFC 2474, 1354 December 1998. 1356 2. [DIFF-ARCH] S.Blake et al., �An Architecture for Differentiated 1357 Services�, RFC 2475, December 1998. 1359 3. [G709-FRM] A.Bellato, D.Papadimitriou, et al., �Generalized MPLS 1360 Control Framework for G.709 Optical Transport Networks�, Internet 1361 Draft, Work in progress, draft-bellato-ccamp-g709-framework-00.txt, 1362 June 2001. 1364 4. [GMPLS-ARCH] E.Mannie et al., �Generalized MPLS Architecture�, 1365 Internet Draft, Work in progress, draft-ietf-ccamp-gmpls- 1366 architecture-00.txt, June 2001. 1368 5. [GMPLS-CRLDP] P.Ashwood-Smith, L.Berger et al., �Generalized MPLS 1369 � Signaling Functional Description�, Internet Draft, Work in 1370 progress, draft-ietf-mpls-generalized-cr-ldp-03.txt, May 2001. 1372 Papadimitriou et al. Expires January 2002 26 1373 6. [GMPLS-G709] M.Fontana, D.Papadimitriou, et al., �Generalized MPLS 1374 Control for G.709 � Functional Description�, Internet Draft, Work in 1375 progress, draft-fontana-ccamp-gmpls-g709-00.txt, June 2001. 1377 7. [GMPLS-ISIS-TE] K. Kompella et al., �IS-IS Extensions in Support 1378 of MPL(ambda)S,� Internet Draft, draft-ietf-isis-gmpls-extensions- 1379 01.txt, March 2001. 1381 8. [GMPLS-OSPF-TE] K. Kompella et al., �OSPF Extensions in Support 1382 of MPL(ambda)S,� Internet Draft, draft-kompella-ospf-gmpls- 1383 extensions-01.txt, February 2001. 1385 9. [GMPLS-RSVP] P.Ashwood-Smith, L.Berger et al., �Generalized MPLS � 1386 Signaling Functional Description�, Internet Draft, Work in progress, 1387 draft-ietf-mpls-generalized-rsvp-te-03.txt, May 2001. 1389 10. [GMPLS-SIG] P.Ashwood-Smith, L.Berger et al., �Generalized MPLS - 1390 Signaling Functional Description�, Internet Draft, Work in progress, 1391 draft-ietf-mpls-generalized-signalling-04.txt, March 2001. 1393 11. [GMPLS-SDH] E.Mannie et al., �Generalized MPLS Extensions for 1394 SONET and SDH Control�, Internet Draft, Work in progress, draft-ietf- 1395 ccamp-gmpls-sonet-sdh-01.txt, June 2001. 1397 12. [IPO-COS] D.Papadimitriou et al., �Optical Class-of-Services for 1398 Lambda LSP�, Internet Draft, Work in Progress, draft-papadimitriou- 1399 ipo-lambda-lsp-cos-00.txt, July 2001. 1401 13. [IPO-FRM] B.Rajagopalan, J.Luciani et al., �IP Optical 1402 Framework�, Internet Draft, Work in Progress, draft-many-optical- 1403 framework-03.txt, March 2001. 1405 14. [IPO-NLRI] D.Papadimitriou et al., �Optical Non-Linear Routing 1406 Impairments in Wavelength Switched Optical Networks�, Internet 1407 Draft, Work in progress, draft-papadimitriou�ipo-non-linear- 1408 impairmnets-00.txt, July 2001. 1410 15. [IPO-OMF] D.Papadimitriou, D.Ooms and J.Jones, �Optical 1411 Multicast � A Framework�, Internet Draft, Work in progress, draft- 1412 poj-optical-multicast-01.txt, July 2001. 1414 16. [IPO-RES] J.Hahm, D.Griffith, R.Hartani and D.Papadimitriou, 1415 �Restoration Mechanisms and Signalling Extensions in Optical 1416 Networks�, Internet Draft, Work in progress, draft-many-optical- 1417 restoration-01.txt, July 2001. 1419 17. [IPO-RFR] H.Ghani, P.Bonenfant, D.Papadimitriou and 1420 S.Dharanikota, �Optical Architectural Framework for Automatic 1421 Protection Provisioning In Dynamic Optical Rings�, Internet Draft, 1422 Work in progress, draft-ghani-optical-rings-01.txt, March 2001. 1424 Papadimitriou et al. Expires January 2002 27 1425 18. [IPO-SCM] D.Blumenthal et al., �Optical Performance Monitoring 1426 in Reconfigurable WDM Optical Networks Using Sub-Carrier 1427 Multiplexing�, Journal of Lightwave Technology, Volume 18, Number 1428 12, December 2000. 1430 19. [IPO-SRLG] D.Papadimitriou et al., �Inference of Shared Risk 1431 Link Groups�, Internet Draft, Work in progress, draft-many- 1432 inference-srlg-01.txt, July 2001. 1434 20. [IPO-WBS] E.Dotaro et al., �Optical Multi-Granularity � 1435 Architectural Framework�, Internet Draft, Work in progress, draft- 1436 dotaro-ipo-multi-granularity-00.txt, July 2001. 1438 21. [RFC-1771] Y.Rekther et al., �A Border Gateway Protocol 4 (BGP- 1439 4)�, Internet Standard Track, RFC 1771. 1441 22. [RFC-2685] B.Fox and B.Gleeson, �VPN Identifiers�, Internet 1442 Standard Track, RFC 2685. 1444 10. Author's Addresses 1446 Dimitri Papadimitriou (Editor) 1447 Senior R&D Engineer � Optical Networking 1448 Alcatel IPO NSG-NA 1449 Francis Wellesplein 1, 1450 B-2018 Antwerpen, Belgium 1451 Phone: +32 3 240-84-91 1452 Email: Dimitri.Papadimitriou@alcatel.be 1454 Jim Jones 1455 Alcatel TND-USA 1456 3400 W. Plano Parkway, 1457 Plano, TX 75075, USA 1458 Phone: +1 972 519-27-44 1459 Email: Jim.D.Jones1@usa.alcatel.com 1461 Papadimitriou et al. Expires January 2002 28 1462 Full Copyright Statement 1464 "Copyright (C) The Internet Society (date). All Rights Reserved. 1465 This document and translations of it may be copied and furnished to 1466 others, and derivative works that comment on or otherwise explain it 1467 or assist in its implementation may be prepared, copied, published 1468 and distributed, in whole or in part, without restriction of any 1469 kind, provided that the above copyright notice and this paragraph 1470 are included on all such copies and derivative works. However, this 1471 document itself may not be modified in any way, such as by removing 1472 the copyright notice or references to the Internet Society or other 1473 Internet organizations, except as needed for the purpose of 1474 developing Internet standards in which case the procedures for 1475 copyrights defined in the Internet Standards process must be 1476 followed, or as required to translate it into languages other than 1477 English. 1479 The limited permissions granted above are perpetual and will not be 1480 revoked by the Internet Society or its successors or assigns. 1482 This document and the information contained herein is provided on an 1483 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1484 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1485 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1486 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1487 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1489 Papadimitriou et al. Expires January 2002 29