idnits 2.17.1 draft-ietf-ccamp-sdhsonet-control-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1503. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1480. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1487. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1493. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (February 2005) is 7010 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '8' is defined on line 1422, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (ref. '1') (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (ref. '2') (Obsoleted by RFC 3979) -- No information found for draft-ietf-ccamp-ospf-extensions - is the name correct? == Outdated reference: A later version (-19) exists of draft-ietf-isis-gmpls-extensions-16 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-bundle-04 Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Bernstein (Grotto Networking) 3 Internet Draft E. Mannie (InterAir Link) 4 Category: Informational V. Sharma (Metanoia, Inc.) 5 E. Gray (Marconi Communications) 6 Expires August 2005 February 2005 8 Framework for GMPLS-based Control of SDH/SONET Networks 9 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667 [1] and Section 6 of RFC 3668 [2]. 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 Generalized MPLS (GMPLS) is a suite of protocol extensions to MPLS 39 (Multi-Protocol Label Switching) to make it generally applicable, to 40 include - for example - control of non packet-based switching, and 41 particularly, optical switching. One consideration is to use GMPLS 42 protocols to upgrade the control plane of optical transport networks. 43 This document illustrates this process by describing those extensions 44 to GMPLS protocols that are aimed at controlling Synchronous Digital 45 Hierarchy (SDH) or Synchronous Optical Networking (SONET) networks. 46 SDH/SONET networks make good examples of this process for a variety 47 of reasons. This document high-lights extensions to GMPLS-related 48 routing protocols to disseminate information needed in transport path 49 computation and network operations, together with (G)MPLS protocol 50 extensions required for the provisioning of transport circuits. New 51 capabilities that an GMPLS control plane would bring to SDH/SONET 52 networks, such as new restoration methods and multi-layer circuit 53 establishment, are also discussed. 55 1. Introduction ................................................3 56 1.1. MPLS Overview .............................................3 57 1.2. SDH/SONET Overview ........................................4 58 1.3. The Current State of Circuit Establishment in SDH/SONET 59 Networks ..................................................7 60 1.3.1. Administrative Tasks ..................................7 61 1.3.2. Manual Operations .....................................7 62 1.3.3. Planning Tool Operation ...............................7 63 1.3.4. Circuit Provisioning ..................................8 64 1.4. Centralized Approach versus Distributed Approach ..........8 65 1.4.1. Topology Discovery and Resource Dissemination .........9 66 1.4.2. Path Computation (Route Determination).................9 67 1.4.3. Connection Establishment (Provisioning)...............10 68 1.5. Why SDH/SONET will not Disappear Tomorrow ................11 69 2. GMPLS Applied to SDH/SONET .................................12 70 2.1. Controlling the SDH/SONET Multiplex ......................12 71 2.2. SDH/SONET LSR and LSP Terminology ........................13 72 3. Decomposition of the GMPLS Circuit-Switching Problem Space .13 73 4. GMPLS Routing for SDH/SONET ................................14 74 4.1. Switching Capabilities ...................................15 75 4.1.1. Switching Granularity ................................15 76 4.1.2. Signal Concatenation Capabilities ....................16 77 4.1.3. SDH/SONET Transparency ...............................17 78 4.2. Protection ...............................................18 79 4.3. Available Capacity Advertisement .........................21 80 4.4. Path Computation .........................................22 81 5. LSP Provisioning/Signaling for SDH/SONET ...................22 82 5.1. What do we Label in SDH/SONET? Frames or Circuits?........23 83 5.2. Label Structure in SDH/SONET .............................24 84 5.3. Signaling Elements .......................................24 85 6. Summary and Conclusions ....................................26 86 7. Security Considerations ....................................27 87 8. Acknowledgments ............................................27 88 9. Author's Addresses .........................................27 89 10. References .................................................28 90 10.1. Normative References ...................................28 91 10.2. Informative References .................................28 92 11. Intellectual Property Statement ............................29 93 12. Disclaimer .................................................30 94 13. Copyright Statement ........................................30 95 14. IANA Considerations .........................................30 96 15. Acronyms ....................................................30 97 16. Acknowledgement .............................................31 99 1. Introduction 101 The CCAMP Working Group of the IETF has the goal of extending MPLS 102 [3] protocols to support multiple network layers and new services. 103 This extended MPLS, which was initially known as Multi-Protocol 104 Lambda Switching, is now better referred to as Generalized MPLS (or 105 GMPLS). 107 The GMPLS effort is, in effect, extending IP/MPLS technology to 108 control and manage lower layers. Using the same framework and 109 similar signaling and routing protocols to control multiple layers 110 can not only reduce the overall complexity of designing, deploying 111 and maintaining networks, but can also make it possible to operate 112 two contiguous layers by using either an overlay model, a peer 113 model, or an integrated model. The benefits of using a peer or an 114 overlay model between the IP layer and its underlying layer(s) will 115 have to be clarified and evaluated in the future. In the mean time, 116 GMPLS could be used for controlling each layer independently. 118 The goal of this work is to highlight how GMPLS could be used to 119 dynamically establish, maintain, and tear down SDH/SONET circuits. 120 The objective of using these extended IP/MPLS protocols is to 121 provide at least the same kinds of SDH/SONET services as are 122 provided today, but using signaling instead of provisioning via 123 centralized management to establish those services. This will allow 124 operators to propose new services, and will allow clients to create 125 SDH/SONET paths on-demand, in real-time, through the provider 126 network. We first review the essential properties of SDH/SONET 127 networks and their operations, and we show how the label concept in 128 GMPLS can be extended to the SDH/SONET case. We then look at 129 important information to be disseminated by a link state routing 130 protocol and look at the important signal attributes that need to be 131 conveyed by a label distribution protocol. Finally, we look at some 132 outstanding issues and future possibilities. 134 1.1. MPLS Overview 136 A major advantage of the MPLS architecture [3] for use as a general 137 network control plane is its clear separation between the forwarding 138 (or data) plane, the signaling (or connection control) plane, and 139 the routing (or topology discovery/resource status) plane. This 140 allows the work on MPLS extensions to focus on the forwarding and 141 signaling planes, while allowing well-known IP routing protocols to 142 be reused in the routing plane. This clear separation also allows 143 for MPLS to be used to control networks that do not have a 144 packet-based forwarding plane. 146 An MPLS network consists of MPLS nodes called Label Switch Routers 147 (LSRs) connected via circuits called Label Switched Paths (LSPs). An 148 LSP is unidirectional and could be of several different types such 149 as point-to-point, point-to-multipoint, and multipoint-to-point. 151 Border LSRs in an MPLS network act either as ingress or egress LSRs 152 depending on the direction of the traffic being forwarded. 154 Each LSP is associated with a Fowarding Equivalence Class (FEC), 155 which may be thought of as a set of packets that receive identical 156 forwarding treatment at an LSR. The simplest example of an FEC might 157 be the set of destination addresses lying in a given address range. 158 All packets that have a destination address lying within this 159 address range are forwarded identically at each LSR configured with 160 that FEC. 162 To establish an LSP, a signaling protocol (or label distribution 163 protocol) such as LDP or RSVP-TE is required. Between two adjacent 164 LSRs, an LSP is locally identified by a fixed length identifier 165 called a label, which is only significant between those two LSRs. 166 A signaling protocol is used for inter-node communication to assign 167 and maintain these labels. 169 When a packet enters an MPLS-based packet network, it is classified 170 according to its FEC and, possibly, additional rules, which together 171 determine the LSP along which the packet must be sent. For this 172 purpose, the ingress LSR attaches an appropriate label to the 173 packet, and forwards the packet to the next hop. The label may be 174 attached to a packet in different ways. For example, it may be in 175 the form of a header encapsulating the packet (the "shim" header) or 176 it may be written in the VPI/VCI field (or DLCI field) of the layer 177 2 encapsulation of the packet. In case of SDH/SONET networks, we 178 will see that a label is simply associated with a segment of a 179 circuit, and is mainly used in the signaling plane to identify this 180 segment (e.g. a time-slot) between two adjacent nodes. 182 When a packet reaches a packet LSR, this LSR uses the label as an 183 index into a forwarding table to determine the next hop and the 184 corresponding outgoing label (and, possibly, the QoS treatment to be 185 given to the packet), writes the new label into the packet, and 186 forwards the packet to the next hop. When the packet reaches the 187 egress LSR, the label is removed and the packet is forwarded using 188 appropriate forwarding, such as normal IP forwarding. We will see 189 that for a SDH/SONET network these operations do not occur in quite 190 the same way. 192 1.2. SDH/SONET Overview 194 There are currently two different multiplexing technologies in use 195 in optical networks: wavelength division multiplexing (WDM) and time 196 division multiplexing (TDM). This work focuses on TDM technology. 198 SDH and SONET are two TDM standards widely used by operators to 199 transport and multiplex different tributary signals over optical 200 links, thus creating a multiplexing structure, which we call the 201 SDH/SONET multiplex. 203 ITU-T (G.707) [4] includes both the European ETSI SDH hierarchy and 204 the USA ANSI SONET hierarchy [5]. The ETSI SDH and SONET standards 205 regarding frame structures and higher-order multiplexing are the 206 same. There are some regional differences in terminology, on the use 207 of some overhead bytes, and lower-order multiplexing. Interworking 208 between the two lower-order hierarchies is possible using gateways. 210 The fundamental signal in SDH is the STM-1 that operates at a rate 211 of about 155 Mbps, while the fundamental signal in SONET is the STS- 212 1 that operates at a rate of about 51 Mbps. These two signals are 213 made of contiguous frames that consist of transport overhead 214 (header) and payload. To solve synchronization issues, the actual 215 data is not transported directly in the payload but rather in 216 another internal frame that is allowed to float over two successive 217 SDH/SONET payloads. This internal frame is named a Virtual Container 218 (VC) in SDH and a SONET Payload Envelope (SPE) in SONET. 220 The SDH/SONET architecture identifies three different layers, each 221 of which corresponds to one level of communication between SDH/SONET 222 equipment. These are, starting with the lowest, the regenerator 223 section/section layer, the multiplex section/line layer, and (at the 224 top) the path layer. Each of these layers in turn has its own 225 overhead (header). The transport overhead of a SDH/SONET frame is 226 mainly sub-divided in two parts that contain the regenerator 227 section/section overhead and the multiplex section/line overhead. In 228 addition, a pointer (in the form of the H1, H2 and H3 bytes) 229 indicates the beginning of the VC/SPE in the payload of the overall 230 STM/STS frame. 232 The VC/SPE itself is made up of a header (the path overhead) and a 233 payload. This payload can be further subdivided into sub-elements 234 (signals) in a fairly complex way. In the case of SDH, the STM-1 235 frame may contain either one VC-4 or three multiplexed VC-3s. The 236 SONET multiplex is a pure tree, while the SDH multiplex is not a 237 pure tree, since it contains a node that can be attached to two 238 parent nodes. The structure of the SDH/SONET multiplex is shown in 239 Figure 1. In addition, we show reference points in this figure that 240 are explained in later sections. 242 The leaves of these multiplex structures are time slots (positions) 243 of different sizes that can contain tributary signals. These 244 tributary signals (e.g. E1, E3, etc) are mapped into the leaves 245 using standardized mapping rules. In general, a tributary signal 246 does not fill a time slot completely, and the mapping rules define 247 precisely how to fill it. 249 What is important for the GMPLS-based control of SDH/SONET circuits 250 is to identify the elements that can be switched from an input 251 multiplex on one interface to an output multiplex on another 252 interface. The only elements that can be switched are those that can 253 be re-aligned via a pointer, i.e. a VC-x in the case of SDH and a 254 SPE in the case of SONET. 256 xN x1 257 STM-N<----AUG<----AU-4<--VC4<------------------------------C-4 E4 258 ^ ^ 259 Ix3 Ix3 260 I I x1 261 I -----TUG-3<----TU-3<---VC-3<---I 262 I ^ C-3 DS3/E3 263 STM-0<------------AU-3<---VC-3<-- I ---------------------I 264 ^ I 265 Ix7 Ix7 266 I I x1 267 -----TUG-2<---TU-2<---VC-2<---C-2 DS2/T2 268 ^ ^ 269 I I x3 270 I I----TU-12<---VC-12<--C-12 E1 271 I 272 I x4 273 I-------TU-11<---VC-11<--C-11 DS1/T1 275 xN 276 STS-N<-------------------SPE<------------------------------DS3/T3 277 ^ 278 Ix7 279 I x1 280 I---VT-Group<---VT-6<----SPE DS2/T2 281 ^ ^ ^ 282 I I I x2 283 I I I-----VT-3<----SPE DS1C 284 I I 285 I I x3 286 I I--------VT-2<----SPE E1 287 I 288 I x4 289 I-----------VT-1.5<--SPE DS1/T1 291 Figure 1. SDH and SONET multiplexing structure and typical PDH 292 payload signals. 294 An STM-N/STS-N signal is formed from N x STM-1/STS-1 signals via 295 byte interleaving. The VCs/SPEs in the N interleaved frames are 296 independent and float according to their own clocking. To transport 297 tributary signals in excess of the basic STM-1/STS-1 signal rates, 299 the VCs/SPEs can be concatenated, i.e., glued together. In this case 300 their relationship with respect to each other is fixed in time and 301 hence this relieves, when possible, an end system of any inverse 302 multiplexing bonding processes. Different types of concatenations 303 are defined in SDH/SONET. 305 For example, standard SONET concatenation allows the concatenation 306 of M x STS-1 signals within an STS-N signal with M <= N, and M = 3, 307 12, 48, 192,...). The SPEs of these M x STS-1s can be concatenated 308 to form an STS-Mc. The STS-Mc notation is short hand for describing 309 an STS-M signal whose SPEs have been concatenated. 311 1.3. The Current State of Circuit Establishment in SDH/SONET Networks 313 In present day SDH and SONET networks, the networks are primarily 314 statically configured. When a client of an operator requests a 315 point-to-point circuit, the request sets in motion a process that 316 can last for several weeks or more. This process is composed of a 317 chain of shorter administrative and technical tasks, some of which 318 can be fully automated, resulting in significant improvements in 319 provisioning time and in operational savings. In the best case, the 320 entire process can be fully automated allowing, for example, 321 customer premise equipment (CPE) to contact a SDH/SONET switch to 322 request a circuit. Currently, the provisioning process involves the 323 following tasks. 325 1.3.1. Administrative Tasks 327 The administrative tasks represent a significant part of the 328 provisioning time. Most of them can be automated using IT 329 applications, e.g., a client still has to fill a form to request a 330 circuit. This form can be filled via a Web-based application and can 331 be automatically processed by the operator. A further enhancement is 332 to allow the client's equipment to coordinate with the operator's 333 network directly and request the desired circuit. This could be 334 achieved through a signaling protocol at the interface between the 335 client equipment and an operator switch, i.e., at the UNI, where 336 GMPLS signaling [6], [7] can be used. 338 1.3.2. Manual Operations 340 Another significant part of the time may be consumed by manual 341 operations that involve installing the right interface in the CPE 342 and installing the right cable or fiber between the CPE and the 343 operator switch. This time can be especially significant when a 344 client is in a different time zone than the operator's main office. 345 This first-time connection time is frequently accounted for in the 346 overall establishment time. 348 1.3.3. Planning Tool Operation 350 Another portion of the time is consumed by planning tools that run 351 simulations using heuristic algorithms to find an optimized 352 placement for the required circuits. These planning tools can 353 require a significant running time, sometimes on the order of days. 355 These simulations are, in general, executed for a set of demands for 356 circuits, i.e., a batch mode, to improve the optimality of network 357 resource usage and other parameters. Today, we do not really have a 358 means to reduce this simulation time. On the contrary, to support 359 fast, on-line, circuit establishment, this phase may be invoked more 360 frequently, i.e., we will not "batch up" as many connection 361 requests before we plan out the corresponding circuits. This means 362 that the network may need to be re-optimized periodically, implying 363 that the signaling should support re-optimization with minimum 364 impact to existing services. 366 1.3.4. Circuit Provisioning 368 Once the first three steps discussed above have been completed, the 369 operator must provision the circuits using the outputs of the 370 planning process. The time required for provisioning varies greatly. 371 It can be fairly short, on the order of a few minutes, if the 372 operators already have tools that help them to do the provisioning 373 over heterogeneous equipment. Otherwise, the process can take days. 374 Developing these tools for each new piece of equipment and each 375 vendor is a significant burden on the service provider. A 376 standardized interface for provisioning, such as GMPLS signaling, 377 could significantly reduce or eliminate this development burden. In 378 general, provisioning is a batched activity, i.e., a few times per 379 week an operator provisions a set of circuits. GMPLS will reduce 380 this provisioning time from a few minutes to a few seconds and could 381 help to transform this periodic process into a real-time process. 383 When a circuit is provisioned, it is not delivered directly to a 384 client. Rather, the operator first tests its performance and 385 behavior and if successful, delivers the circuit to the client. This 386 testing phase lasts, in general, for up to 24 hours. The operator 387 installs test equipment at each end and uses pre-defined test 388 streams to verify performance. If successful, the circuit is 389 officially accepted by the client. To speed up the verification 390 (sometimes known as "proving") process, it would be necessary to 391 support some form of automated performance testing. 393 1.4. Centralized Approach versus Distributed Approach 395 Whether a centralized approach or a distributed approach will be 396 used to control SDH/SONET networks is an open question, since each 397 approach has its merits. The application of GMPLS to SDH/SONET 398 networks does not preclude either model, although GMPLS is itself a 399 distributed technology. 401 The basic tradeoff between the centralized and distributed 402 approaches is that of complexity of the network elements versus that 403 of the network management system (NMS). Since adding functionality 404 to existing SDH/SONET network elements may not be possible, a 405 centralized approach may be needed in some cases. The main issue 406 facing centralized control via an NMS is one of scalability. For 407 instance, this approach may be limited in the number of network 408 elements that can be managed (e.g., one thousand). It is, therefore, 409 quite common for operators to deploy several NMS in parallel at 410 the Network Management Layer, each managing a different zone. In 411 that case, however, a Service Management Layer must be built on the 412 top of several individual NMS to take care of end-to-end on-demand 413 services. On the other hand, in a complex and/or dense network, 414 restoration could be faster with a distributed approach than with a 415 centralized approach. 417 Let's now look at how the major control plane functional components 418 are handled via the centralized and distributed approaches: 420 1.4.1. Topology Discovery and Resource Dissemination 422 Currently an NMS maintains a consistent view of all the networking 423 layers under its purview. This can include the physical topology, 424 such as information about fibers and ducts. Since most of this 425 information is entered manually, it remains error prone. 427 A link state GMPLS routing protocol, on the other hand, could 428 perform automatic topology discovery and disseminate the topology 429 as well as resource status. This information would be available to 430 all nodes in the network, and hence also the NMS. Hence one can 431 look at a continuum of functionality between manually provisioned 432 topology information (of which there will always be some) and fully 433 automated discovery and dissemination as in a link state protocol. 434 Note that, unlike the IP datagram case, a link state routing 435 protocol applied to the SDH/SONET network does not have any service 436 impacting implications. This is because in the SDH/SONET case, the 437 circuit is source-routed (so there can be no loops), and no traffic 438 is transmitted until a circuit has been established, and an 439 acknowledgement received at the source. 441 1.4.2. Path Computation (Route Determination) 443 In the SDH/SONET case, unlike the IP datagram case, there is no need 444 for network elements to all perform the same path calculation [9]. 445 In addition, path determination is an area for vendors to provide a 446 potentially significant value addition in terms of network 447 efficiency, reliability, and service differentiation. In this sense, 448 a centralized approach to path computation may be easier to operate 449 and upgrade. For example, new features such as new types of path 450 diversity or new optimization algorithms can be introduced with a 451 simple NMS software upgrade. On the other hand, updating switches 452 with new path computation software is a more complicated task. In 453 addition, many of the algorithms can be fairly computationally 454 intensive and may be completely unsuitable for the embedded 455 processing environment available on most switches. In restoration 456 scenarios, the ability to perform a reasonably sophisticated level 457 of path computation on the network element can be particularly 458 useful for restoring traffic during major network faults. 460 1.4.3. Connection Establishment (Provisioning) 462 The actual setting up of circuits, i.e., a coupled collection of 463 cross connects across a network, can be done either via the NMS 464 setting up individual cross connects or via a "soft permanent LSP" 465 (SPLSP) type approach. In the SPLSP approach, the NMS may just kick 466 off the connection at the "ingress" switch with GMPLS signaling 467 setting up the connection from that point onward. Connection 468 establishment is the trickiest part to distribute, however, since 469 errors in the connection setup/tear down process are service 470 impacting. 472 The table below compares the two approaches to connection 473 establishment. 475 Distributed approach Centralized approach 477 Packet-based control plane Management plane like TMN or 478 (like GMPLS or PNNI) useful? SNMP 479 Do we really need it? Being Always needed! Already there, 480 added/specified by several proven and understood. 481 standardization bodies 483 High survivability (e.g. in Potential single point(s) of 484 case of partition) failure 486 Distributed load Bottleneck: #requests and 487 actions to/from NMS 489 Individual local routing Centralized routing decision, 490 decision can be done per block of 491 requests 492 Routing scalable as for the Assumes a few big 493 Internet administrative domains 495 Complex to change routing Very easy local upgrade (non 496 protocol/algorithm intrusive) 498 Requires enhanced routing Better consistency 499 protocol (traffic 500 engineering) 502 Ideal for inter-domain Not inter-domain friendly 504 Suitable for very dynamic For less dynamic demands 505 demands (longer lived) 507 Probably faster to restore, Probably slower to restore,but 509 but more difficult to have could effect reliable 510 reliable restoration. restoration. 512 High scalability Limited scalability: #nodes, 513 (hierarchical) links, circuits, messages 515 Planning (optimization) Planning is a background 516 harder to achieve centralized activity 518 Easier future integration 519 with other control plane 520 layers 522 Table 1. Qualitative comparison between centralized and distributed 523 approaches. 525 1.5. Why SDH/SONET will not Disappear Tomorrow 527 As IP traffic becomes the dominant traffic transported over the 528 transport infrastructure, it is useful to compare the statistical 529 multiplexing of IP with the time division multiplexing of SDH and 530 SONET. 532 Consider, for instance, a scenario where IP over WDM is used 533 everywhere and lambdas are optically switched. In such a case, a 534 carrier's carrier would sell dynamically controlled lambdas with 535 each customers building their own IP backbones over these lambdas. 537 This simple model implies that a carrier would sell lambdas instead 538 of bandwidth. The carrier's goal will be to maximize the number of 539 wavelengths/lambdas per fiber, with each customer having to fully 540 support the cost for each end-to-end lambda whether or not the 541 wavelength is fully utilized. Although, in the near future, we may 542 have technology to support up to several hundred lambdas per fiber, 543 a world where lambdas are so cheap and abundant that every 544 individual customer buys them, from one point to any other point, 545 appears an unlikely scenario today. 547 More realistically, there is still room for a multiplexing 548 technology that provides circuits with a lower granularity than a 549 wavelength. (Not everyone needs a minimum of 10 Gbps or 40 Gbps per 550 circuit, and IP does not yet support all telecom applications in 551 bulk efficiently.) 553 SDH and SONET possess a rich multiplexing hierarchy that permits 554 fairly fine granularity and that provides a very cheap and simple 555 physical separation of the transported traffic between circuits, 556 i.e., QoS. Moreover, even IP datagrams cannot be transported 557 directly over a wavelength. A framing or encapsulation is always 558 required to delimit IP datagrams. The Total Length field of an IP 559 header cannot be trusted to find the start of a new datagram, since 560 it could be corrupted and would result in a loss of synchronization. 561 The typical framing used today for IP over DWDM is defined in 562 RFC1619/RFC2615 and known as POS (Packet Over SDH/SONET), i.e., IP 563 over PPP (in HDLC-like format) over SDH/SONET. SDH and SONET are 564 actually efficient encapsulations for IP. For instance, with an 565 average IP datagram length of 350 octets, an IP over GBE 566 encapsulation using an 8B/10B encoding results in 28% overhead, an 567 IP/ATM/SDH encapsulation results in 22% overhead and an IP/PPP/SDH 568 encapsulation results in only 6% overhead. 570 Any encapsulation of IP over WDM should, in the data plane, at least 571 provide error monitoring capabilities (to detect signal 572 degradation); error correction capabilities, such as FEC (Forward 573 Error Correction) that are particularly needed for ultra long haul 574 transmission; sufficient timing information, to allow robust 575 synchronization (that is, to detect the beginning of a packet). In 576 the case where associated signaling is used (that is the control and 577 data plane topologies are congruent) the encapsulation should also 578 provide the capacity to transport signaling, routing and management 579 messages, in order to control the optical switches. Rather SDH and 580 SONET cover all these aspects natively, except FEC, which tends to 581 be supported in a proprietary way. (We note, however, that 582 associated signaling is not a requirement for the GMPLS-based 583 control of SDH/SONET networks. Rather, it is just one option. Non 584 associated signaling, as would happen with an out-of-band control 585 plane network is another equally valid option.) 587 Since IP encapsulated in SDH/SONET is efficient and widely used, the 588 only real difference between an IP over WDM network and an IP over 589 SDH over WDM network is the layers at which the switching or 590 forwarding can take place. In the first case, it can take place at 591 the IP and optical layers. In the second case, it can take place at 592 the IP, SDH/SONET, and optical layers. 594 Almost all transmission networks today are based on SDH or SONET. 595 A client is connected either directly through an SDH or SONET 596 interface or through a PDH interface, the PDH signal being 597 transported between the ingress and the egress interfaces over SDH 598 or SONET. What we are arguing here is that it makes sense to do 599 switching or forwarding at all these layers. 601 2. GMPLS Applied to SDH/SONET 603 2.1. Controlling the SDH/SONET Multiplex 605 Controlling the SDH/SONET multiplex implies deciding which of the 606 different switchable components of the SDH/SONET multiplex do we 607 wish to control using GMPLS. Essentially, every SDH/SONET element 608 that is referenced by a pointer can be switched. These component 609 signals are the VC-4, VC-3, VC-2, VC-12 and VC-11 in the SDH case; 610 and the VT and STS SPEs in the SONET case. The SPEs in SONET do not 611 have individual names, although they can be referred to simply as 612 VT-N SPEs. We will refer to them by identifying the structure that 613 contains them, namely STS-1, VT-6, VT-3, VT-2 and VT-1.5. 615 The STS-1 SPE corresponds to a VC-3, a VT-6 SPE corresponds to a VC- 616 2, a VT-2 SPE corresponds to a VC-12, and a VT-1.5 SPE corresponds 617 to a VC-11. The SONET VT-3 SPE has no correspondence in SDH, however 618 SDH's VC-4 corresponds to SONET's STS-3c SPE. 620 In addition, it is possible to concatenate some of the structures 621 that contain these elements to build larger elements. For instance, 622 SDH allows the concatenation of X contiguous AU-4s to build a VC-4- 623 Xc and of m contiguous TU-2s to build a VC-2-mc. In that case, a VC- 624 4-Xc or a VC-2-mc can be switched and controlled by GMPLS. SDH also 625 defines virtual (non-contiguous) concatenation of TU- 2s, however 626 in that case each constituent VC-2 is switched individually. 628 2.2. SDH/SONET LSR and LSP Terminology 630 Let a SDH or SONET Terminal Multiplexer (TM), Add-Drop Multiplexer 631 (ADM) or cross-connect (i.e. a switch) be called an SDH/SONET LSR. A 632 SDH/SONET path or circuit between two SDH/SONET LSRs now becomes a 633 GMPLS LSP. An SDH/SONET LSP is a logical connection between the 634 point at which a tributary signal (client layer) is adapted into its 635 virtual container, and the point at which it is extracted from its 636 virtual container. 638 To establish such an LSP, a signaling protocol is required to 639 configure the input interface, switch fabric, and output interface 640 of each SDH/SONET LSR along the path. An SDH/SONET LSP can be 641 point-to-point or point-to-multipoint, but not multipoint-to-point, 642 since no merging is possible with SDH/SONET signals. 644 To facilitate the signaling and setup of SDH/SONET circuits, an 645 SDH/SONET LSR must, therefore, identify each possible signal 646 individually per interface, since each signal corresponds to a 647 potential LSP that can be established through the SDH/SONET LSR. It 648 turns out, however, that not all SDH signals correspond to an LSP 649 and therefore not all of them need be identified. In fact, only 650 those signals that can be switched need identification. 652 3. Decomposition of the GMPLS Circuit-Switching Problem Space 654 Although those familiar with GMPLS may be familiar with its 655 application in a variety of application areas, e.g., ATM, Frame 656 Relay, and so on, here we quickly review its decomposition when 657 applied to the optical switching problem space. 659 (i) Information needed to compute paths must be made globally 660 available throughout the network. Since this is done via the link 661 state routing protocol, any information of this nature must either 662 be in the existing link state advertisements (LSAs) or the LSAs must 663 be supplemented to convey this information. For example, if it is 664 desirable to offer different levels of service in a network based on 665 whether a circuit is routed over SDH/SONET lines that are ring 666 protected versus being routed over those that are not ring protected 667 (differentiation based on reliability), the type of protection on a 668 SDH/SONET line would be an important topological parameter that 669 would have to be distributed via the link state routing protocol. 671 (ii) Information that is only needed between two "adjacent" switches 672 for the purposes of connection establishment is appropriate for 673 distribution via one of the label distribution protocols. In fact, 674 this information can be thought of as the "virtual" label. For 675 example, in SONET networks, when distributing information to 676 switches concerning an end-to-end STS-1 path traversing a network, 677 it is critical that adjacent switches agree on the multiplex entry 678 used by this STS-1 (but this information is only of local 679 significance between those two switches). Hence, the multiplex entry 680 number in this case can be used as a virtual label. Note that the 681 label is virtual, in that it is not appended to the payload in any 682 way, but it is still a label in the sense that it uniquely 683 identifies the signal locally on the link between the two switches. 685 (iii) Information that all switches in the path need to know about a 686 circuit will also be distributed via the label distribution 687 protocol. Examples of such information include bandwidth, priority, 688 and preemption for instance. 690 (iv) Information intended only for end systems of the connection. 691 Some of the payload type information in may fall into this category. 693 4. GMPLS Routing for SDH/SONET 695 Modern SDH/SONET transport networks excel at interoperability in the 696 performance monitoring (PM) and fault management (FM) areas [10], 697 [11]. They do not, however, interoperate in the areas of topology 698 discovery or resource status. Although link state routing protocols, 699 such as IS-IS and OSPF, have been used for some time in the IP world 700 to compute destination-based next hops for routes (without routing 701 loops), they are particularly valuable for providing timely topology 702 and network status information in a distributed manner, i.e., at any 703 network node. If resource utilization information is disseminated 704 along with the link status (as done in ATM's PNNI routing protocol) 705 then a very complete picture of network status is available to a 706 network operator for use in planning, provisioning and operations. 708 The information needed to compute the path a connection will take 709 through a network is important to distribute via the routing 710 protocol. In the TDM case, this information includes, but is not 711 limited to: the available capacity of the network links, the 712 switching and termination capabilities of the nodes and interfaces, 713 and the protection properties of the link. This is what is being 714 proposed in the GMPLS extensions to IP routing protocols [12], [13], 715 [14]. 717 When applying routing to circuit switched networks it is useful to 718 compare and contrast this situation with the datagram routing case 720 [15]. In the case of routing datagrams, all routes on all nodes 721 must be calculated exactly the same to avoid loops and "black 722 holes". In circuit switching, this is not the case since routes are 723 established per circuit and are fixed for that circuit. Hence, 724 unlike the datagram case, routing is not service impacting in the 725 circuit switched case. This is helpful, because, to accommodate the 726 optical layer, routing protocols need to be supplemented with new 727 information, much more than the datagram case. This information is 728 also likely to be used in different ways for implementing different 729 user services. Due to the increase in information transferred in 730 the routing protocol, it may be useful to separate the relatively 731 static parameters concerning a link from those that may be subject 732 to frequent changes. The current GMPLS routing extensions 733 [12], [13], [14] do not make such a separation, however. 735 Indeed, from the carriers' perspective, the up-to-date dissemination 736 of all link properties is essential and desired, and the use of a 737 link-state routing protocol to distribute this information provides 738 timely and efficient delivery. If GMPLS-based networks got to the 739 point that bandwidth updates happen very frequently, it makes sense, 740 from an efficiency point of view, to separate them out for update. 741 This situation is not yet seen in actual networks; however, if GMPLS 742 signaling is put into widespread use then the need could arise. 744 4.1. Switching Capabilities 746 The main switching capabilities that characterize a SDH/SONET end 747 system and thus need to be advertised via the link state routing 748 protocol are: the switching granularity, supported forms of 749 concatenation, and the level of transparency. 751 4.1.1. Switching Granularity 753 From references [4], [5] and the overview section on SDH/SONET we 754 see that there are a number of different signals that compose the 755 SDH/SONET hierarchies. Those signals that are referenced via a 756 pointer, i.e., the VCs in SDH and the SPEs in SONET are those that 757 will actually be switched within a SDH/SONET network. These signals 758 are subdivided into lower order signals and higher order signals as 759 shown in Table 2. 761 Table 2. SDH/SONET switched signal groupings. 763 Signal Type SDH SONET 765 Lower Order VC-11, VC-12, VC-2 VT-1.5 SPE, VT-2 SPE, 766 VT-3 SPE, VT-6 SPE 768 Higher VC-3, VC-4 STS-1 SPE, STS-3c SPE 769 Order 771 Manufacturers today differ in the types of switching capabilities 772 their systems support. Many manufacturers today switch signals 773 starting at VC-4 for SDH or STS-1 for SONET (i.e. the basic frame) 774 and above (see Section 5.1.2 on concatenation), but they do not 775 switch lower order signals. Some of them only allow the switching of 776 entire aggregates (concatenated or not) of signals such as 16 VC-4s, 777 i.e. a complete STM-16, and nothing finer. Some go down to the VC-3 778 level for SDH. Finally, some offer highly integrated switches that 779 switch at the VC-3/STS-1 level down to lower order signals such as 780 VC-12s. In order to cover the needs of all manufacturers and 781 operators, GMPLS signaling ([6], [7]) covers both higher order and 782 lower order signals. 784 4.1.2. Signal Concatenation Capabilities 786 As stated in the SDH/SONET overview, to transport tributary signals 787 with rates in excess of the basic STM-1/STS-1 signal, the VCs/SPEs 788 can be concatenated, i.e., glued together. Different types of 789 concatenations are defined: contiguous standard concatenation, 790 arbitrary concatenation, and virtual concatenation with different 791 rules concerning their size, placement, and binding. 793 Standard SONET concatenation allows the concatenation of M x STS-1 794 signals within an STS-N signal with M <= N, and M = 3, 12, 48, 192, 795 ...). The SPEs of these M x STS-1s can be concatenated to form an 796 STS-Mc. The STS-Mc notation is short hand for describing an STS-M 797 signal whose SPEs have been concatenated. The multiplexing 798 procedures for SDH and SONET are given in references [4] and [5], 799 respectively. Constraints are imposed on the size of STS-Mc signals, 800 i.e., they must be a multiple of 3, and on their starting location 801 and interleaving. 803 This has the following advantages: (a) restriction to multiples of 3 804 helps with SDH compatibility (there is no STS-1 equivalent signal in 805 SDH); (b) the restriction to multiples of 3 reduces the number of 806 connection types; (c) the restriction on the placement and 807 interleaving could allow more compact representation of the "label"; 809 The major disadvantages of these restrictions are: 810 (a) Limited flexibility in bandwidth assignment (somewhat inhibits 811 finer grained traffic engineering). (b) The lack of flexibility in 812 starting time slots for STS-Mc signals and in their interleaving 813 (where the rest of the signal gets put in terms of STS-1 slot 814 numbers) leads to the requirement for re-grooming (due to bandwidth 815 fragmentation). 817 Due to these disadvantages some SONET framer manufacturers now 818 support "flexible" or arbitrary concatenation, i.e., no restrictions 819 on the size of an STS-Mc (as long as M <= N) and no constraints on 820 the STS-1 timeslots used to convey it, i.e., the signals can use any 821 combination of available time slots. 823 Standard and flexible concatenations are network services, while 824 virtual concatenation is a SDH/SONET end-system service approved by 825 the Committee T1 of ANSI [5] and the ITU-T [4]. The essence of this 826 service is to have SDH/SONET end systems "glue" together the VCs or 827 SPEs of separate signals rather than requiring that the signals be 828 carried through the network as a single unit. In one example of 829 virtual concatenation, two end systems supporting this feature could 830 essentially "inverse multiplex" two STS-1s into a STS-1-2v for the 831 efficient transport of 100 Mbps Ethernet traffic. Note that this 832 inverse multiplexing process (or virtual concatenation) can be 833 significantly easier to implement with SDH/SONET than packet switched 834 circuits, because ensuring that timing and in-order frame delivery is 835 preserved may be simpler to establish using SDH/SONET rather than 836 packet switched circuits, where more sophisticated techniques may be 837 needed. 839 Since virtual concatenation is provided by end systems, it is 840 compatible with existing SDH/SONET networks. Virtual concatenation 841 is defined for both higher order signals and low order signals. 842 Table 3 shows the nomenclature and capacity for several lower-order 843 virtually concatenated signals contained within different 844 higher-order signals. 846 Table 3 Capacity of Virtually Concatenated VTn-Xv (9/G.707) 848 Carried In X Capacity In steps 849 of 851 VT1.5/ STS-1/VC-3 1 to 28 1600kbit/s to 1600kbit/s 852 VC-11-Xv 44800kbit/s 854 VT2/ STS-1/VC-3 1 to 21 2176kbit/s to 2176kbit/s 855 VC-12-Xv 45696kbit/s 857 VT1.5/ STS-3c/VC-4 1 to 64 1600kbit/s to 1600kbit/s 858 VC-11-Xv 102400kbit/s 860 VT2/ STS-3c/VC-4 1 to 63 2176kbit/s to 2176kbit/s 861 VC-12-Xv 137088kbit/s 863 4.1.3. SDH/SONET Transparency 865 The purposed of SDH/SONET is to carry its payload signals in a 866 transparent manner. This can include some of the layers of SONET 867 itself. For example, situations where the path overhead can never be 868 touched, since it actually belongs to the client. This was another 869 reason for not coding an explicit label in the SDH/SONET path 870 overhead. It may be useful to transport, multiplex and/or switch 871 lower layers of the SONET signal transparently. 873 As mentioned in the introduction, SONET overhead is broken into 874 three layers: Section, Line and Path. Each of these layers is 875 concerned with fault and performance monitoring. The Section 876 overhead is primarily concerned with framing, while the Line 877 overhead is primarily concerned with multiplexing and protection. To 878 perform pipe multiplexing (that is, multiplexing of 50 Mbps or 150 879 Mbps chunks), a SONET network element should be line terminating. 880 However, not all SONET multiplexers/switches perform SONET pointer 881 adjustments on all the STS-1s contained within a higher order SONET 882 signal passing through them. Alternatively, if they perform pointer 883 adjustments, they do not terminate the line overhead. For example, a 884 multiplexer may take four SONET STS-48 signals and multiplex them 885 onto an STS-192 without performing standard line pointer adjustments 886 on the individual STS-1s. This can be looked at as a service since 887 it may be desirable to pass SONET signals, like an STS-12 or STS-48, 888 with some level of transparency through a network and still take 889 advantage of TDM technology. Transparent multiplexing and switching 890 can also be viewed as a constraint, since some multiplexers and 891 switches may not switch with as fine a granularity as others. Table 892 4 summarizes the levels of SDH/SONET transparency. 894 Table 4. SDH/SONET transparency types and their properties. 896 Transparency Type Comments 898 Path Layer (or Line Standard higher order SONET path 899 Terminating) switching. Line overhead is terminated 900 or modified. 902 Line Level (or Section Preserves line overhead and switches 903 Terminating) the entire line multiplex as a whole. 904 Section overhead is terminated or 905 modified. 907 Section layer Preserves all section overhead, 908 Basically does not modify/terminate 909 any of the SDH/SONET overhead bits. 911 4.2. Protection 913 SONET and SDH networks offer a variety of protection options at both 914 the SONET line (SDH multiplex section) and SDH/SONET path level 915 [10], [11]. Standardized SONET line level protection techniques 916 include: Linear 1+1 and linear 1:N automatic protection switching 917 (APS) and both two-fiber and four-fiber bi-directional line switched 918 rings (BLSRs). At the path layer, SONET offers uni-directional path 919 switched ring protection. Likewise, standardized SDH multiplex 920 section protection techniques include linear 1+1 and 1:N automatic p 921 protection switching and both two-fiber and four-fiber bi-directional 922 MS-SPRings (Multiplex Section-Shared Protection Rings). 924 At the path layer, SDH offers SNCP (sub-network connection 925 protection) ring protection. 927 Both ring and 1:N line protection also allow for "extra traffic" to 928 be carried over the protection line when that line is not being 929 used, i.e., when it is not carrying traffic for a failed working 930 line. These protection methods are summarized in Table 5. It should 931 be noted that these protection methods are completely separate from 932 any GMPLS layer protection or restoration mechanisms. 934 Table 5. Common SDH/SONET protection mechanisms. 936 Protection Type Extra Comments 937 Traffic 938 Optionally 939 Supported 941 1+1 No Requires no coordination 942 Unidirectional between the two ends of the 943 circuit. Dedicated 944 protection line. 946 1+1 Bi- No Coordination via K byte 947 directional protocol. Lines must be 948 consistently configured. 949 Dedicated protection line. 951 1:1 Yes Dedicated protection. 953 1:N Yes One Protection line shared 954 by N working lines 956 4F-BLSR (4 Yes Dedicated protection, with 957 fiber bi- alternative ring path. 958 directional 959 line switched 960 ring) 962 2F-BLSR (2 Yes Dedicated protection, with 963 fiber bi- alternative ring path 964 directional 965 line switched 966 ring) 968 UPSR (uni- No Dedicated protection via 969 directional alternative ring path. 970 path switched Typically used in access 971 ring) networks. 973 It may be desirable to route some connections over lines that 974 support protection of a given type, while others may be routed over 975 unprotected lines, or as "extra traffic" over protection lines. 976 Also, to assist in the configuration of these various protection 977 methods it can be extremely valuable to advertise the link 978 protection attributes in the routing protocol, as is done in the 979 current GMPLS routing protocols. For example, suppose that a 1:N 980 protection group is being configured via two nodes. One must make 981 sure that the lines are "numbered the same" with respect to both 982 ends of the connection or else the APS (K1/K2 byte) protocol will 983 not correctly operate. 985 Table 6. Parameters defining protection mechanisms. 987 Protection Comments 988 Related Link 989 Information 991 Protection Type Indicates which of the protection types 992 delineated in Table 5. 994 Protection Indicates which of several protection 995 Group Id groups (linear or ring) that a node belongs 996 to. Must be unique for all groups that a 997 node participates in 999 Working line Important in 1:N case and to differentiate 1000 number between working and protection lines 1002 Protection line Used to indicate if the line is a 1003 number protection line. 1005 Extra Traffic Yes or No 1006 Supported 1008 Layer If this protection parameter is specific to 1009 SONET then this parameter is unneeded, 1010 otherwise it would indicate the signal 1011 layer that the protection is applied. 1013 An open issue concerning protection is the extent of information 1014 regarding protection that must be disseminated. The contents of 1015 Table 6 represent one extreme while a simple enumerated list of: 1016 Extra-Traffic/Protection line, Unprotected, Shared (1:N)/Working 1017 line, Dedicated (1:1, 1+1)/Working Line, Enhanced (Ring) /Working 1018 Line, represents the other. 1020 There is also a potential implication for link bundling [16], [18] 1021 that is, for each link, the routing protocol could advertise whether 1022 that link is a working or protection link and possibly some 1023 parameters from Table 6. A possible drawback of this scheme is that 1024 the routing protocol would be burdened with advertising properties 1025 even for those protection links in the network that could not, in 1026 fact, be used for routing working traffic, e.g., dedicated 1027 protection links. An alternative method would be to bundle the 1028 working and protection links together, and advertise the bundle 1029 instead. Now, for each bundled link, the protocol would have to 1030 advertise the amount of bandwidth available on its working links, as 1031 well as the amount of bandwidth available on those protection links 1032 within the bundle that were capable of carrying "extra traffic." 1033 This would reduce the amount of information to be advertised. An 1034 issue here would be to decide which types of working and protection 1035 links to bundle together. For instance, it might be preferable to 1036 bundle working links (and their corresponding protection links) that 1037 are "shared" protected separately from working links that are 1038 "dedicated" protected. 1040 4.3. Available Capacity Advertisement 1042 Each SDH/SONET LSR must maintain an internal table per interface 1043 that indicates each signal in the multiplex structure that is 1044 allocated at that interface. This internal table is the most 1045 complete and accurate view of the link usage and available capacity. 1047 For use in path computation, this information needs to be advertised 1048 in some way to all others SDH/SONET LSRs in the same domain. There 1049 is a trade off to be reached concerning: the amount of detail in the 1050 available capacity information to be reported via a link state 1051 routing protocol, the frequency or conditions under which this 1052 information is updated, the percentage of connection establishments 1053 that are unsuccessful on their first attempt due to the granularity 1054 of the advertised information, and the extent to which network 1055 resources can be optimized. There are different levels of 1056 summarization that are being considered today for the available 1057 capacity information. At one extreme, all signals that are allocated 1058 on an interface could be advertised, while at the other extreme, a 1059 single aggregated value of the available bandwidth per link could be 1060 advertised. 1062 Consider first the relatively simple structure of SONET and its most 1063 common current and planned usage. DS1s and DS3s are the signals most 1064 often carried within a SONET STS-1. Either a single DS3 occupies 1065 the STS-1 or up to 28 DS1s (4 each within the 7 VT groups) are 1066 carried within the STS-1. With a reasonable VT1.5 placement 1067 algorithm within each node it may be possible to just report on 1068 aggregate bandwidth usage in terms of number of whole STS-1s 1069 (dedicated to DS3s) used and the number of STS-1s dedicated to 1070 carrying DS1s allocated for this purpose. This way a network 1071 optimization program could try to determine the optimal placement of 1072 DS3s and DS1s to minimize wasted bandwidth due to half-empty STS-1s 1073 at various places within the transport network. Similarly consider 1074 the set of super rate SONET signals (STS-Nc). If the links between 1075 the two switches support flexible concatenation then the reporting 1076 is particularly straightforward since any of the STS-1s within an 1077 STS-M can be used to comprise the transported STS-Nc. However, if 1078 only standard concatenation is supported, then reporting gets 1079 trickier since there are constraints on where the STS-1s can be 1080 placed. SDH has still more options and constraints, hence it is not 1081 yet clear which is the best way to advertise bandwidth resource 1082 availability/usage in SDH/SONET. At present, the GMPLS routing 1083 protocol extensions define minimum and maximum values for available 1084 bandwidth, which allows a remote node to make some deductions about 1085 the amount of capacity available at a remote link and the types of 1086 signals it can accommodate. However, due to the multiplexed nature 1087 of the signals, reporting of bandwidth particular to signal types 1088 rather than as a single aggregate bit rate may be desirable. For 1089 details on why this may be the case, we refer the reader to ITU-T 1090 publications G.7715.1 [19] and to Chapter 12 of [20]. 1092 4.4. Path Computation 1094 Although a link state routing protocol can be used to obtain network 1095 topology and resource information, this does not imply the use of an 1096 "open shortest path first" route [9]. The path must be open in the 1097 sense that the links must be capable of supporting the desired 1098 signal type and that capacity must be available to carry the signal. 1099 Other constraints may include hop count, total delay (mostly 1100 propagation), and underlying protection. In addition, it may be 1101 desirable to route traffic in order to optimize overall network 1102 capacity, or reliability, or some combination of the two. Dikstra's 1103 algorithm computes the shortest path with respect to link weights 1104 for a single connection at a time. This can be much different than 1105 the paths that would be selected in response to a request to set up 1106 a batch of connections between a set of endpoints in order to 1107 optimize network link utilization. One can think of this along the 1108 lines of global or local optimization of the network in time. 1110 Due to the complexity of some of the connection routing algorithms 1111 (high dimensionality, non-linear integer programming problems) and 1112 various criteria by which one may optimize a network, it may not be 1113 possible or desirable to run these algorithms on network nodes. 1114 However, it may still be desirable to have some basic path 1115 computation ability running on the network nodes, particularly for 1116 use during restoration situations. Such an approach is in line with 1117 the use of GMPLS for traffic engineering, but is much different than 1118 typical OSPF or IS-IS usage where all nodes must run the same 1119 routing algorithm. 1121 5. LSP Provisioning/Signaling for SDH/SONET 1123 Traditionally, end-to-end circuit connections in SDH/SONET networks 1124 have been set up via network management systems (NMSs), which issue 1125 commands (usually under the control of a human operator) to the 1126 various network elements involved in the circuit, via an equipment 1127 vendor's element management system (EMS). Very little multi-vendor 1128 interoperability has been achieved via management systems. Hence, 1129 end-to-end circuits in a multi-vendor environment typically require 1130 the use of multiple management systems and the infamous configuration 1131 via "yellow sticky notes". As discussed in Section 3, a common 1132 signaling protocol - such as RSVP with TE extensions or CR-LDP - 1133 appropriately extended for circuit switching applications, could 1134 therefore help to solve these interoperability problems. In this 1135 section, we examine the various components involved in the automated 1136 provisioning of SDH/SONET LSPs. 1138 5.1. What do we Label in SDH/SONET? Frames or Circuits? 1140 GMPLS was initially introduced to control asynchronous technologies 1141 like IP, where a label was attached to each individual block of 1142 data, such as an IP packet or a Frame Relay frame. SONET and SDH, 1143 however, are synchronous technologies that define a multiplexing 1144 structure (see Section 3), which we referred to as the SDH (or 1145 SONET) multiplex. This multiplex involves a hierarchy of signals, 1146 lower order signals embedded within successive higher order ones 1147 (see Fig. 1). Thus, depending on its level in the hierarchy, each 1148 signal consists of frames that repeat periodically, with a certain 1149 number of byte time slots per frame. 1151 The question then arises: is it these frames that we label in GMPLS? 1152 It will be seen in what follows that each SONET or SDH "frame" 1153 need not have its own label, nor is it necessary to switch frames 1154 individually. Rather, the unit that is switched is a "flow" 1155 comprised of a continuous sequence of time slots that appear at a 1156 given position in a frame. That is, we switch an individual SONET or 1157 SDH signal, and a label associated with each given signal. 1159 For instance, the payload of an SDH STM-1 frame does not fully 1160 contain a complete unit of user data. In fact, the user data is 1161 contained in a virtual container (VC) that is allowed to float over 1162 two contiguous frames for synchronization purposes. The H1-H2-H3 1163 Au-n pointer bytes in the SDH overhead indicates the beginning of the 1164 VC in the payload. Thus, frames are now inter-related, since each 1165 consecutive pair may share a common virtual container. From the 1166 point of view of GMPLS, therefore, it is not the successive frames 1167 that are treated independently or labeled, but rather the entire 1168 user signal. An identical argument applies to SONET. 1170 Observe also that the GMPLS signaling used to control the SDH/SONET 1171 multiplex must honor its hierarchy. In other words, the SDH/SONET 1172 layer should not be viewed as homogeneous and flat, because this 1173 would limit the scope of the services that SDH/SONET can provide. 1174 Instead, GMPLS tunnels should be used to dynamically and 1175 hierarchically control the SDH/SONET multiplex. For example, one 1176 unstructured VC-4 LSP may be established between two nodes, and 1177 later lower order LSPs (e.g. VC-12) may be created within that 1178 higher order LSP. This VC-4 LSP can, in fact, be established 1179 between two non-adjacent internal nodes in an SDH network, and later 1180 advertised by a routing protocol as a new (virtual) link called a 1181 Forwarding Adjacency (FA) [17]. 1183 A SDH/SONET-LSR will have to identify each possible signal 1184 individually per interface to fulfill the GMPLS operations. In order 1185 to stay transparent the LSR obviously should not touch the SDH/SONET 1186 overheads; this is why an explicit label is not encoded in the 1187 SDH/SONET overheads. Rather, a label is associated with each 1188 individual signal. This approach is similar to the one considered 1189 for lambda switching, except that it is more complex, since SONET 1190 and SDH define a richer multiplexing structure. Therefore a label 1191 is associated with each signal, and is locally unique for each 1192 signal at each interface. This signal could, and will most probably, 1193 occupy different time-slots at different interfaces. 1195 5.2. Label Structure in SDH/SONET 1197 The signaling protocol used to establish an SDH/SONET LSP must have 1198 specific information elements in it to map a label to the particular 1199 signal type that it represents, and to the position of that signal 1200 in the SDH/SONET multiplex. As we will see shortly, with a 1201 carefully chosen label structure, the label itself can be made to 1202 function as this information element. 1204 In general, there are two ways to assign labels for signals between 1205 neighboring SDH/SONET LSRs. One way is for the labels to be 1206 allocated completely independently of any SDH/SONET semantics; e.g. 1207 labels could just be unstructured 16 or 32 bit numbers. In that 1208 case, in the absence of appropriate binding information, a label 1209 gives no visible information about the flow that it represents. From 1210 a management and debugging point of view, therefore, it becomes 1211 difficult to match a label with the corresponding signal, since , as 1212 we saw in Section 6.1, the label is not coded in the SDH/SONET 1213 overhead of the signal. 1215 Another way is to use the well-defined and finite structure of the 1216 SDH/SONET multiplexing tree to devise a signal numbering scheme that 1217 makes use of the multiplex as a naming tree, and assigns each 1218 multiplex entry a unique associated value. This allows the unique 1219 identification of each multiplex entry (signal) in terms of its type 1220 and position in the multiplex tree. By using this multiplex entry 1221 value itself as the label, we automatically add SDH/SONET semantics 1222 to the label! Thus, simply by examining the label, one can now 1223 directly deduce the signal that it represents, as well as its 1224 position in the SDH/SONET multiplex. We refer to this as 1225 multiplex-based labeling. This is the idea that was incorporated in 1226 the GMPLS signaling specifications for SDH/SONET [18]. 1228 5.3. Signaling Elements 1230 In the preceding sections, we defined the meaning of a SDH/SONET 1231 label and specified its structure. A question that arises naturally 1232 at this point is the following. In an LSP or connection setup 1233 request, how do we specify the signal for which we want to establish 1234 a path (and for which we desire a label)? 1235 Clearly, information that is required to completely specify the 1236 desired signal and its characteristics must be transferred via the 1237 label distribution protocol, so that the switches along the path can 1238 be configured to correctly handle and switch the signal. This 1239 information is specified in three parts [18], each of which refers 1240 to a different network layer. 1242 1. GENERALIZED_LABEL REQUEST (as in [6], [7]), which contains three 1243 parts: LSP Encoding Type, Switching Type, and G-PID. 1245 The first specifies the nature/type of the LSP or the desired 1246 SDH/SONET channel, in terms of the particular signal (or collection 1247 of signals) within the SDH/SONET multiplex that the LSP represents, 1248 and is used by all the nodes along the path of the LSP. 1250 The second specifies certain link selection constraints, which 1251 control, at each hop, the selection of the underlying link that is 1252 used to transport this LSP. 1254 The third specifies the payload carried by the LSP or SDH/SONET 1255 channel, in terms of the termination and adaptation functions 1256 required at the end points, and is used by the source and 1257 destination nodes of the LSP. 1259 2. SONET/SDH TRAFFIC_PARAMETERS (as in [18], Section 2.1) used as a 1260 SENDER_TSPEC/FLOWSPEC, which contains 7 parts: Signal Type, 1261 (Requested Contiguous Concatenation (RCC), Number of Contiguous 1262 Components (NCC), Number of Virtual Components (NVC)), Multiplier 1263 (MT), Transparency, and Profile. 1265 The Signal Type indicates the type of elementary signal comprising 1266 the LSP, while the remaining fields indicate transforms that can be 1267 applied to the basic signal to build the final signal that 1268 corresponds to the LSP actually being requested. For instance (see 1269 [18] for details): 1271 - Contiguous concatenation (by using the RCC and NCC 1272 fields) can be optionally applied on the Elementary Signal, 1273 resulting in a contiguously concatenated signal. 1275 - Then, virtual concatenation (by using the NVC field) can be 1276 optionally applied on the Elementary Signal resulting in 1277 a virtually concatenated signal. 1279 - Third, some transparency (by using the Transparency field) 1280 can be optionally specified when requesting a frame as 1281 signal rather than an SPE or VC based signal. 1283 - Fourth, a multiplication (by using the Multiplier field) 1284 can be optionally applied either directly on the Elementary 1285 Signal, or on the contiguously concatenated signal obtained 1286 from the first phase, or on the virtually concatenated signal 1287 obtained from the second phase, or on these signals combined 1288 with some transparency. 1290 Transparency indicates precisely which fields in these overheads 1291 must be delivered unmodified at the other end of the LSP. An ingress 1292 LSR requesting transparency will pass these overhead fields that 1293 must be delivered to the egress LSR without any change. From the 1294 ingress and egress LSRs point of views, these fields must be seen as 1295 unmodified. 1297 Transparency is not applied at the interfaces with the initiating 1298 and terminating LSRs, but is only applied between intermediate LSRs. 1300 The transparency field is used to request an LSP that supports the 1301 requested transparency type; it may also be used to setup the 1302 transparency process to be applied at each intermediate LSR. 1304 Finally, the profile field is intended particular capabilities that 1305 must be supported for the LSP, for example monitoring capabilities. 1306 No standard profile is currently defined, however. 1308 3. UPSTREAM_LABEL for Bi-directional LSP's (as in [6], [7]). 1310 4. Local Link Selection e.g. IF_ID_RSVP_HOP Object (as in [7]). 1312 6. Summary and Conclusions 1314 We provided a detailed account of the issues involved in applying 1315 generalized GMPLS-based control (GMPLS) to TDM networks. 1317 We began with a brief overview of GMPLS and SDH/SONET networks, 1318 discussing current circuit establishment in TDM networks, and 1319 arguing why SDH/SONET technologies will not be "outdated" in the 1320 foreseeable future. Next, we looked at IP/MPLS applied to SDH/SONET 1321 networks, where we considered why such an application makes sense, 1322 and reviewed some GMPLS terminology as applied to TDM networks. 1324 We considered the two main areas of application of IP/MPLS methods 1325 to TDM networks, namely routing and signaling, and discussed how 1326 Generalized MPLS routing and signaling are used in the context of 1327 TDM networks. We reviewed in detail the switching capabilities of 1328 TDM equipment, and the requirement to learn about the protection 1329 capabilities of underlying links, and how these influence the 1330 available capacity advertisement in TDM networks. 1332 We focused briefly on path computation methods, pointing out that 1333 these were not subject to standardization. We then examined optical 1334 path provisioning or signaling, considering the issue of what 1335 constitutes an appropriate label for TDM circuits and how this label 1336 should be structured, and we focused on the importance of 1337 hierarchical label allocation in a TDM network. Finally, we reviewed 1338 the signaling elements involved when setting up an TDM circuit, 1339 focusing on the nature of the LSP, the type of payload it carries, 1340 and the characteristics of the links that the LSP wishes to use at 1341 each hop along its path for achieving a certain reliability. 1343 7. Security Considerations 1345 This document describes the framework for GMPLS extensions for use 1346 in SDH/SONET control. As such, it introduces no new security issues 1347 with respect to GMPLS specifications. GMPLS protocol specifications 1348 should identify and address security issues specific to protocol. 1350 Among the considerations that should be addressed by GMPLS protocol 1351 specifications, are any security vulnerabilities that are introduced 1352 by specific GMPLS extensions added in each specification. 1354 8. Acknowledgments 1356 We acknowledge all the participants of the MPLS and CCAMP WGs, whose 1357 constant enquiry about GMPLS issues in TDM networks motivated the 1358 writing of this document, and whose questions helped shape its 1359 contents. Also, thanks to Kireeti Kompella for his careful reading 1360 of the last version of this document, and for his helpful comments 1361 and feedback, and to Dimitri Papadimitriou for his review on behalf 1362 of the Routing Area Directorate, which provided many useful inputs 1363 to help update the document to conform to the standards evolutions 1364 since this document passed last call. 1366 9. Author's Addresses 1368 Greg Bernstein 1369 Grotto Networking 1370 Phone: +1 510 573-2237 1371 E-mail: gregb@grotto-networking.com 1373 Eric Mannie 1374 InterAir Link 1375 Phone: +32 2 790 34 25 1376 E-mail: eric_mannie@hotmail.com 1378 Vishal Sharma 1379 Metanoia, Inc. 1380 888 Villa Street, Suite 200B 1381 Mountain View, CA 94041 1382 Phone: +1 408 530 8313 1383 Email: v.sharma@ieee.org 1385 Eric Gray 1386 Marconi Communications 1387 E-mail: Eric.Gray@Marconi.com 1389 10. References 1391 10.1. Normative References 1393 [1] Bradner, S., "IETF Rights in Contributions" BCP 78, RFC 3667, 1394 February, 2004. 1396 [2] Bradner, S., "Intellectual Property Rights in IETF Technology", 1397 BCP 79, RFC 3668, February, 2004. 1399 10.2. Informative References 1401 In the ITU references below, please see http://www.itu.int for 1402 availability of ITU documents. For ANSI references, please see 1403 the Library available through http://www.ansi.org. 1405 [3] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol 1406 Label Switching Architecture", RFC 3031, January 2001. 1408 [4] G.707, Network Node Interface for the Synchronous Digital 1409 Hierarchy (SDH), International Telecommunication Union, March 1410 1996. 1412 [5] ANSI T1.105-1995, Synchronous Optical Network (SONET) Basic 1413 Description including Multiplex Structure, Rates, and Formats, 1414 American National Standards Institute. 1416 [6] Berger, L. (Editor), "Generalized MPLS - Signaling Functional 1417 Description," RFC 3471, January 2003. 1419 [7] Berger, L. (Editor), "Generalized MPLS Signaling - RSVP-TE 1420 Extensions," RFC 3473, January 2003. 1422 [8] Omitted. 1424 [9] Bernstein, G., Yates, J., Saha, D., "IP-Centric Control and 1425 Management of Optical Transport Networks," IEEE Communications 1426 Mag., Vol. 40, Issue 10, October 2000. 1428 [10] ANSI T1.105.01-1995, Synchronous Optical Network (SONET) 1429 Automatic Protection Switching, American National Standards 1430 Institute. 1432 [11] G.841, Types and Characteristics of SDH Network Protection 1433 Architectures, ITU-T, July 1995. 1435 [12] Kompella, K., et al, "Routing Extensions in Support of 1436 Generalized MPLS," Internet Draft, Work-in-Progress, 1437 draft-ietf-ccamp-gmpls-routing-09.txt, October 2003. 1439 [13] Kompella, K., et al, "OSPF Extensions in Support of Generalized 1440 MPLS," Internet Draft, Work-in-Progress, 1441 draft-ietf-ccamp-ospf-extensions-12.txt, October 2003. 1443 [14] Kompella, K., et al, "IS-IS Extensions in Support of 1444 Generalized MPLS," Internet Draft, Work-in-Progress, 1445 draft-ietf-isis-gmpls-extensions-16.txt, August 2002. 1447 [15] Bernstein, G., Sharma, V., Ong, L., "Inter-domain Optical 1448 Routing, " OSA J. of Optical Networking, vol. 1, no. 2, pp. 1449 80-92. 1451 [16] Kompella, K., Rekhter, Y., and Berger, L., "Link Bundling in 1452 MPLS Traffic Engineering", Internet Draft, Work-in-Progress, 1453 draft-ietf-mpls-bundle-04.txt, July 2002. 1455 [17] Kompella, K., Rekhter, Y., "LSP Hierarchy with Generalized 1456 MPLS-TE", Internet Draft, Work-in-Progress, 1457 draft-ietf-mpls-lsp-hierarchy-08.txt, February 2002. 1459 [18] Mannie, E. (Editor), "GMPLS Extensions for SONET and SDH 1460 Control", Internet Draft, Work-in-Progress, 1461 draft-ietf-ccamp-gmpls-sonet-sdh-08.txt, February 2003. 1463 [19] G.7715.1, ASON Routing Architecture and Requirements for 1464 Link-State Protocols, International Telecommunications Union, 1465 February 2004. 1467 [20] Bernstein, G., Rajagopalan, R., and Saha, D., "Optical Network 1468 Control: Protocols, Architectures, and Standards," 1469 Addison-Wesley, July 2003. 1471 11. Intellectual Property Statement 1473 The IETF takes no position regarding the validity or scope of any 1474 Intellectual Property Rights or other rights that might be claimed to 1475 pertain to the implementation or use of the technology described in 1476 this document or the extent to which any license under such rights 1477 might or might not be available; nor does it represent that it has 1478 made any independent effort to identify any such rights. Information 1479 on the procedures with respect to rights in RFC documents can be 1480 found in BCP 78 and BCP 79. 1482 Copies of IPR disclosures made to the IETF Secretariat and any 1483 assurances of licenses to be made available, or the result of an 1484 attempt made to obtain a general license or permission for the use 1485 of such proprietary rights by implementers or users of this 1486 specification can be obtained from the IETF on-line IPR repository 1487 at http://www.ietf.org/ipr. 1489 The IETF invites any interested party to bring to its attention 1490 any copyrights, patents or patent applications, or other 1491 proprietary rights that may cover technology that may be required 1492 to implement this standard. Please address the information to the 1493 IETF at ietf-ipr@ietf.org. 1495 12. Disclaimer 1497 This document and the information contained herein are provided on an 1498 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1499 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1500 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1501 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1502 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1503 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1505 13. Copyright Statement 1507 Copyright (C) The Internet Society (2004). This document is 1508 subject to the rights, licenses and restrictions contained in BCP 1509 78, and except as set forth therein, the authors retain all their 1510 rights. 1512 14. IANA Considerations 1514 There are no IANA considerations that apply to this document. 1516 15. Acronyms 1518 ANSI - American National Standards Institute 1519 APS - Automatic Protection Switching 1520 ATM - Asynchronous Transfer Mode 1521 BLSR - Bi-directional Line Switch Ring 1522 CPE - Customer Premise Equipment 1523 DLCI - Data Link Connection Identifier 1524 ETSI - European Telecommunication Standards Institute 1525 FEC - Forwarding Equivalency Class 1526 GMPLS - Generalized MPLS 1527 IP - Internet Protocol 1528 IS-IS - Intermediate System to Intermediate System (RP) 1529 LDP - Label Distribution Protocol 1530 LSP - Label Switched Path 1531 LSR - Label Switching Router 1532 MPLS - Multi-Protocol Label Switching 1533 NMS - Network Management System 1534 OSPF - Open Shortest Path First (RP) 1535 PNNI - Private Network Node Interface 1536 PPP - Point to Point Protocol 1537 QoS - Quality of Service 1538 RP - Routing Protocol 1539 RSVP - ReSerVation Protocol 1540 SDH - Synchronous Digital Hierarchy 1541 SNMP - Simple Network Management Protocol 1542 SONET - Synchronous Optical NETworking 1543 SPE - SONET Payload Envelope 1544 STM - Synchronous Transport Module (or Terminal Multiplexer) 1545 STS - Synchronous Transport Signal 1546 TDM - Time Division Multiplexer 1547 TE - Traffic Engineering 1548 TMN - Telecommunication Management Network 1549 UPSR - Uni-directional Path Switch Ring 1550 VC - Virtual Container (SDH) or Virtual Circuit 1551 VCI - Virtual Circuit Identifier (ATM) 1552 VPI - Virtual Path Identifier (ATM) 1553 VT - Virtual Tributary 1554 WDM - Wave-length Division Multiplexing 1556 16. Acknowledgement 1558 Funding for the RFC Editor function is currently provided by the 1559 Internet Society.