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