diff options
Diffstat (limited to 'doc/rfc/rfc4257.txt')
| -rw-r--r-- | doc/rfc/rfc4257.txt | 1963 |
1 files changed, 1963 insertions, 0 deletions
diff --git a/doc/rfc/rfc4257.txt b/doc/rfc/rfc4257.txt new file mode 100644 index 0000000..4fbb8dd --- /dev/null +++ b/doc/rfc/rfc4257.txt @@ -0,0 +1,1963 @@ + + + + + + +Network Working Group G. Bernstein +Request for Comments: 4257 Grotto Networking +Category: Informational E. Mannie + Perceval + V. Sharma + Metanoia, Inc. + E. Gray + Marconi Corporation, plc + December 2005 + + + Framework for Generalized Multi-Protocol Label + Switching (GMPLS)-based Control of Synchronous Digital + Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + Generalized Multi-Protocol Label Switching (GMPLS) is a suite of + protocol extensions to MPLS to make it generally applicable, to + include, for example, control of non packet-based switching, and + particularly, optical switching. One consideration is to use GMPLS + protocols to upgrade the control plane of optical transport networks. + This document illustrates this process by describing those extensions + to GMPLS protocols that are aimed at controlling Synchronous Digital + Hierarchy (SDH) or Synchronous Optical Networking (SONET) networks. + SDH/SONET networks make good examples of this process for a variety + of reasons. This document highlights extensions to GMPLS-related + routing protocols to disseminate information needed in transport path + computation and network operations, together with (G)MPLS protocol + extensions required for the provisioning of transport circuits. New + capabilities that an GMPLS control plane would bring to SDH/SONET + networks, such as new restoration methods and multi-layer circuit + establishment, are also discussed. + + + + + + + + +Bernstein, et al. Informational [Page 1] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. MPLS Overview ..............................................3 + 1.2. SDH/SONET Overview .........................................5 + 1.3. The Current State of Circuit Establishment in + SDH/SONET Networks .........................................7 + 1.3.1. Administrative Tasks ................................8 + 1.3.2. Manual Operations ...................................8 + 1.3.3. Planning Tool Operation .............................8 + 1.3.4. Circuit Provisioning ................................8 + 1.4. Centralized Approach versus Distributed Approach ...........9 + 1.4.1. Topology Discovery and Resource Dissemination ......10 + 1.4.2. Path Computation (Route Determination) .............10 + 1.4.3. Connection Establishment (Provisioning) ............10 + 1.5. Why SDH/SONET Will Not Disappear Tomorrow .................12 + 2. GMPLS Applied to SDH/SONET .....................................13 + 2.1. Controlling the SDH/SONET Multiplex .......................13 + 2.2. SDH/SONET LSR and LSP Terminology .........................14 + 3. Decomposition of the GMPLS Circuit-Switching Problem Space .....14 + 4. GMPLS Routing for SDH/SONET ....................................15 + 4.1. Switching Capabilities ....................................16 + 4.1.1. Switching Granularity ..............................16 + 4.1.2. Signal Concatenation Capabilities ..................17 + 4.1.3. SDH/SONET Transparency .............................19 + 4.2. Protection ................................................20 + 4.3. Available Capacity Advertisement ..........................23 + 4.4. Path Computation ..........................................24 + 5. LSP Provisioning/Signaling for SDH/SONET .......................25 + 5.1. What Do We Label in SDH/SONET? Frames or Circuits? .......25 + 5.2. Label Structure in SDH/SONET ..............................26 + 5.3. Signaling Elements ........................................27 + 6. Summary and Conclusions ........................................29 + 7. Security Considerations ........................................29 + 8. Acknowledgements ...............................................30 + 9. Informative References .........................................31 + 10. Acronyms ......................................................33 + + + + + + + + + + + + + + +Bernstein, et al. Informational [Page 2] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + +1. Introduction + + The CCAMP Working Group of the IETF has the goal of extending MPLS + [1] protocols to support multiple network layers and new services. + This extended MPLS, which was initially known as Multi-Protocol + Lambda Switching, is now better referred to as Generalized MPLS (or + GMPLS). + + The GMPLS effort is, in effect, extending IP/MPLS technology to + control and manage lower layers. Using the same framework and + similar signaling and routing protocols to control multiple layers + can not only reduce the overall complexity of designing, deploying, + and maintaining networks, but can also make it possible to operate + two contiguous layers by using either an overlay model, a peer model, + or an integrated model. The benefits of using a peer or an overlay + model between the IP layer and its underlying layer(s) will have to + be clarified and evaluated in the future. In the mean time, GMPLS + could be used for controlling each layer independently. + + The goal of this work is to highlight how GMPLS could be used to + dynamically establish, maintain, and tear down SDH/SONET circuits. + The objective of using these extended IP/MPLS protocols is to provide + at least the same kinds of SDH/SONET services as are provided today, + but using signaling instead of provisioning via centralized + management to establish those services. This will allow operators to + propose new services, and will allow clients to create SDH/SONET + paths on-demand, in real-time, through the provider network. We + first review the essential properties of SDH/SONET networks and their + operations, and we show how the label concept in GMPLS can be + extended to the SDH/SONET case. We then look at important + information to be disseminated by a link state routing protocol and + look at the important signal attributes that need to be conveyed by a + label distribution protocol. Finally, we look at some outstanding + issues and future possibilities. + +1.1. MPLS Overview + + A major advantage of the MPLS architecture [1] for use as a general + network control plane is its clear separation between the forwarding + (or data) plane, the signaling (or connection control) plane, and the + routing (or topology discovery/resource status) plane. This allows + the work on MPLS extensions to focus on the forwarding and signaling + planes, while allowing well-known IP routing protocols to be reused + in the routing plane. This clear separation also allows for MPLS to + be used to control networks that do not have a packet-based + forwarding plane. + + + + + +Bernstein, et al. Informational [Page 3] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + + An MPLS network consists of MPLS nodes called Label Switch Routers + (LSRs) connected via Label Switched Paths (LSPs). An LSP is uni- + directional and could be of several different types such as point- + to-point, point-to-multipoint, and multipoint-to-point. Border LSRs + in an MPLS network act as either ingress or egress LSRs, depending on + the direction of the traffic being forwarded. + + Each LSP is associated with a Forwarding Equivalence Class (FEC), + which may be thought of as a set of packets that receive identical + forwarding treatment at an LSR. The simplest example of an FEC might + be the set of destination addresses lying in a given address range. + All packets that have a destination address lying within this address + range are forwarded identically at each LSR configured with that FEC. + + To establish an LSP, a signaling protocol (or label distribution + protocol) such as LDP or RSVP-TE is required. Between two adjacent + LSRs, an LSP is locally identified by a fixed length identifier + called a label, which is only significant between those two LSRs. A + signaling protocol is used for inter-node communication to assign and + maintain these labels. + + When a packet enters an MPLS-based packet network, it is classified + according to its FEC and, possibly, additional rules, which together + determine the LSP along which the packet must be sent. For this + purpose, the ingress LSR attaches an appropriate label to the packet, + and forwards the packet to the next hop. The label may be attached + to a packet in different ways. For example, it may be in the form of + a header encapsulating the packet (the "shim" header) or it may be + written in the VPI/VCI field (or DLCI field) of the layer 2 + encapsulation of the packet. In case of SDH/SONET networks, we will + see that a label is simply associated with a segment of a circuit, + and is mainly used in the signaling plane to identify this segment + (e.g., a time-slot) between two adjacent nodes. + + When a packet reaches a packet LSR, this LSR uses the label as an + index into a forwarding table to determine the next hop and the + corresponding outgoing label (and, possibly, the QoS treatment to be + given to the packet), writes the new label into the packet, and + forwards the packet to the next hop. When the packet reaches the + egress LSR, the label is removed and the packet is forwarded using + appropriate forwarding, such as normal IP forwarding. We will see + that for an SDH/SONET network these operations do not occur in quite + the same way. + + + + + + + + +Bernstein, et al. Informational [Page 4] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + +1.2. SDH/SONET Overview + + There are currently two different multiplexing technologies in use in + optical networks: wavelength-division multiplexing (WDM) and time + division multiplexing (TDM). This work focuses on TDM technology. + + SDH and SONET are two TDM standards widely used by operators to + transport and multiplex different tributary signals over optical + links, thus creating a multiplexing structure, which we call the + SDH/SONET multiplex. + + ITU-T (G.707) [2] includes both the European Telecommunications + Standards Institute (ETSI) SDH hierarchy and the USA ANSI SONET + hierarchy [3]. The ETSI SDH and SONET standards regarding frame + structures and higher-order multiplexing are the same. There are + some regional differences in terminology, on the use of some overhead + bytes, and lower-order multiplexing. Interworking between the two + lower-order hierarchies is possible using gateways. + + The fundamental signal in SDH is the STM-1 that operates at a rate of + about 155 Mbps, while the fundamental signal in SONET is the STS-1 + that operates at a rate of about 51 Mbps. These two signals are made + of contiguous frames that consist of transport overhead (header) and + payload. To solve synchronization issues, the actual data is not + transported directly in the payload, but rather in another internal + frame that is allowed to float over two successive SDH/SONET + payloads. This internal frame is named a Virtual Container (VC) in + SDH and a SONET Payload Envelope (SPE) in SONET. + + The SDH/SONET architecture identifies three different layers, each of + which corresponds to one level of communication between SDH/SONET + equipment. These are, starting with the lowest, the regenerator + section/section layer, the multiplex section/line layer, and (at the + top) the path layer. Each of these layers, in turn, has its own + overhead (header). The transport overhead of an SDH/SONET frame is + mainly sub-divided in two parts that contain the regenerator + section/section overhead and the multiplex section/line overhead. In + addition, a pointer (in the form of the H1, H2, and H3 bytes) + indicates the beginning of the VC/SPE in the payload of the overall + STM/STS frame. + + The VC/SPE itself is made up of a header (the path overhead) and a + payload. This payload can be further subdivided into sub-elements + (signals) in a fairly complex way. In the case of SDH, the STM-1 + frame may contain either one VC-4 or three multiplexed VC-3s. The + SONET multiplex is a pure tree, while the SDH multiplex is not a pure + tree, since it contains a node that can be attached to two parent + + + + +Bernstein, et al. Informational [Page 5] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + + nodes. The structure of the SDH/SONET multiplex is shown in Figure + 1. In addition, we show reference points in this figure that are + explained in later sections. + + The leaves of these multiplex structures are time slots (positions) + of different sizes that can contain tributary signals. These + tributary signals (e.g., E1, E3, etc) are mapped into the leaves + using standardized mapping rules. In general, a tributary signal + does not fill a time slot completely, and the mapping rules define + precisely how to fill it. + + What is important for the GMPLS-based control of SDH/SONET circuits + is to identify the elements that can be switched from an input + multiplex on one interface to an output multiplex on another + interface. The only elements that can be switched are those that can + be re-aligned via a pointer, i.e., a VC-x in the case of SDH and a + SPE in the case of SONET. + + xN x1 + STM-N<----AUG<----AU-4<--VC4<------------------------------C-4 E4 + ^ ^ + Ix3 Ix3 + I I x1 + I -----TUG-3<----TU-3<---VC-3<---I + I ^ C-3 DS3/E3 + STM-0<------------AU-3<---VC-3<-- I ---------------------I + ^ I + Ix7 Ix7 + I I x1 + -----TUG-2<---TU-2<---VC-2<---C-2 DS2/T2 + ^ ^ + I I x3 + I I----TU-12<---VC-12<--C-12 E1 + I + I x4 + I-------TU-11<---VC-11<--C-11 DS1/T1 + + + + + + + + + + + + + + + +Bernstein, et al. Informational [Page 6] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + + xN + STS-N<-------------------SPE<------------------------------DS3/T3 + ^ + Ix7 + I x1 + I---VT-Group<---VT-6<----SPE DS2/T2 + ^ ^ ^ + I I I x2 + I I I-----VT-3<----SPE DS1C + I I + I I x3 + I I--------VT-2<----SPE E1 + I + I x4 + I-----------VT-1.5<--SPE DS1/T1 + + Figure 1. SDH and SONET multiplexing structure and typical + Plesiochronous Digital Hierarchy (PDH) payload signals. + + An STM-N/STS-N signal is formed from N x STM-1/STS-1 signals via byte + interleaving. The VCs/SPEs in the N interleaved frames are + independent and float according to their own clocking. To transport + tributary signals in excess of the basic STM-1/STS-1 signal rates, + the VCs/SPEs can be concatenated, i.e., glued together. In this + case, their relationship with respect to each other is fixed in time; + hence, this relieves, when possible, an end system of any inverse + multiplexing bonding processes. Different types of concatenations + are defined in SDH/SONET. + + For example, standard SONET concatenation allows the concatenation of + M x STS-1 signals within an STS-N signal with M <= N, and M = 3, 12, + 48, 192, .... The SPEs of these M x STS-1s can be concatenated to + form an STS-Mc. The STS-Mc notation is short hand for describing an + STS-M signal whose SPEs have been concatenated. + +1.3. The Current State of Circuit Establishment in SDH/SONET Networks + + In present day SDH and SONET networks, the networks are primarily + statically configured. When a client of an operator requests a + point-to-point circuit, the request sets in motion a process that can + last for several weeks or more. This process is composed of a chain + of shorter administrative and technical tasks, some of which can be + fully automated, resulting in significant improvements in + provisioning time and in operational savings. In the best case, the + entire process can be fully automated allowing, for example, customer + premise equipment (CPE) to contact an SDH/SONET switch to request a + circuit. Currently, the provisioning process involves the following + tasks. + + + +Bernstein, et al. Informational [Page 7] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + +1.3.1. Administrative Tasks + + The administrative tasks represent a significant part of the + provisioning time. Most of them can be automated using IT + applications, e.g., a client still has to fill a form to request a + circuit. This form can be filled via a Web-based application and can + be automatically processed by the operator. A further enhancement is + to allow the client's equipment to coordinate with the operator's + network directly and request the desired circuit. This could be + achieved through a signaling protocol at the interface between the + client equipment and an operator switch, i.e., at the UNI, where + GMPLS signaling [4], [5] can be used. + +1.3.2. Manual Operations + + Another significant part of the time may be consumed by manual + operations that involve installing the right interface in the CPE and + installing the right cable or fiber between the CPE and the operator + switch. This time can be especially significant when a client is in + a different time zone than the operator's main office. This first- + time connection time is frequently accounted for in the overall + establishment time. + +1.3.3. Planning Tool Operation + + Another portion of the time is consumed by planning tools that run + simulations using heuristic algorithms to find an optimized placement + for the required circuits. These planning tools can require a + significant running time, sometimes on the order of days. + + These simulations are, in general, executed for a set of demands for + circuits, i.e., a batch mode, to improve the optimality of network + resource usage and other parameters. Today, we do not really have a + means to reduce this simulation time. On the contrary, to support + fast, on-line, circuit establishment, this phase may be invoked more + frequently, i.e., we will not "batch up" as many connection requests + before we plan out the corresponding circuits. This means that the + network may need to be re-optimized periodically, implying that the + signaling should support re-optimization with minimum impact to + existing services. + +1.3.4. Circuit Provisioning + + Once the first three steps discussed above have been completed, the + operator must provision the circuits using the outputs of the + planning process. The time required for provisioning varies greatly. + It can be fairly short, on the order of a few minutes, if the + operators already have tools that help them to do the provisioning + + + +Bernstein, et al. Informational [Page 8] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + + over heterogeneous equipment. Otherwise, the process can take days. + Developing these tools for each new piece of equipment and each + vendor is a significant burden on the service provider. A + standardized interface for provisioning, such as GMPLS signaling, + could significantly reduce or eliminate this development burden. In + general, provisioning is a batched activity, i.e., a few times per + week an operator provisions a set of circuits. GMPLS will reduce + this provisioning time from a few minutes to a few seconds and could + help to transform this periodic process into a real-time process. + + When a circuit is provisioned, it is not delivered directly to a + client. Rather, the operator first tests its performance and + behavior and, if successful, delivers the circuit to the client. + This testing phase lasts, in general, up to 24 hours. The operator + installs test equipment at each end and uses pre-defined test streams + to verify performance. If successful, the circuit is officially + accepted by the client. To speed up the verification (sometimes + known as "proving") process, it would be necessary to support some + form of automated performance testing. + +1.4. Centralized Approach versus Distributed Approach + + Whether a centralized approach or a distributed approach will be used + to control SDH/SONET networks is an open question, since each + approach has its merits. The application of GMPLS to SDH/SONET + networks does not preclude either model, although GMPLS is itself a + distributed technology. + + The basic tradeoff between the centralized and distributed approaches + is that of complexity of the network elements versus that of the + network management system (NMS). Since adding functionality to + existing SDH/SONET network elements may not be possible, a + centralized approach may be needed in some cases. The main issue + facing centralized control via an NMS is one of scalability. For + instance, this approach may be limited in the number of network + elements that can be managed (e.g., one thousand). It is, therefore, + quite common for operators to deploy several NMS in parallel at the + Network Management Layer, each managing a different zone. In that + case, however, a Service Management Layer must be built on the top of + several individual NMS to take care of end-to-end on-demand services. + On the other hand, in a complex and/or dense network, restoration + could be faster with a distributed approach than with a centralized + approach. + + Let's now look at how the major control plane functional components + are handled via the centralized and distributed approaches: + + + + + +Bernstein, et al. Informational [Page 9] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + +1.4.1. Topology Discovery and Resource Dissemination + + Currently, an NMS maintains a consistent view of all the networking + layers under its purview. This can include the physical topology, + such as information about fibers and ducts. Since most of this + information is entered manually, it remains error prone. + + A link state GMPLS routing protocol, on the other hand, could perform + automatic topology discovery and disseminate the topology as well as + resource status. This information would be available to all nodes in + the network, and hence also the NMS. Hence, one can look at a + continuum of functionality between manually provisioned topology + information (of which there will always be some) and fully automated + discovery and dissemination (as in a link state protocol). Note + that, unlike the IP datagram case, a link state routing protocol + applied to the SDH/SONET network does not have any service impacting + implications. This is because in the SDH/SONET case, the circuit is + source-routed (so there can be no loops), and no traffic is + transmitted until a circuit has been established and an + acknowledgement received at the source. + +1.4.2. Path Computation (Route Determination) + + In the SDH/SONET case, unlike the IP datagram case, there is no need + for network elements to all perform the same path calculation [6]. + In addition, path determination is an area for vendors to provide a + potentially significant value addition in terms of network + efficiency, reliability, and service differentiation. In this sense, + a centralized approach to path computation may be easier to operate + and upgrade. For example, new features such as new types of path + diversity or new optimization algorithms can be introduced with a + simple NMS software upgrade. On the other hand, updating switches + with new path computation software is a more complicated task. In + addition, many of the algorithms can be fairly computationally + intensive and may be completely unsuitable for the embedded + processing environment available on most switches. In restoration + scenarios, the ability to perform a reasonably sophisticated level of + path computation on the network element can be particularly useful + for restoring traffic during major network faults. + +1.4.3. Connection Establishment (Provisioning) + + The actual setting up of circuits, i.e., a coupled collection of + cross connects across a network, can be done either via the NMS + setting up individual cross connects or via a "soft permanent LSP" + (SPLSP) type approach. In the SPLSP approach, the NMS may just kick + off the connection at the "ingress" switch with GMPLS signaling + setting up the connection from that point onward. Connection + + + +Bernstein, et al. Informational [Page 10] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + + establishment is the trickiest part to distribute, however, since + errors in the connection setup/tear down process are service + impacting. + + The table below compares the two approaches to connection + establishment. + + Table 1. Qualitative comparison between centralized and distributed + approaches. + + Distributed approach Centralized approach + + Packet-based control plane Management plane like TMN or + (like GMPLS or PNNI) useful? SNMP + Do we really need it? Being Always needed! Already there, + added/specified by several proven and understood. + standardization bodies + + High survivability (e.g., in Potential single point(s) of + case of partition) failure + + Distributed load Bottleneck: #requests and + actions to/from NMS + + Individual local routing Centralized routing decision, + decision can be done per block of + requests + Routing scalable as for the Assumes a few big + Internet administrative domains + + Complex to change routing Very easy local upgrade (non- + protocol/algorithm intrusive) + + Requires enhanced routing Better consistency + protocol (traffic + engineering) + + Ideal for inter-domain Not inter-domain friendly + + Suitable for very dynamic For less dynamic demands + demands (longer lived) + + Probably faster to restore, Probably slower to restore,but + but more difficult to have could effect reliable + reliable restoration. restoration. + + High scalability Limited scalability: #nodes, + (hierarchical) links, circuits, messages + + + +Bernstein, et al. Informational [Page 11] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + + Planning (optimization) Planning is a background + harder to achieve centralized activity + + Easier future integration + with other control plane + layers + +1.5. Why SDH/SONET Will Not Disappear Tomorrow + + As IP traffic becomes the dominant traffic transported over the + transport infrastructure, it is useful to compare the statistical + multiplexing of IP with the time division multiplexing of SDH and + SONET. + + Consider, for instance, a scenario where IP over WDM is used + everywhere and lambdas are optically switched. In such a case, a + carrier's carrier would sell dynamically controlled lambdas with each + customers building their own IP backbones over these lambdas. + + This simple model implies that a carrier would sell lambdas instead + of bandwidth. The carrier's goal will be to maximize the number of + wavelengths/lambdas per fiber, with each customer having to fully + support the cost for each end-to-end lambda whether or not the + wavelength is fully utilized. Although, in the near future, we may + have technology to support up to several hundred lambdas per fiber, a + world where lambdas are so cheap and abundant that every individual + customer buys them, from one point to any other point, appears an + unlikely scenario today. + + More realistically, there is still room for a multiplexing technology + that provides circuits with a lower granularity than a wavelength. + (Not everyone needs a minimum of 10 Gbps or 40 Gbps per circuit, and + IP does not yet support all telecom applications in bulk + efficiently.) + + SDH and SONET possess a rich multiplexing hierarchy that permits + fairly fine granularity and that provides a very cheap and simple + physical separation of the transported traffic between circuits, + i.e., QoS. Moreover, even IP datagrams cannot be transported + directly over a wavelength. A framing or encapsulation is always + required to delimit IP datagrams. The Total Length field of an IP + header cannot be trusted to find the start of a new datagram, since + it could be corrupted and would result in a loss of synchronization. + The typical framing used today for IP over Dense WDM (DWDM) is + defined in RFC1619/RFC2615 and is known as POS (Packet Over + SDH/SONET), i.e., IP over PPP (in High-Level Data Link Control + (HDLC)-like format) over SDH/SONET. SDH and SONET are actually + efficient encapsulations for IP. For instance, with an average IP + + + +Bernstein, et al. Informational [Page 12] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + + datagram length of 350 octets, an IP over Gigabit Ethernet (GbE) + encapsulation using an 8B/10B encoding results in 28% overhead, an + IP/ATM/SDH encapsulation results in 22% overhead, and an IP/PPP/SDH + encapsulation results in only 6% overhead. + + Any encapsulation of IP over WDM should, in the data plane, at least + provide the following: error monitoring capabilities (to detect + signal degradation); error correction capabilities, such as FEC + (Forward Error Correction) that are particularly needed for ultra + long haul transmission; and sufficient timing information, to allow + robust synchronization (that is, to detect the beginning of a + packet). In the case where associated signaling is used (that is, + where the control and data plane topologies are congruent), the + encapsulation should also provide the capacity to transport + signaling, routing, and management messages, in order to control the + optical switches. Rather, SDH and SONET cover all these aspects + natively, except FEC, which tends to be supported in a proprietary + way. (We note, however, that associated signaling is not a + requirement for the GMPLS-based control of SDH/SONET networks. + Rather, it is just one option. Non associated signaling, as would + happen with an out-of-band control plane network is another equally + valid option.) + + Since IP encapsulated in SDH/SONET is efficient and widely used, the + only real difference between an IP over WDM network and an IP over + SDH over WDM network is the layers at which the switching or + forwarding can take place. In the first case, it can take place at + the IP and optical layers. In the second case, it can take place at + the IP, SDH/SONET, and optical layers. + + Almost all transmission networks today are based on SDH or SONET. A + client is connected either directly through an SDH or SONET interface + or through a PDH interface, the PDH signal being transported between + the ingress and the egress interfaces over SDH or SONET. What we are + arguing here is that it makes sense to do switching or forwarding at + all these layers. + +2. GMPLS Applied to SDH/SONET + +2.1. Controlling the SDH/SONET Multiplex + + Controlling the SDH/SONET multiplex implies deciding which of the + different switchable components of the SDH/SONET multiplex we wish to + control using GMPLS. Essentially, every SDH/SONET element that is + referenced by a pointer can be switched. These component signals are + the VC-4, VC-3, VC-2, VC-12, and VC-11 in the SDH case; and the VT + and STS SPEs in the SONET case. The SPEs in SONET do not have + + + + +Bernstein, et al. Informational [Page 13] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + + individual names, although they can be referred to simply as VT-N + SPEs. We will refer to them by identifying the structure that + contains them, namely STS-1, VT-6, VT-3, VT-2, and VT-1.5. + + The STS-1 SPE corresponds to a VC-3, a VT-6 SPE corresponds to a VC- + 2, a VT-2 SPE corresponds to a VC-12, and a VT-1.5 SPE corresponds to + a VC-11. The SONET VT-3 SPE has no correspondence in SDH, however + SDH's VC-4 corresponds to SONET's STS-3c SPE. + + In addition, it is possible to concatenate some of the structures + that contain these elements to build larger elements. For instance, + SDH allows the concatenation of X contiguous AU-4s to build a VC-4-Xc + and of m contiguous TU-2s to build a VC-2-mc. In that case, a VC-4- + Xc or a VC-2-mc can be switched and controlled by GMPLS. SDH also + defines virtual (non-contiguous) concatenation of TU-2s; however, in + that case, each constituent VC-2 is switched individually. + +2.2. SDH/SONET LSR and LSP Terminology + + Let an SDH or SONET Terminal Multiplexer (TM), Add-Drop Multiplexer + (ADM), or cross-connect (i.e., a switch) be called an SDH/SONET LSR. + An SDH/SONET path or circuit between two SDH/SONET LSRs now becomes a + GMPLS LSP. An SDH/SONET LSP is a logical connection between the + point at which a tributary signal (client layer) is adapted into its + virtual container, and the point at which it is extracted from its + virtual container. + + To establish such an LSP, a signaling protocol is required to + configure the input interface, switch fabric, and output interface of + each SDH/SONET LSR along the path. An SDH/SONET LSP can be point- + to-point or point-to-multipoint, but not multipoint-to-point, since + no merging is possible with SDH/SONET signals. + + To facilitate the signaling and setup of SDH/SONET circuits, an + SDH/SONET LSR must, therefore, identify each possible signal + individually per interface, since each signal corresponds to a + potential LSP that can be established through the SDH/SONET LSR. It + turns out, however, that not all SDH signals correspond to an LSP and + therefore not all of them need be identified. In fact, only those + signals that can be switched need identification. + +3. Decomposition of the GMPLS Circuit-Switching Problem Space + + Although those familiar with GMPLS may be familiar with its + application in a variety of application areas (e.g., ATM, Frame + Relay, and so on), here we quickly review its decomposition when + applied to the optical switching problem space. + + + + +Bernstein, et al. Informational [Page 14] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + + (i) Information needed to compute paths must be made globally + available throughout the network. Since this is done via the link + state routing protocol, any information of this nature must either be + in the existing link state advertisements (LSAs) or the LSAs must be + supplemented to convey this information. For example, if it is + desirable to offer different levels of service in a network, based on + whether a circuit is routed over SDH/SONET lines that are ring + protected versus being routed over those that are not ring protected + (differentiation based on reliability), the type of protection on a + SDH/SONET line would be an important topological parameter that would + have to be distributed via the link state routing protocol. + + (ii) Information that is only needed between two "adjacent" switches + for the purposes of connection establishment is appropriate for + distribution via one of the label distribution protocols. In fact, + this information can be thought of as the "virtual" label. For + example, in SONET networks, when distributing information to switches + concerning an end-to-end STS-1 path traversing a network, it is + critical that adjacent switches agree on the multiplex entry used by + this STS-1 (but this information is only of local significance + between those two switches). Hence, the multiplex entry number in + this case can be used as a virtual label. Note that the label is + virtual, in that it is not appended to the payload in any way, but it + is still a label in the sense that it uniquely identifies the signal + locally on the link between the two switches. + + (iii) Information that all switches in the path need to know about a + circuit will also be distributed via the label distribution protocol. + Examples of such information include bandwidth, priority, and + preemption. + + (iv) Information intended only for end systems of the connection. + Some of the payload type information may fall into this category. + +4. GMPLS Routing for SDH/SONET + + Modern SDH/SONET transport networks excel at interoperability in the + performance monitoring (PM) and fault management (FM) areas [7], [8]. + They do not, however, interoperate in the areas of topology discovery + or resource status. Although link state routing protocols, such as + IS-IS and OSPF, have been used for some time in the IP world to + compute destination-based next hops for routes (without routing + loops), they are particularly valuable for providing timely topology + and network status information in a distributed manner, i.e., at any + network node. If resource utilization information is disseminated + along with the link status (as done in ATM's PNNI routing protocol), + then a very complete picture of network status is available to a + network operator for use in planning, provisioning, and operations. + + + +Bernstein, et al. Informational [Page 15] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + + The information needed to compute the path a connection will take + through a network is important to distribute via the routing + protocol. In the TDM case, this information includes, but is not + limited to: the available capacity of the network links, the + switching and termination capabilities of the nodes and interfaces, + and the protection properties of the link. This is what is being + proposed in the GMPLS extensions to IP routing protocols [9], [10], + [11]. + + When applying routing to circuit switched networks, it is useful to + compare and contrast this situation with the datagram routing case + [12]. In the case of routing datagrams, all routes on all nodes must + be calculated exactly the same to avoid loops and "black holes". In + circuit switching, this is not the case since routes are established + per circuit and are fixed for that circuit. Hence, unlike the + datagram case, routing is not service impacting in the circuit + switched case. This is helpful because, to accommodate the optical + layer, routing protocols need to be supplemented with new + information, as compared to the datagram case. This information is + also likely to be used in different ways for implementing different + user services. Due to the increase in information transferred in the + routing protocol, it may be useful to separate the relatively static + parameters concerning a link from those that may be subject to + frequent changes. However, the current GMPLS routing extensions [9], + [10], [11] do not make such a separation. + + Indeed, from the carriers' perspective, the up-to-date dissemination + of all link properties is essential and desired, and the use of a + link-state routing protocol to distribute this information provides + timely and efficient delivery. If GMPLS-based networks got to the + point that bandwidth updates happen very frequently, it makes sense, + from an efficiency point of view, to separate them out for update. + This situation is not yet seen in actual networks; however, if GMPLS + signaling is put into widespread use then the need could arise. + +4.1. Switching Capabilities + + The main switching capabilities that characterize an SDH/SONET end + system and thus need to be advertised via the link state routing + protocol are: the switching granularity, supported forms of + concatenation, and the level of transparency. + +4.1.1. Switching Granularity + + From references [2], [3], and the overview section on SDH/SONET we + see that there are a number of different signals that compose the + SDH/SONET hierarchies. Those signals that are referenced via a + pointer (i.e., the VCs in SDH and the SPEs in SONET) will actually be + + + +Bernstein, et al. Informational [Page 16] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + + switched within an SDH/SONET network. These signals are subdivided + into lower order signals and higher order signals as shown in Table + 2. + + Table 2. SDH/SONET switched signal groupings. + + Signal Type SDH SONET + + Lower Order VC-11, VC-12, VC-2 VT-1.5 SPE, VT-2 SPE, + VT-3 SPE, VT-6 SPE + + Higher VC-3, VC-4 STS-1 SPE, STS-3c SPE + Order + + Manufacturers today differ in the types of switching capabilities + their systems support. Many manufacturers today switch signals + starting at VC-4 for SDH or STS-1 for SONET (i.e., down the basic + frame) and above (see Section 5.1.2 on concatenation), but they do + not switch lower order signals. Some of them only allow the + switching of entire aggregates (concatenated or not) of signals such + as 16 VC-4s, i.e., a complete STM-16, and nothing finer. Some go + down to the VC-3 level for SDH. Finally, some offer highly + integrated switches that switch at the VC-3/STS-1 level down to lower + order signals such as VC-12s. In order to cover the needs of all + manufacturers and operators, GMPLS signaling ([4], [5]) covers both + higher order and lower order signals. + +4.1.2. Signal Concatenation Capabilities + + As stated in the SDH/SONET overview, to transport tributary signals + with rates in excess of the basic STM-1/STS-1 signal, the VCs/SPEs + can be concatenated, i.e., glued together. Different types of + concatenations are defined: contiguous standard concatenation, + arbitrary concatenation, and virtual concatenation with different + rules concerning their size, placement, and binding. + + Standard SONET concatenation allows the concatenation of M x STS-1 + signals within an STS-N signal with M <= N, and M = 3, 12, 48, 192, + STS-Mc. The STS-Mc notation is shorthand for describing an STS-M + signal whose SPEs have been concatenated. The multiplexing + procedures for SDH and SONET are given in references [2] and [3], + respectively. Constraints are imposed on the size of STS-Mc signals, + i.e., they must be a multiple of 3, and on their starting location + and interleaving. + + + + + + + +Bernstein, et al. Informational [Page 17] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + + This has the following advantages: (a) restriction to multiples of 3 + helps with SDH compatibility (there is no STS-1 equivalent signal in + SDH); (b) the restriction to multiples of 3 reduces the number of + connection types; (c) the restriction on the placement and + interleaving could allow more compact representation of the "label"; + + The major disadvantages of these restrictions are: (a) Limited + flexibility in bandwidth assignment (somewhat inhibits finer grained + traffic engineering). (b) The lack of flexibility in starting time + slots for STS-Mc signals and in their interleaving (where the rest of + the signal gets put in terms of STS-1 slot numbers) leads to the + requirement for re-grooming (due to bandwidth fragmentation). + + Due to these disadvantages, some SONET framer manufacturers now + support "flexible" or arbitrary concatenation. That is, they support + concatenation with no restrictions on the size of an STS-Mc (as long + as M <= N) and no constraints on the STS-1 timeslots used to convey + it, i.e., the signals can use any combination of available time + slots. + + Standard and flexible concatenations are network services, while + virtual concatenation is an SDH/SONET end-system service approved by + the Committee T1 of ANSI [3] and the ITU-T [2]. The essence of this + service is to have SDH/SONET end systems "glue" together the VCs or + SPEs of separate signals, rather than requiring that the signals be + carried through the network as a single unit. In one example of + virtual concatenation, two end systems supporting this feature could + essentially "inverse multiplex" two STS-1s into an STS-1-2v for the + efficient transport of 100 Mbps Ethernet traffic. Note that this + inverse multiplexing process (or virtual concatenation) can be + significantly easier to implement with SDH/SONET than packet switched + circuits, because ensuring that timing and in-order frame delivery is + preserved may be simpler to establish using SDH/SONET, rather than + packet switched circuits, where more sophisticated techniques may be + needed. + + Since virtual concatenation is provided by end systems, it is + compatible with existing SDH/SONET networks. Virtual concatenation + is defined for both higher order signals and low order signals. + Table 3 shows the nomenclature and capacity for several lower-order + virtually concatenated signals contained within different higher- + order signals. + + + + + + + + + +Bernstein, et al. Informational [Page 18] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + + Table 3. Capacity of Virtually Concatenated VTn-Xv (9/G.707) + + Carried In X Capacity In steps + of + + VT1.5/ STS-1/VC-3 1 to 28 1600kbit/s to 1600kbit/s + VC-11-Xv 44800kbit/s + + VT2/ STS-1/VC-3 1 to 21 2176kbit/s to 2176kbit/s + VC-12-Xv 45696kbit/s + + VT1.5/ STS-3c/VC-4 1 to 64 1600kbit/s to 1600kbit/s + VC-11-Xv 102400kbit/s + + VT2/ STS-3c/VC-4 1 to 63 2176kbit/s to 2176kbit/s + VC-12-Xv 137088kbit/s + +4.1.3. SDH/SONET Transparency + + The purposed of SDH/SONET is to carry its payload signals in a + transparent manner. This can include some of the layers of SONET + itself. An example of this is a situation where the path overhead + can never be touched, since it actually belongs to the client. This + was another reason for not coding an explicit label in the SDH/SONET + path overhead. It may be useful to transport, multiplex and/or + switch lower layers of the SONET signal transparently. + + As mentioned in the introduction, SONET overhead is broken into three + layers: Section, Line, and Path. Each of these layers is concerned + with fault and performance monitoring. The Section overhead is + primarily concerned with framing, while the Line overhead is + primarily concerned with multiplexing and protection. To perform + pipe multiplexing (that is, multiplexing of 50 Mbps or 150 Mbps + chunks), a SONET network element should be line terminating. + However, not all SONET multiplexers/switches perform SONET pointer + adjustments on all the STS-1s contained within a higher order SONET + signal passing through them. Alternatively, if they perform pointer + adjustments, they do not terminate the line overhead. For example, a + multiplexer may take four SONET STS-48 signals and multiplex them + onto an STS-192 without performing standard line pointer adjustments + on the individual STS-1s. This can be looked at as a service since + it may be desirable to pass SONET signals, like an STS-12 or STS-48, + with some level of transparency through a network and still take + advantage of TDM technology. Transparent multiplexing and switching + can also be viewed as a constraint, since some multiplexers and + switches may not switch with as fine a granularity as others. Table + 4 summarizes the levels of SDH/SONET transparency. + + + + +Bernstein, et al. Informational [Page 19] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + + Table 4. SDH/SONET transparency types and their properties. + + Transparency Type Comments + + Path Layer (or Line Standard higher order SONET path + Terminating) switching. Line overhead is terminated + or modified. + + Line Level (or Section Preserves line overhead and switches + Terminating) the entire line multiplex as a whole. + Section overhead is terminated or + modified. + + Section layer Preserves all section overhead, + Basically does not modify/terminate any + of the SDH/SONET overhead bits. + +4.2. Protection + + SONET and SDH networks offer a variety of protection options at both + the SONET line (SDH multiplex section) and SDH/SONET path level [7], + [8]. Standardized SONET line level protection techniques include: + Linear 1+1 and linear 1:N automatic protection switching (APS) and + both two-fiber and four-fiber bi-directional line switched rings + (BLSRs). At the path layer, SONET offers uni-directional path + switched ring protection. Likewise, standardized SDH multiplex + section protection techniques include linear 1+1 and 1:N automatic p + protection switching and both two-fiber and four-fiber bi-directional + MS-SPRings (Multiplex Section-Shared Protection Rings). + + At the path layer, SDH offers SNCP (sub-network connection + protection) ring protection. + + Both ring and 1:N line protection also allow for "extra traffic" to + be carried over the protection line when that line is not being used, + i.e., when it is not carrying traffic for a failed working line. + These protection methods are summarized in Table 5. It should be + noted that these protection methods are completely separate from any + GMPLS layer protection or restoration mechanisms. + + + + + + + + + + + + +Bernstein, et al. Informational [Page 20] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + + Table 5. Common SDH/SONET protection mechanisms. + + Protection Type Extra Comments + Traffic + Optionally + Supported + + 1+1 No Requires no coordination + Unidirectional between the two ends of the + circuit. Dedicated + protection line. + + 1+1 Bi- No Coordination via K byte + directional protocol. Lines must be + consistently configured. + Dedicated protection line. + + 1:1 Yes Dedicated protection. + + 1:N Yes One Protection line shared + by N working lines + + 4F-BLSR (4 Yes Dedicated protection, with + fiber bi- alternative ring path. + directional + line switched + ring) + + 2F-BLSR (2 Yes Dedicated protection, with + fiber bi- alternative ring path + directional + line switched + ring) + + UPSR (uni- No Dedicated protection via + directional alternative ring path. + path switched Typically used in access + ring) networks. + + It may be desirable to route some connections over lines that support + protection of a given type, while others may be routed over + unprotected lines, or as "extra traffic" over protection lines. + Also, to assist in the configuration of these various protection + methods, it can be extremely valuable to advertise the link + protection attributes in the routing protocol, as is done in the + current GMPLS routing protocols. For example, suppose that a 1:N + protection group is being configured via two nodes. One must make + + + + +Bernstein, et al. Informational [Page 21] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + + sure that the lines are "numbered the same" with respect to both ends + of the connection, or else the APS (K1/K2 byte) protocol will not + correctly operate. + + Table 6. Parameters defining protection mechanisms. + + Protection Comments + Related Link + Information + + + Protection Type Indicates which of the protection types + delineated in Table 5. + + Protection Indicates which of several protection + Group Id groups (linear or ring) that a node belongs + to. Must be unique for all groups that a + node participates in + + Working line Important in 1:N case and to differentiate + number between working and protection lines + + Protection line Used to indicate if the line is a + number protection line. + + Extra Traffic Yes or No + Supported + + Layer If this protection parameter is specific to + SONET then this parameter is unneeded, + otherwise it would indicate the signal + layer that the protection is applied. + + An open issue concerning protection is the extent of information + regarding protection that must be disseminated. The contents of + Table 6 represent one extreme, while a simple enumerated list + (Extra-Traffic/Protection line, Unprotected, Shared (1:N)/Working + line, Dedicated (1:1, 1+1)/Working Line, Enhanced (Ring) /Working + Line) represents the other. + + There is also a potential implication for link bundling [13], [15] + that is, for each link, the routing protocol could advertise whether + that link is a working or protection link and possibly some + parameters from Table 6. A possible drawback of this scheme is that + the routing protocol would be burdened with advertising properties + even for those protection links in the network that could not, in + fact, be used for routing working traffic, e.g., dedicated protection + links. An alternative method would be to bundle the working and + + + +Bernstein, et al. Informational [Page 22] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + + protection links together, and advertise the bundle instead. Now, + for each bundled link, the protocol would have to advertise the + amount of bandwidth available on its working links, as well as the + amount of bandwidth available on those protection links within the + bundle that were capable of carrying "extra traffic". This would + reduce the amount of information to be advertised. An issue here + would be to decide which types of working and protection links to + bundle together. For instance, it might be preferable to bundle + working links (and their corresponding protection links) that are + "shared" protected separately from working links that are "dedicated" + protected. + +4.3. Available Capacity Advertisement + + Each SDH/SONET LSR must maintain an internal table per interface that + indicates each signal in the multiplex structure that is allocated at + that interface. This internal table is the most complete and + accurate view of the link usage and available capacity. + + For use in path computation, this information needs to be advertised + in some way to all other SDH/SONET LSRs in the same domain. There is + a trade off to be reached concerning: the amount of detail in the + available capacity information to be reported via a link state + routing protocol, the frequency or conditions under which this + information is updated, the percentage of connection establishments + that are unsuccessful on their first attempt due to the granularity + of the advertised information, and the extent to which network + resources can be optimized. There are different levels of + summarization that are being considered today for the available + capacity information. At one extreme, all signals that are allocated + on an interface could be advertised; while at the other extreme, a + single aggregated value of the available bandwidth per link could be + advertised. + + Consider first the relatively simple structure of SONET and its most + common current and planned usage. DS1s and DS3s are the signals most + often carried within a SONET STS-1. Either a single DS3 occupies the + STS-1 or up to 28 DS1s (4 each within the 7 VT groups) are carried + within the STS-1. With a reasonable VT1.5 placement algorithm within + each node, it may be possible to just report on aggregate bandwidth + usage in terms of number of whole STS-1s (dedicated to DS3s) used and + the number of STS-1s dedicated to carrying DS1s allocated for this + purpose. This way, a network optimization program could try to + determine the optimal placement of DS3s and DS1s to minimize wasted + bandwidth due to half-empty STS-1s at various places within the + transport network. Similarly consider the set of super rate SONET + signals (STS-Nc). If the links between the two switches support + flexible concatenation, then the reporting is particularly + + + +Bernstein, et al. Informational [Page 23] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + + straightforward since any of the STS-1s within an STS-M can be used + to comprise the transported STS-Nc. However, if only standard + concatenation is supported, then reporting gets trickier since there + are constraints on where the STS-1s can be placed. SDH has still + more options and constraints, hence it is not yet clear which is the + best way to advertise bandwidth resource availability/usage in + SDH/SONET. At present, the GMPLS routing protocol extensions define + minimum and maximum values for available bandwidth, which allows a + remote node to make some deductions about the amount of capacity + available at a remote link and the types of signals it can + accommodate. However, due to the multiplexed nature of the signals, + reporting of bandwidth particular to signal types, rather than as a + single aggregate bit rate, may be desirable. For details on why this + may be the case, we refer the reader to ITU-T publications G.7715.1 + [16] and to Chapter 12 of [17]. + +4.4. Path Computation + + Although a link state routing protocol can be used to obtain network + topology and resource information, this does not imply the use of an + "open shortest path first" route [6]. The path must be open in the + sense that the links must be capable of supporting the desired signal + type and that capacity must be available to carry the signal. Other + constraints may include hop count, total delay (mostly propagation), + and underlying protection. In addition, it may be desirable to route + traffic in order to optimize overall network capacity, or + reliability, or some combination of the two. Dikstra's algorithm + computes the shortest path with respect to link weights for a single + connection at a time. This can be much different than the paths that + would be selected in response to a request to set up a batch of + connections between a set of endpoints in order to optimize network + link utilization. One can think of this along the lines of global or + local optimization of the network in time. + + Due to the complexity of some of the connection routing algorithms + (high dimensionality, non-linear integer programming problems) and + various criteria by which one may optimize a network, it may not be + possible or desirable to run these algorithms on network nodes. + However, it may still be desirable to have some basic path + computation ability running on the network nodes, particularly for + use during restoration situations. Such an approach is in line with + the use of GMPLS for traffic engineering, but is much different than + typical OSPF or IS-IS usage where all nodes must run the same routing + algorithm. + + + + + + + +Bernstein, et al. Informational [Page 24] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + +5. LSP Provisioning/Signaling for SDH/SONET + + Traditionally, end-to-end circuit connections in SDH/SONET networks + have been set up via network management systems (NMSs), which issue + commands (usually under the control of a human operator) to the + various network elements involved in the circuit, via an equipment + vendor's element management system (EMS). Very little multi-vendor + interoperability has been achieved via management systems. Hence, + end-to-end circuits in a multi-vendor environment typically require + the use of multiple management systems and the infamous configuration + via "yellow sticky notes". As discussed in Section 3, a common + signaling protocol -- such as RSVP with TE extensions or CR-LDP -- + appropriately extended for circuit switching applications, could + therefore help to solve these interoperability problems. In this + section, we examine the various components involved in the automated + provisioning of SDH/SONET LSPs. + +5.1. What Do We Label in SDH/SONET? Frames or Circuits? + + GMPLS was initially introduced to control asynchronous technologies + like IP, where a label was attached to each individual block of data, + such as an IP packet or a Frame Relay frame. SONET and SDH, however, + are synchronous technologies that define a multiplexing structure + (see Section 3), which we referred to as the SDH (or SONET) + multiplex. This multiplex involves a hierarchy of signals, lower + order signals embedded within successive higher order ones (see Fig. + 1). Thus, depending on its level in the hierarchy, each signal + consists of frames that repeat periodically, with a certain number of + byte time slots per frame. + + The question then arises: is it these frames that we label in GMPLS? + It will be seen in what follows that each SONET or SDH "frame" need + not have its own label, nor is it necessary to switch frames + individually. Rather, the unit that is switched is a "flow" + comprised of a continuous sequence of time slots that appear at a + given position in a frame. That is, we switch an individual SONET or + SDH signal, and a label associated with each given signal. + + For instance, the payload of an SDH STM-1 frame does not fully + contain a complete unit of user data. In fact, the user data is + contained in a virtual container (VC) that is allowed to float over + two contiguous frames for synchronization purposes. The H1-H2-H3 + Au-n pointer bytes in the SDH overhead indicates the beginning of the + VC in the payload. Thus, frames are now inter-related, since each + consecutive pair may share a common virtual container. From the + point of view of GMPLS, therefore, it is not the successive frames + that are treated independently or labeled, but rather the entire user + signal. An identical argument applies to SONET. + + + +Bernstein, et al. Informational [Page 25] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + + Observe also that the GMPLS signaling used to control the SDH/SONET + multiplex must honor its hierarchy. In other words, the SDH/SONET + layer should not be viewed as homogeneous and flat, because this + would limit the scope of the services that SDH/SONET can provide. + Instead, GMPLS tunnels should be used to dynamically and + hierarchically control the SDH/SONET multiplex. For example, one + unstructured VC-4 LSP may be established between two nodes, and later + lower order LSPs (e.g., VC-12) may be created within that higher + order LSP. This VC-4 LSP can, in fact, be established between two + non-adjacent internal nodes in an SDH network, and later advertised + by a routing protocol as a new (virtual) link called a Forwarding + Adjacency (FA) [14]. + + An SDH/SONET-LSR will have to identify each possible signal + individually per interface to fulfill the GMPLS operations. In order + to stay transparent, the LSR obviously should not touch the SDH/SONET + overheads; this is why an explicit label is not encoded in the + SDH/SONET overheads. Rather, a label is associated with each + individual signal. This approach is similar to the one considered + for lambda switching, except that it is more complex, since SONET and + SDH define a richer multiplexing structure. Therefore, a label is + associated with each signal, and is locally unique for each signal at + each interface. This signal could, and will most probably, occupy + different time-slots at different interfaces. + +5.2. Label Structure in SDH/SONET + + The signaling protocol used to establish an SDH/SONET LSP must have + specific information elements in it to map a label to the particular + signal type that it represents, and to the position of that signal in + the SDH/SONET multiplex. As we will see shortly, with a carefully + chosen label structure, the label itself can be made to function as + this information element. + + In general, there are two ways to assign labels for signals between + neighboring SDH/SONET LSRs. One way is for the labels to be + allocated completely independently of any SDH/SONET semantics; e.g., + labels could just be unstructured 16 or 32 bit numbers. In that + case, in the absence of appropriate binding information, a label + gives no visible information about the flow that it represents. From + a management and debugging point of view, therefore, it becomes + difficult to match a label with the corresponding signal, since , as + we saw in Section 6.1, the label is not coded in the SDH/SONET + overhead of the signal. + + Another way is to use the well-defined and finite structure of the + SDH/SONET multiplexing tree to devise a signal numbering scheme that + makes use of the multiplex as a naming tree, and assigns each + + + +Bernstein, et al. Informational [Page 26] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + + multiplex entry a unique associated value. This allows the unique + identification of each multiplex entry (signal) in terms of its type + and position in the multiplex tree. By using this multiplex entry + value itself as the label, we automatically add SDH/SONET semantics + to the label! Thus, simply by examining the label, one can now + directly deduce the signal that it represents, as well as its + position in the SDH/SONET multiplex. We refer to this as multiplex- + based labeling. This is the idea that was incorporated in the GMPLS + signaling specifications for SDH/SONET [15]. + +5.3. Signaling Elements + + In the preceding sections, we defined the meaning of an SDH/SONET + label and specified its structure. A question that arises naturally + at this point is the following. In an LSP or connection setup + request, how do we specify the signal for which we want to establish + a path (and for which we desire a label)? + + Clearly, information that is required to completely specify the + desired signal and its characteristics must be transferred via the + label distribution protocol, so that the switches along the path can + be configured to correctly handle and switch the signal. This + information is specified in three parts [15], each of which refers to + a different network layer. + + 1. GENERALIZED_LABEL REQUEST (as in [4], [5]), which contains three + parts: LSP Encoding Type, Switching Type, and G-PID. + + The first specifies the nature/type of the LSP or the desired + SDH/SONET channel, in terms of the particular signal (or collection + of signals) within the SDH/SONET multiplex that the LSP represents, + and is used by all the nodes along the path of the LSP. + + The second specifies certain link selection constraints, which + control, at each hop, the selection of the underlying link that is + used to transport this LSP. + + The third specifies the payload carried by the LSP or SDH/SONET + channel, in terms of the termination and adaptation functions + required at the end points, and is used by the source and destination + nodes of the LSP. + + 2. SONET/SDH TRAFFIC_PARAMETERS (as in [15], Section 2.1) used as a + SENDER_TSPEC/FLOWSPEC, which contains 7 parts: Signal Type, + (Requested Contiguous Concatenation (RCC), Number of Contiguous + Components (NCC), Number of Virtual Components (NVC)), Multiplier + (MT), Transparency, and Profile. + + + + +Bernstein, et al. Informational [Page 27] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + + The Signal Type indicates the type of elementary signal comprising + the LSP, while the remaining fields indicate transforms that can be + applied to the basic signal to build the final signal that + corresponds to the LSP actually being requested. For instance (see + [15] for details): + + - Contiguous concatenation (by using the RCC and NCC fields) can + be optionally applied on the Elementary Signal, resulting in a + contiguously concatenated signal. + + - Then, virtual concatenation (by using the NVC field) can be + optionally applied on the Elementary Signal, resulting in a + virtually concatenated signal. + + - Third, some transparency (by using the Transparency field) can + be optionally specified when requesting a frame as a signal + rather than an SPE- or VC-based signal. + + - Fourth, a multiplication (by using the Multiplier field) can be + optionally applied either directly on the Elementary Signal or + on the contiguously concatenated signal obtained from the first + phase, or on the virtually concatenated signal obtained from the + second phase, or on these signals combined with some + transparency. + + Transparency indicates precisely which fields in these overheads must + be delivered unmodified at the other end of the LSP. An ingress LSR + requesting transparency will pass these overhead fields that must be + delivered to the egress LSR without any change. From the ingress and + egress LSRs point of views, these fields must be seen as unmodified. + + Transparency is not applied at the interfaces with the initiating and + terminating LSRs, but is only applied between intermediate LSRs. + + The transparency field is used to request an LSP that supports the + requested transparency type; it may also be used to setup the + transparency process to be applied at each intermediate LSR. + + Finally, the profile field is intended to specify particular + capabilities that must be supported for the LSP, for example + monitoring capabilities. However, no standard profile is currently + defined. + + 3. UPSTREAM_LABEL for Bi-directional LSP's (as in [4], [5]). + + 4. Local Link Selection, e.g., IF_ID_RSVP_HOP Object (as in [5]). + + + + + +Bernstein, et al. Informational [Page 28] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + +6. Summary and Conclusions + + We provided a detailed account of the issues involved in applying + generalized GMPLS-based control (GMPLS) to TDM networks. + + We began with a brief overview of GMPLS and SDH/SONET networks, + discussing current circuit establishment in TDM networks, and arguing + why SDH/SONET technologies will not be "outdated" in the foreseeable + future. Next, we looked at IP/MPLS applied to SDH/SONET networks, + where we considered why such an application makes sense, and reviewed + some GMPLS terminology as applied to TDM networks. + + We considered the two main areas of application of IP/MPLS methods to + TDM networks, namely routing and signaling, and discussed how + Generalized MPLS routing and signaling are used in the context of TDM + networks. We reviewed in detail the switching capabilities of TDM + equipment, and the requirement to learn about the protection + capabilities of underlying links, and how these influence the + available capacity advertisement in TDM networks. + + We focused briefly on path computation methods, pointing out that + these were not subject to standardization. We then examined optical + path provisioning or signaling, considering the issue of what + constitutes an appropriate label for TDM circuits and how this label + should be structured; and we focused on the importance of + hierarchical label allocation in a TDM network. Finally, we reviewed + the signaling elements involved when setting up a TDM circuit, + focusing on the nature of the LSP, the type of payload it carries, + and the characteristics of the links that the LSP wishes to use at + each hop along its path for achieving a certain reliability. + +7. Security Considerations + + The use of a control plane to provision connectivity through a + SONET/SDH network shifts the security burden significantly from the + management plane to the control plane. Before the introduction of a + control plane, the communications that had to be secured were between + the management stations (Element Management Systems or Network + Management Systems) and each network element that participated in the + network connection. After the introduction of the control plane, the + only management plane communication that needs to be secured is that + to the head-end (ingress) network node as the end-to-end service is + requested. On the other hand, the control plane introduces a new + requirement to secure signaling and routing communications between + adjacent nodes in the network plane. + + + + + + +Bernstein, et al. Informational [Page 29] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + + The security risk from impersonated management stations is + significantly reduced by the use of a control plane. In particular, + where unsecure versions of network management protocols such as SNMP + versions 1 and 2 were popular configuration tools in transport + networks, the use of a control plane may significantly reduce the + security risk of malicious and false assignment of network resources + that could cause the interception or disruption of data traffic. + + On the other hand, the control plane may increase the number of + security relationships that each network node must maintain. Instead + of a single security relationship with its management element, each + network node must now maintain a security relationship with each of + its signaling and routing neighbors in the control plane. + + There is a strong requirement for signaling and control plane + exchanges to be secured, and any protocols proposed for this purpose + must be capable of secure message exchanges. This is already the + case for the existing GMPLS routing and signaling protocols. + +8. Acknowledgements + + We acknowledge all the participants of the MPLS and CCAMP WGs, whose + constant enquiry about GMPLS issues in TDM networks motivated the + writing of this document, and whose questions helped shape its + contents. Also, thanks to Kireeti Kompella for his careful reading + of the last version of this document, and for his helpful comments + and feedback, and to Dimitri Papadimitriou for his review on behalf + of the Routing Area Directorate, which provided many useful inputs to + help update the document to conform to the standards evolutions since + this document passed last call. + + + + + + + + + + + + + + + + + + + + + +Bernstein, et al. Informational [Page 30] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + +9. Informative References + + In the ITU references below, please see http://www.itu.int for + availability of ITU documents. For ANSI references, please see the + Library available through http://www.ansi.org. + + [1] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label + Switching Architecture", RFC 3031, January 2001. + + [2] G.707, Network Node Interface for the Synchronous Digital + Hierarchy (SDH), International Telecommunication Union, March + 1996. + + [3] ANSI T1.105-1995, Synchronous Optical Network (SONET) Basic + Description including Multiplex Structure, Rates, and Formats, + American National Standards Institute. + + [4] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) + Signaling Functional Description", RFC 3471, January 2003. + + [5] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) + Signaling Resource ReserVation Protocol-Traffic Engineering + (RSVP-TE) Extensions", RFC 3473, January 2003. + + [6] Bernstein, G., Yates, J., Saha, D., "IP-Centric Control and + Management of Optical Transport Networks," IEEE Communications + Mag., Vol. 40, Issue 10, October 2000. + + [7] ANSI T1.105.01-1995, Synchronous Optical Network (SONET) + Automatic Protection Switching, American National Standards + Institute. + + [8] G.841, Types and Characteristics of SDH Network Protection + Architectures, ITU-T, July 1995. + + [9] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in + Support of Generalized Multi-Protocol Label Switching (GMPLS)", + RFC 4202, October 2005. + + [10] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in + Support of Generalized Multi-Protocol Label Switching (GMPLS)", + RFC 4203, October 2005. + + [11] Kompella, K., Ed. and Y. Rekhter, Ed., "Intermediate System to + Intermediate System (IS-IS) Extensions in Support of Generalized + Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005. + + + + + +Bernstein, et al. Informational [Page 31] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + + [12] Bernstein, G., Sharma, V., Ong, L., "Inter-domain Optical + Routing," OSA J. of Optical Networking, vol. 1, no. 2, pp. 80- + 92. + + [13] Kompella, K., Rekhter, Y. and L. Berger, "Link Bundling in MPLS + Traffic Engineering (TE)", RFC 4201, October 2005. + + [14] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) + Hierarchy with Generalized Multi-Protocol Label Switching + (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. + + [15] Mannie, E. and D. Papadimitriou, "Generalized Multi-Protocol + Label Switching (GMPLS) Extensions for Synchronous Optical + Network (SONET) and Synchronous Digital Hierarchy (SDH) + Control", RFC 3946, October 2004. + + [16] G.7715.1, ASON Routing Architecture and Requirements for Link- + State Protocols, International Telecommunications Union, + February 2004. + + [17] Bernstein, G., Rajagopalan, R., and Saha, D., "Optical Network + Control: Protocols, Architectures, and Standards," Addison- + Wesley, July 2003. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bernstein, et al. Informational [Page 32] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + +10. Acronyms + + ANSI - American National Standards Institute + APS - Automatic Protection Switching + ATM - Asynchronous Transfer Mode + BLSR - Bi-directional Line Switch Ring + CPE - Customer Premise Equipment + DLCI - Data Link Connection Identifier + ETSI - European Telecommunication Standards Institute + FEC - Forwarding Equivalency Class + GMPLS - Generalized MPLS + IP - Internet Protocol + IS-IS - Intermediate System to Intermediate System (RP) + LDP - Label Distribution Protocol + LSP - Label Switched Path + LSR - Label Switching Router + MPLS - Multi-Protocol Label Switching + NMS - Network Management System + OSPF - Open Shortest Path First (RP) + PNNI - Private Network Node Interface + PPP - Point to Point Protocol + QoS - Quality of Service + RP - Routing Protocol + RSVP - ReSerVation Protocol + SDH - Synchronous Digital Hierarchy + SNMP - Simple Network Management Protocol + SONET - Synchronous Optical NETworking + SPE - SONET Payload Envelope + STM - Synchronous Transport Module (or Terminal Multiplexer) + STS - Synchronous Transport Signal + TDM - Time Division Multiplexer + TE - Traffic Engineering + TMN - Telecommunication Management Network + UPSR - Uni-directional Path Switch Ring + VC - Virtual Container (SDH) or Virtual Circuit + VCI - Virtual Circuit Identifier (ATM) + VPI - Virtual Path Identifier (ATM) + VT - Virtual Tributary + WDM - Wavelength-Division Multiplexing + + + + + + + + + + + + +Bernstein, et al. Informational [Page 33] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + +Author's Addresses + + Greg Bernstein + Grotto Networking + + Phone: +1 510 573-2237 + EMail: gregb@grotto-networking.com + + + Eric Mannie + Perceval + Rue Tenbosch, 9 + 1000 Brussels + Belgium + + Phone: +32-2-6409194 + EMail: eric.mannie@perceval.net + + + Vishal Sharma + Metanoia, Inc. + 888 Villa Street, Suite 500 + Mountain View, CA 94041 + + Phone: +1 650 641 0082 + Email: v.sharma@ieee.org + + + Eric Gray + Marconi Corporation, plc + 900 Chelmsford Street + Lowell, MA 01851 + USA + + Phone: +1 978 275 7470 + EMail: Eric.Gray@Marconi.com + + + + + + + + + + + + + + + +Bernstein, et al. Informational [Page 34] + +RFC 4257 GMPLS based Control of SDH/SONET December 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Bernstein, et al. Informational [Page 35] + |