draft-ietf-ccamp-sdhsonet-control-03.txt | draft-ietf-ccamp-sdhsonet-control-04.txt | |||
---|---|---|---|---|
CCAMP Working Group G. Bernstein (Grotto Networking) | Network Working Group G. Bernstein (Grotto Networking) | |||
Internet Draft E. Mannie (InterAir Link) | Internet Draft E. Mannie (InterAir Link) | |||
Document: <draft-ietf-ccamp-sdhsonet- V. Sharma (Metanoia, Inc.) | Category: Informational V. Sharma (Metanoia, Inc.) | |||
control-03.txt> | E. Gray (Marconi Communications) | |||
Category: Informational | Expires March 30, 2005 September 2004 | |||
Expires January 2005 July 2004 | ||||
Framework for GMPLS-based Control of SDH/SONET Networks | Framework for GMPLS-based Control of SDH/SONET Networks | |||
<draft-ietf-ccamp-sdhsonet-control-03.txt> | <draft-ietf-ccamp-sdhsonet-control-04.txt> | |||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft and is in full conformance with | This document is an Internet-Draft and is subject to all provisions | |||
all provisions of Section 10 of RFC2026 [1]. | of section 3 of RFC 3667 [1]. 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 of will be disclosed, in | ||||
accordance with RFC 3668 [2]. | ||||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
Internet-Drafts are draft documents valid for a maximum of six | Internet-Drafts are draft documents valid for a maximum of six | |||
months and may be updated, replaced, or obsoleted by other documents | months and may be updated, replaced, or obsoleted by other documents | |||
at any time. It is inappropriate to use Internet- Drafts as | at any time. It is inappropriate to use Internet-Drafts as reference | |||
reference material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
Abstract | Abstract | |||
The suite of protocols that defines Multi-Protocol Label Switching | GMPLS consists of a suite of protocol extensions to MPLS to make | |||
(MPLS) is in the process of enhancement to generalize its | these protocols more generally applicable, to include - for example | |||
applicability to the control of non-packet based switching, that is, | - control of non-packet based switching, and particularly, optical | |||
optical switching. One area of prime consideration is to use these | switching. One area of prime consideration is to use Generalized | |||
generalized MPLS (GMPLS) protocols in upgrading the control plane of | MPLS (GMPLS) protocols in upgrading the control plane of optical | |||
optical transport networks. This document illustrates this process | transport networks. This document illustrates this process by | |||
by describing those extensions to MPLS protocols that are directed | describing those extensions to GMPLS protocols that are directed | |||
towards controlling SDH/SONET networks. SDH/SONET networks make | towards controlling SDH/SONET networks. SDH/SONET networks make | |||
very good examples of this process since they possess a rich | very good examples of this process since they possess a rich | |||
multiplex structure, a variety of protection/restoration options, | multiplex structure, a variety of protection/restoration options, | |||
are well defined, and are widely deployed. The document discusses | are well defined, and are widely deployed. The document discusses | |||
extensions to MPLS routing protocols to disseminate information | extensions to GMPLS routing protocols to disseminate information | |||
needed in transport path computation and network operations, | needed in transport path computation and network operations, | |||
together with the extensions to MPLS label distribution protocols | together with the extensions to GMPLS label distribution protocols | |||
needed for the provisioning of transport circuits. New capabilities | needed for the provisioning of transport circuits. New capabilities | |||
that an MPLS control plane would bring to SDH/SONET networks, such | that an GMPLS control plane would bring to SDH/SONET networks, such | |||
as new restoration methods and multi-layer circuit establishment, | as new restoration methods and multi-layer circuit establishment, | |||
are also discussed. | are also discussed. | |||
Bernstein/Mannie/Sharma Informational-January 2005 1 | Internet Draft Expires March 2005 Page 1 | |||
GMPLS based Control of SDH/SONET July 2004 | Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | |||
1. Conventions used in this document................................2 | ||||
2. Introduction.....................................................3 | ||||
2.1. MPLS Overview..................................................3 | ||||
2.2. SDH/SONET Overview.............................................4 | ||||
2.3. The Current State of Circuit Establishment in SDH/SONET | ||||
Networks.............................................................7 | ||||
2.3.1. Administrative Tasks.......................................7 | ||||
2.3.2. Manual Operations..........................................7 | ||||
2.3.3. Planning Tool Operation....................................7 | ||||
2.3.4. Circuit Provisioning.......................................8 | ||||
2.4. Centralized Approach versus Distributed Approach...............8 | ||||
2.4.1. Topology Discovery and Resource Dissemination..............9 | ||||
2.4.2. Path Computation (Route Determination).....................9 | ||||
2.4.3. Connection Establishment (Provisioning)...................10 | ||||
2.5. Why SDH/SONET will not Disappear Tomorrow.....................11 | ||||
3. GMPLS Applied to SDH/SONET......................................12 | ||||
3.1. Controlling the SDH/SONET Multiplex...........................12 | ||||
3.2. SDH/SONET LSR and LSP Terminology.............................13 | ||||
4. Decomposition of the MPLS Circuit-Switching Problem Space.......13 | ||||
5. GMPLS Routing for SDH/SONET.....................................14 | ||||
5.1. Switching Capabilities........................................15 | ||||
5.1.1. Switching Granularity.....................................15 | ||||
5.1.2. Signal Concatenation Capabilities.........................16 | ||||
5.1.3. SDH/SONET Transparency....................................17 | ||||
5.2. Protection....................................................18 | ||||
5.3. Available Capacity Advertisement..............................21 | ||||
5.4. Path Computation..............................................22 | ||||
6. LSP Provisioning/Signaling for SDH/SONET........................22 | ||||
6.1. What do we Label in SDH/SONET? Frames or Circuits?............23 | ||||
6.2. Label Structure in SDH/SONET..................................24 | ||||
6.3. Signaling Elements............................................24 | ||||
7. Summary and Conclusions.........................................26 | ||||
8. Security Considerations.........................................27 | ||||
9. Acknowledgments.................................................27 | ||||
10. Author's Addresses..............................................27 | ||||
11. References......................................................27 | ||||
11.1. Normative References........................................27 | ||||
11.2. Informative References......................................28 | ||||
12. Intellectual Property Considerations............................29 | ||||
12.1. IPR Disclosure Acknowledgement..............................29 | ||||
13. Full Copyright Statement........................................29 | ||||
1. Conventions used in this document | ||||
Bernstein/Mannie/Sharma Expires January 2005 2 | 1. Introduction.................................................3 | |||
GMPLS based Control of SDH/SONET July 2004 | 1.1. MPLS Overview..............................................3 | |||
1.2. SDH/SONET Overview.........................................4 | ||||
1.3. The Current State of Circuit Establishment in SDH/SONET | ||||
Networks...................................................7 | ||||
1.3.1. Administrative Tasks...................................7 | ||||
1.3.2. Manual Operations......................................7 | ||||
1.3.3. Planning Tool Operation................................7 | ||||
1.3.4. Circuit Provisioning...................................8 | ||||
1.4. Centralized Approach versus Distributed Approach...........8 | ||||
1.4.1. Topology Discovery and Resource Dissemination..........9 | ||||
1.4.2. Path Computation (Route Determination).................9 | ||||
1.4.3. Connection Establishment (Provisioning)...............10 | ||||
1.5. Why SDH/SONET will not Disappear Tomorrow.................11 | ||||
2. GMPLS Applied to SDH/SONET..................................12 | ||||
2.1. Controlling the SDH/SONET Multiplex.......................12 | ||||
2.2. SDH/SONET LSR and LSP Terminology.........................13 | ||||
3. Decomposition of the GMPLS Circuit-Switching Problem Space..13 | ||||
4. GMPLS Routing for SDH/SONET.................................14 | ||||
4.1. Switching Capabilities....................................15 | ||||
4.1.1. Switching Granularity.................................15 | ||||
4.1.2. Signal Concatenation Capabilities.....................16 | ||||
4.1.3. SDH/SONET Transparency................................17 | ||||
4.2. Protection................................................18 | ||||
4.3. Available Capacity Advertisement..........................21 | ||||
4.4. Path Computation..........................................22 | ||||
5. LSP Provisioning/Signaling for SDH/SONET....................22 | ||||
5.1. What do we Label in SDH/SONET? Frames or Circuits?........23 | ||||
5.2. Label Structure in SDH/SONET..............................24 | ||||
5.3. Signaling Elements........................................24 | ||||
6. Summary and Conclusions.....................................26 | ||||
7. Security Considerations.....................................27 | ||||
8. Acknowledgments.............................................27 | ||||
9. Author's Addresses..........................................27 | ||||
10. References..................................................28 | ||||
10.1. Normative References....................................28 | ||||
10.2. Informative References..................................28 | ||||
11. Intellectual Property Statement.............................29 | ||||
12. Disclaimer of Validity......................................30 | ||||
13. Copyright Statement.........................................30 | ||||
14. Acknowledgement..............................................30 | ||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | Internet Draft Expires March 2005 Page 2 | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in | Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | |||
this document are to be interpreted as described in RFC-2119 [2]. | ||||
2. Introduction | 1. Introduction | |||
The CCAMP Working Group of the IETF is currently working on | The CCAMP Working Group of the IETF has the goal of extending MPLS | |||
extending MPLS [3] protocols to support multiple network layers and | [3] protocols to support multiple network layers and new services. | |||
new services. This extended MPLS, which was initially known as | This extended MPLS, which was initially known as Multi-Protocol | |||
Multi-Protocol Lambda Switching, is now better referred to as | Lambda Switching, is now better referred to as Generalized MPLS (or | |||
Generalized MPLS (or GMPLS). | GMPLS). | |||
The GMPLS effort is, in effect, extending IP/MPLS technology to | The GMPLS effort is, in effect, extending IP/MPLS technology to | |||
control and manage lower layers. Using the same framework and | control and manage lower layers. Using the same framework and | |||
similar signaling and routing protocols to control multiple layers | similar signaling and routing protocols to control multiple layers | |||
can not only reduce the overall complexity of designing, deploying | can not only reduce the overall complexity of designing, deploying | |||
and maintaining networks, but can also make it possible to operate | and maintaining networks, but can also make it possible to operate | |||
two contiguous layers by using either an overlay model, a peer | two contiguous layers by using either an overlay model, a peer | |||
model, or an integrated model. The benefits of using a peer or an | 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 | 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, | have to be clarified and evaluated in the future. In the mean time, | |||
GMPLS could be used for controlling each layer independently. | GMPLS could be used for controlling each layer independently. | |||
The goal of this work is to highlight how MPLS could be used to | The goal of this work is to highlight how GMPLS could be used to | |||
dynamically establish, maintain, and tear down SDH/SONET circuits. | dynamically establish, maintain, and tear down SDH/SONET circuits. | |||
The objective of using these extended IP/MPLS protocols is to | The objective of using these extended IP/MPLS protocols is to | |||
provide at least the same kinds of SDH/SONET services as are | provide at least the same kinds of SDH/SONET services as are | |||
provided today, but using signaling instead of provisioning via | provided today, but using signaling instead of provisioning via | |||
centralized management to establish those services. This will allow | centralized management to establish those services. This will allow | |||
operators to propose new services, and will allow clients to create | operators to propose new services, and will allow clients to create | |||
SDH/SONET paths on-demand, in real-time, through the provider | SDH/SONET paths on-demand, in real-time, through the provider | |||
network. We first review the essential properties of SDH/SONET | network. We first review the essential properties of SDH/SONET | |||
networks and their operations, and we show how the label concept in | networks and their operations, and we show how the label concept in | |||
MPLS can be extended to the SDH/SONET case. We then look at | GMPLS can be extended to the SDH/SONET case. We then look at | |||
important information to be disseminated by a link state routing | important information to be disseminated by a link state routing | |||
protocol and look at the important signal attributes that need to be | protocol and look at the important signal attributes that need to be | |||
conveyed by a label distribution protocol. Finally, we look at some | conveyed by a label distribution protocol. Finally, we look at some | |||
outstanding issues and future possibilities. | outstanding issues and future possibilities. | |||
2.1. MPLS Overview | 1.1. MPLS Overview | |||
A major advantage of the MPLS architecture [3] for use as a general | A major advantage of the MPLS architecture [3] for use as a general | |||
network control plane is its clear separation between the forwarding | network control plane is its clear separation between the forwarding | |||
(or data) plane, the signaling (or connection control) plane, and | (or data) plane, the signaling (or connection control) plane, and | |||
the routing (or topology discovery/resource status) plane. This | the routing (or topology discovery/resource status) plane. This | |||
allows the work on MPLS extensions to focus on the forwarding and | allows the work on MPLS extensions to focus on the forwarding and | |||
signaling planes, while allowing well-known IP routing protocols to | signaling planes, while allowing well-known IP routing protocols to | |||
be reused in the routing plane. This clear separation also allows | 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- | for MPLS to be used to control networks that do not have a packet- | |||
based forwarding plane. | based forwarding plane. | |||
Bernstein/Mannie/Sharma Expires January 2005 3 | ||||
GMPLS based Control of SDH/SONET July 2004 | ||||
An MPLS network consists of MPLS nodes called Label Switch Routers | An MPLS network consists of MPLS nodes called Label Switch Routers | |||
(LSRs) connected via circuits called Label Switched Paths (LSPs). An | (LSRs) connected via circuits called Label Switched Paths (LSPs). An | |||
LSP is unidirectional and could be of several different types such | LSP is unidirectional and could be of several different types such | |||
as point-to-point, point-to-multipoint, and multipoint-to-point. | as point-to-point, point-to-multipoint, and multipoint-to-point. | |||
Internet Draft Expires March 2005 Page 3 | ||||
Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | ||||
Border LSRs in an MPLS network act either as ingress or egress LSRs | Border LSRs in an MPLS network act either as ingress or egress LSRs | |||
depending on the direction of the traffic being forwarded. | depending on the direction of the traffic being forwarded. | |||
Each LSP is associated with a Fowarding Equivalence Class (FEC), | Each LSP is associated with a Fowarding Equivalence Class (FEC), | |||
which may be thought of as a set of packets that receive identical | 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 | forwarding treatment at an LSR. The simplest example of an FEC might | |||
be the set of destination addresses lying in a given address range. | be the set of destination addresses lying in a given address range. | |||
All packets that have a destination address lying within this | All packets that have a destination address lying within this | |||
address range are forwarded identically at each LSR configured with | address range are forwarded identically at each LSR configured with | |||
that FEC. | that FEC. | |||
To establish an LSP, a signaling protocol (or label distribution | To establish an LSP, a signaling protocol (or label distribution | |||
protocol) such as LDP/CR-LDP or RSVP-TE is required. Between two | protocol) such as LDP or RSVP-TE is required. Between two adjacent | |||
adjacent LSRs, an LSP is locally identified by a short, fixed length | LSRs, an LSP is locally identified by a fixed length identifier | |||
identifier called a label, which is only significant between those | called a label, which is only significant between those two LSRs. | |||
two LSRs. The signaling protocol is responsible for the inter-node | A signaling protocol is used for inter-node communication to assign | |||
communication that assigns and maintains these labels. | and maintain these labels. | |||
When a packet enters an MPLS-based packet network, it is classified | When a packet enters an MPLS-based packet network, it is classified | |||
according to its FEC and, possibly, additional rules, which together | according to its FEC and, possibly, additional rules, which together | |||
determine the LSP along which the packet must be sent. For this | determine the LSP along which the packet must be sent. For this | |||
purpose, the ingress LSR attaches an appropriate label to the | purpose, the ingress LSR attaches an appropriate label to the | |||
packet, and forwards the packet to the next hop. The label may be | 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 | 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 | 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 | 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 | 2 encapsulation of the packet. In case of SDH/SONET networks, we | |||
skipping to change at line 202 | skipping to change at line 200 | |||
When a packet reaches a packet LSR, this LSR uses the label as an | 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 | index into a forwarding table to determine the next hop and the | |||
corresponding outgoing label (and, possibly, the QoS treatment to be | corresponding outgoing label (and, possibly, the QoS treatment to be | |||
given to the packet), writes the new label into the packet, and | given to the packet), writes the new label into the packet, and | |||
forwards the packet to the next hop. When the packet reaches the | forwards the packet to the next hop. When the packet reaches the | |||
egress LSR, the label is removed and the packet is forwarded using | egress LSR, the label is removed and the packet is forwarded using | |||
appropriate forwarding, such as normal IP forwarding. We will see | appropriate forwarding, such as normal IP forwarding. We will see | |||
that for a SDH/SONET network these operations do not occur in quite | that for a SDH/SONET network these operations do not occur in quite | |||
the same way. | the same way. | |||
2.2. SDH/SONET Overview | 1.2. SDH/SONET Overview | |||
There are currently two different multiplexing technologies in use | There are currently two different multiplexing technologies in use | |||
in optical networks: wavelength division multiplexing (WDM) and time | in optical networks: wavelength division multiplexing (WDM) and time | |||
division multiplexing (TDM). This work focuses on TDM technology. | division multiplexing (TDM). This work focuses on TDM technology. | |||
Bernstein/Mannie/Sharma Expires January 2005 4 | ||||
GMPLS based Control of SDH/SONET July 2004 | ||||
SDH and SONET are two TDM standards widely used by operators to | SDH and SONET are two TDM standards widely used by operators to | |||
transport and multiplex different tributary signals over optical | transport and multiplex different tributary signals over optical | |||
links, thus creating a multiplexing structure, which we call the | links, thus creating a multiplexing structure, which we call the | |||
SDH/SONET multiplex. | SDH/SONET multiplex. | |||
Internet Draft Expires March 2005 Page 4 | ||||
Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | ||||
ITU-T (G.707) [4] includes both the European ETSI SDH hierarchy and | ITU-T (G.707) [4] includes both the European ETSI SDH hierarchy and | |||
the USA ANSI SONET hierarchy [5]. The ETSI SDH and SONET standards | the USA ANSI SONET hierarchy [5]. The ETSI SDH and SONET standards | |||
regarding frame structures and higher-order multiplexing are the | regarding frame structures and higher-order multiplexing are the | |||
same. There are some regional differences in terminology, on the use | same. There are some regional differences in terminology, on the use | |||
of some overhead bytes, and lower-order multiplexing. Interworking | of some overhead bytes, and lower-order multiplexing. Interworking | |||
between the two lower-order hierarchies is possible using gateways. | between the two lower-order hierarchies is possible using gateways. | |||
The fundamental signal in SDH is the STM-1 that operates at a rate | 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- | 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 | 1 that operates at a rate of about 51 Mbps. These two signals are | |||
skipping to change at line 255 | skipping to change at line 253 | |||
The VC/SPE itself is made up of a header (the path overhead) and a | 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 | payload. This payload can be further subdivided into sub-elements | |||
(signals) in a fairly complex way. In the case of SDH, the STM-1 | (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 | 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 | 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 | pure tree, since it contains a node that can be attached to two | |||
parent nodes. The structure of the SDH/SONET multiplex is shown in | parent nodes. The structure of the SDH/SONET multiplex is shown in | |||
Figure 1. In addition, we show reference points in this figure that | Figure 1. In addition, we show reference points in this figure that | |||
are explained in later sections. | 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. | ||||
Internet Draft Expires March 2005 Page 5 | ||||
Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | ||||
xN x1 | xN x1 | |||
STM-N<----AUG<----AU-4<--VC4<------------------------------C-4 E4 | STM-N<----AUG<----AU-4<--VC4<------------------------------C-4 E4 | |||
^ ^ | ^ ^ | |||
Ix3 Ix3 | Ix3 Ix3 | |||
I I x1 | I I x1 | |||
I -----TUG-3<----TU-3<---VC-3<---I | I -----TUG-3<----TU-3<---VC-3<---I | |||
I ^ C-3 DS3/E3 | I ^ C-3 DS3/E3 | |||
Bernstein/Mannie/Sharma Expires January 2005 5 | ||||
GMPLS based Control of SDH/SONET July 2004 | ||||
STM-0<------------AU-3<---VC-3<-- I ---------------------I | STM-0<------------AU-3<---VC-3<-- I ---------------------I | |||
^ I | ^ I | |||
Ix7 Ix7 | Ix7 Ix7 | |||
I I x1 | I I x1 | |||
-----TUG-2<---TU-2<---VC-2<---C-2 DS2/T2 | -----TUG-2<---TU-2<---VC-2<---C-2 DS2/T2 | |||
^ ^ | ^ ^ | |||
I I x3 | I I x3 | |||
I I----TU-12<---VC-12<--C-12 E1 | I I----TU-12<---VC-12<--C-12 E1 | |||
I | I | |||
I x4 | I x4 | |||
skipping to change at line 297 | skipping to change at line 308 | |||
I I | I I | |||
I I x3 | I I x3 | |||
I I--------VT-2<----SPE E1 | I I--------VT-2<----SPE E1 | |||
I | I | |||
I x4 | I x4 | |||
I-----------VT-1.5<--SPE DS1/T1 | I-----------VT-1.5<--SPE DS1/T1 | |||
Figure 1. SDH and SONET multiplexing structure and typical PDH | Figure 1. SDH and SONET multiplexing structure and typical PDH | |||
payload signals. | payload signals. | |||
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 MPLS-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. | ||||
An STM-N/STS-N signal is formed from N x STM-1/STS-1 signals via | 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 | byte interleaving. The VCs/SPEs in the N interleaved frames are | |||
independent and float according to their own clocking. To transport | independent and float according to their own clocking. To transport | |||
tributary signals in excess of the basic STM-1/STS-1 signal rates, | tributary signals in excess of the basic STM-1/STS-1 signal rates, | |||
Bernstein/Mannie/Sharma Expires January 2005 6 | ||||
GMPLS based Control of SDH/SONET July 2004 | ||||
the VCs/SPEs can be concatenated, i.e., glued together. In this case | the VCs/SPEs can be concatenated, i.e., glued together. In this case | |||
their relationship with respect to each other is fixed in time and | their relationship with respect to each other is fixed in time and | |||
hence this relieves, when possible, an end system of any inverse | hence this relieves, when possible, an end system of any inverse | |||
multiplexing bonding processes. Different types of concatenations | multiplexing bonding processes. Different types of concatenations | |||
are defined in SDH/SONET. | are defined in SDH/SONET. | |||
Internet Draft Expires March 2005 Page 6 | ||||
Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | ||||
For example, standard SONET concatenation allows the concatenation | 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, | 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 | 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 | to form an STS-Mc. The STS-Mc notation is short hand for describing | |||
an STS-M signal whose SPEs have been concatenated. | an STS-M signal whose SPEs have been concatenated. | |||
2.3. The Current State of Circuit Establishment in SDH/SONET Networks | 1.3. The Current State of Circuit Establishment in SDH/SONET Networks | |||
In present day SDH and SONET networks, the networks are primarily | In present day SDH and SONET networks, the networks are primarily | |||
statically configured. When a client of an operator requests a | statically configured. When a client of an operator requests a | |||
point-to-point circuit, the request sets in motion a process that | 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 | can last for several weeks or more. This process is composed of a | |||
chain of shorter administrative and technical tasks, some of which | chain of shorter administrative and technical tasks, some of which | |||
can be fully automated, resulting in significant improvements in | can be fully automated, resulting in significant improvements in | |||
provisioning time and in operational savings. In the best case, the | provisioning time and in operational savings. In the best case, the | |||
entire process can be fully automated allowing, for example, | entire process can be fully automated allowing, for example, | |||
customer premise equipment (CPE) to contact a SDH/SONET switch to | customer premise equipment (CPE) to contact a SDH/SONET switch to | |||
request a circuit. Currently, the provisioning process involves the | request a circuit. Currently, the provisioning process involves the | |||
following tasks. | following tasks. | |||
2.3.1. Administrative Tasks | 1.3.1. Administrative Tasks | |||
The administrative tasks represent a significant part of the | The administrative tasks represent a significant part of the | |||
provisioning time. Most of them can be automated using IT | provisioning time. Most of them can be automated using IT | |||
applications, e.g., a client still has to fill a form to request a | 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 | circuit. This form can be filled via a Web-based application and can | |||
be automatically processed by the operator. A further enhancement is | be automatically processed by the operator. A further enhancement is | |||
to allow the client's equipment to coordinate with the operator's | to allow the client's equipment to coordinate with the operator's | |||
network directly and request the desired circuit. This could be | network directly and request the desired circuit. This could be | |||
achieved through a signaling protocol at the interface between the | achieved through a signaling protocol at the interface between the | |||
client equipment and an operator switch, i.e., at the UNI, where | client equipment and an operator switch, i.e., at the UNI, where | |||
GMPLS signaling [6], [7], [8] can be used. | GMPLS signaling [6], [7] can be used. | |||
2.3.2. Manual Operations | 1.3.2. Manual Operations | |||
Another significant part of the time may be consumed by manual | Another significant part of the time may be consumed by manual | |||
operations that involve installing the right interface in the CPE | operations that involve installing the right interface in the CPE | |||
and installing the right cable or fiber between the CPE and the | and installing the right cable or fiber between the CPE and the | |||
operator switch. This time can be especially significant when a | operator switch. This time can be especially significant when a | |||
client is in a different time zone than the operator's main office. | client is in a different time zone than the operator's main office. | |||
This first-time connection time is frequently accounted for in the | This first-time connection time is frequently accounted for in the | |||
overall establishment time. | overall establishment time. | |||
2.3.3. Planning Tool Operation | 1.3.3. Planning Tool Operation | |||
Bernstein/Mannie/Sharma Expires January 2005 7 | ||||
GMPLS based Control of SDH/SONET July 2004 | ||||
Another portion of the time is consumed by planning tools that run | Another portion of the time is consumed by planning tools that run | |||
simulations using heuristic algorithms to find an optimized | simulations using heuristic algorithms to find an optimized | |||
placement for the required circuits. These planning tools can | placement for the required circuits. These planning tools can | |||
require a significant running time, sometimes on the order of days. | require a significant running time, sometimes on the order of days. | |||
Internet Draft Expires March 2005 Page 7 | ||||
Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | ||||
These simulations are, in general, executed for a set of demands for | These simulations are, in general, executed for a set of demands for | |||
circuits, i.e., a batch mode, to improve the optimality of network | circuits, i.e., a batch mode, to improve the optimality of network | |||
resource usage and other parameters. Today, we do not really have a | resource usage and other parameters. Today, we do not really have a | |||
means to reduce this simulation time. On the contrary, to support | means to reduce this simulation time. On the contrary, to support | |||
fast, on-line, circuit establishment, this phase may be invoked more | fast, on-line, circuit establishment, this phase may be invoked more | |||
frequently, i.e., we will not "batch up" as many connection | frequently, i.e., we will not "batch up" as many connection | |||
requests before we plan out the corresponding circuits. This means | requests before we plan out the corresponding circuits. This means | |||
that the network may need to be re-optimized periodically, implying | that the network may need to be re-optimized periodically, implying | |||
that the signaling should support re-optimization with minimum | that the signaling should support re-optimization with minimum | |||
impact to existing services. | impact to existing services. | |||
2.3.4. Circuit Provisioning | 1.3.4. Circuit Provisioning | |||
Once the first three steps discussed above have been completed, the | Once the first three steps discussed above have been completed, the | |||
operator must provision the circuits using the outputs of the | operator must provision the circuits using the outputs of the | |||
planning process. The time required for provisioning varies greatly. | planning process. The time required for provisioning varies greatly. | |||
It can be fairly short, on the order of a few minutes, if the | 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 | operators already have tools that help them to do the provisioning | |||
over heterogeneous equipment. Otherwise, the process can take days. | over heterogeneous equipment. Otherwise, the process can take days. | |||
Developing these tools for each new piece of equipment and each | Developing these tools for each new piece of equipment and each | |||
vendor is a significant burden on the service provider. A | vendor is a significant burden on the service provider. A | |||
standardized interface for provisioning, such as GMPLS signaling, | standardized interface for provisioning, such as GMPLS signaling, | |||
skipping to change at line 415 | skipping to change at line 413 | |||
When a circuit is provisioned, it is not delivered directly to a | When a circuit is provisioned, it is not delivered directly to a | |||
client. Rather, the operator first tests its performance and | client. Rather, the operator first tests its performance and | |||
behavior and if successful, delivers the circuit to the client. This | behavior and if successful, delivers the circuit to the client. This | |||
testing phase lasts, in general, for up to 24 hours. The operator | testing phase lasts, in general, for up to 24 hours. The operator | |||
installs test equipment at each end and uses pre-defined test | installs test equipment at each end and uses pre-defined test | |||
streams to verify performance. If successful, the circuit is | streams to verify performance. If successful, the circuit is | |||
officially accepted by the client. To speed up the verification | officially accepted by the client. To speed up the verification | |||
(sometimes known as "proving") process, it would be necessary to | (sometimes known as "proving") process, it would be necessary to | |||
support some form of automated performance testing. | support some form of automated performance testing. | |||
2.4. Centralized Approach versus Distributed Approach | 1.4. Centralized Approach versus Distributed Approach | |||
Whether a centralized approach or a distributed approach will be | Whether a centralized approach or a distributed approach will be | |||
used to control SDH/SONET networks is an open question, since each | used to control SDH/SONET networks is an open question, since each | |||
approach has its merits. The application of MPLS to SDH/SONET | approach has its merits. The application of GMPLS to SDH/SONET | |||
networks does not preclude either model, although MPLS is itself a | networks does not preclude either model, although GMPLS is itself a | |||
distributed technology. | distributed technology. | |||
The basic tradeoff between the centralized and distributed | The basic tradeoff between the centralized and distributed | |||
approaches is that of complexity of the network elements versus that | approaches is that of complexity of the network elements versus that | |||
of the network management system (NMS). Since adding functionality | of the network management system (NMS). Since adding functionality | |||
Bernstein/Mannie/Sharma Expires January 2005 8 | ||||
GMPLS based Control of SDH/SONET July 2004 | ||||
to existing SDH/SONET network elements may not be possible, a | to existing SDH/SONET network elements may not be possible, a | |||
centralized approach may be needed in some cases. The main issue | centralized approach may be needed in some cases. The main issue | |||
facing centralized control via an NMS is one of scalability. For | facing centralized control via an NMS is one of scalability. For | |||
Internet Draft Expires March 2005 Page 8 | ||||
Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | ||||
instance, this approach may be limited in the number of network | instance, this approach may be limited in the number of network | |||
elements that can be managed (e.g., one thousand). It is, therefore, | elements that can be managed (e.g., one thousand). It is, therefore, | |||
quite common for operators to deploy several NMSÆs in parallel at | quite common for operators to deploy several NMS in parallel at | |||
the Network Management Layer, each managing a different zone. In | the Network Management Layer, each managing a different zone. In | |||
that case, however, a Service Management Layer must be built on the | that case, however, a Service Management Layer must be built on the | |||
top of several individual NMSÆs to take care of end-to-end on-demand | 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, | services. On the other hand, in a complex and/or dense network, | |||
restoration could be faster with a distributed approach than with a | restoration could be faster with a distributed approach than with a | |||
centralized approach. | centralized approach. | |||
Let's now look at how the major control plane functional components | Let's now look at how the major control plane functional components | |||
are handled via the centralized and distributed approaches: | are handled via the centralized and distributed approaches: | |||
2.4.1. Topology Discovery and Resource Dissemination | 1.4.1. Topology Discovery and Resource Dissemination | |||
Currently NMS's maintain a consistent view of all the networking | Currently an NMS maintains a consistent view of all the networking | |||
layers under their purview. This can include the physical topology, | layers under its purview. This can include the physical topology, | |||
such as information about fibers and ducts. Since most of this | such as information about fibers and ducts. Since most of this | |||
information is entered manually, it remains error prone. | information is entered manually, it remains error prone. | |||
A link state GMPLS routing protocol, on the other hand, could | A link state GMPLS routing protocol, on the other hand, could | |||
perform automatic topology discovery and dissemination the topology | perform automatic topology discovery and dissemination the topology | |||
as well as resource status. This information would be available to | as well as resource status. This information would be available to | |||
all nodes in the network, and hence also the NMS. Hence one can | all nodes in the network, and hence also the NMS. Hence one can | |||
look at a continuum of functionality between manually provisioned | look at a continuum of functionality between manually provisioned | |||
topology information (of which there will always be some) and fully | topology information (of which there will always be some) and fully | |||
automated discovery and dissemination as in a link state protocol. | automated discovery and dissemination as in a link state protocol. | |||
Note that, unlike the IP datagram case, a link state routing | Note that, unlike the IP datagram case, a link state routing | |||
protocol applied to the SDH/SONET network does not have any service | protocol applied to the SDH/SONET network does not have any service | |||
impacting implications. This is because in the SDH/SONET case, the | impacting implications. This is because in the SDH/SONET case, the | |||
circuit is source-routed (so there can be no loops), and no traffic | circuit is source-routed (so there can be no loops), and no traffic | |||
is transmitted until a circuit has been established, and an | is transmitted until a circuit has been established, and an | |||
acknowledgement received at the source. | acknowledgement received at the source. | |||
2.4.2. Path Computation (Route Determination) | 1.4.2. Path Computation (Route Determination) | |||
In the SDH/SONET case, unlike the IP datagram case, there is no need | In the SDH/SONET case, unlike the IP datagram case, there is no need | |||
for network elements to all perform the same path calculation [9]. | for network elements to all perform the same path calculation [9]. | |||
In addition, path determination is an area for vendors to provide a | In addition, path determination is an area for vendors to provide a | |||
potentially significant value addition in terms of network | potentially significant value addition in terms of network | |||
efficiency, reliability, and service differentiation. In this sense, | efficiency, reliability, and service differentiation. In this sense, | |||
a centralized approach to path computation may be easier to operate | a centralized approach to path computation may be easier to operate | |||
and upgrade. For example, new features such as new types of path | and upgrade. For example, new features such as new types of path | |||
diversity or new optimization algorithms can be introduced with a | diversity or new optimization algorithms can be introduced with a | |||
simple NMS software upgrade. On the other hand, updating switches | simple NMS software upgrade. On the other hand, updating switches | |||
with new path computation software is a more complicated task. In | with new path computation software is a more complicated task. In | |||
addition, many of the algorithms can be fairly computationally | addition, many of the algorithms can be fairly computationally | |||
intensive and may be completely unsuitable for the embedded | intensive and may be completely unsuitable for the embedded | |||
processing environment available on most switches. In restoration | processing environment available on most switches. In restoration | |||
Bernstein/Mannie/Sharma Expires January 2005 9 | ||||
GMPLS based Control of SDH/SONET July 2004 | ||||
scenarios, the ability to perform a reasonably sophisticated level | scenarios, the ability to perform a reasonably sophisticated level | |||
of path computation on the network element can be particularly | of path computation on the network element can be particularly | |||
useful for restoring traffic during major network faults. | useful for restoring traffic during major network faults. | |||
2.4.3. Connection Establishment (Provisioning) | Internet Draft Expires March 2005 Page 9 | |||
Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | ||||
1.4.3. Connection Establishment (Provisioning) | ||||
The actual setting up of circuits, i.e., a coupled collection of | The actual setting up of circuits, i.e., a coupled collection of | |||
cross connects across a network, can be done either via the NMS | cross connects across a network, can be done either via the NMS | |||
setting up individual cross connects or via a "soft permanent LSP" | setting up individual cross connects or via a "soft permanent LSP" | |||
(SPLSP) type approach. In the SPLSP approach, the NMS may just kick | (SPLSP) type approach. In the SPLSP approach, the NMS may just kick | |||
off the connection at the "ingress" switch with GMPLS signaling | off the connection at the "ingress" switch with GMPLS signaling | |||
setting up the connection from that point onward. Connection | setting up the connection from that point onward. Connection | |||
establishment is the trickiest part to distribute, however, since | establishment is the trickiest part to distribute, however, since | |||
errors in the connection setup/tear down process are service | errors in the connection setup/tear down process are service | |||
impacting. | impacting. | |||
The table below compares the two approaches to connection | The table below compares the two approaches to connection | |||
establishment. | establishment. | |||
Distributed approach Centralized approach | Distributed approach Centralized approach | |||
Packet-based control plane Management plane like TMN or | Packet-based control plane Management plane like TMN or | |||
(like MPLS or PNNI) useful? SNMP | (like GMPLS or PNNI) useful? SNMP | |||
Do we really need it? Being Always needed! Already there, | Do we really need it? Being Always needed! Already there, | |||
added/specified by several proven and understood. | added/specified by several proven and understood. | |||
standardization bodies | standardization bodies | |||
High survivability (e.g. in Potential single point(s) of | High survivability (e.g. in Potential single point(s) of | |||
case of partition) failure | case of partition) failure | |||
Distributed load Bottleneck: #requests and | Distributed load Bottleneck: #requests and | |||
actions to/from NMS | actions to/from NMS | |||
skipping to change at line 539 | skipping to change at line 536 | |||
protocol (traffic | protocol (traffic | |||
engineering) | engineering) | |||
Ideal for inter-domain Not inter-domain friendly | Ideal for inter-domain Not inter-domain friendly | |||
Suitable for very dynamic For less dynamic demands | Suitable for very dynamic For less dynamic demands | |||
demands (longer lived) | demands (longer lived) | |||
Probably faster to restore, Probably slower to restore,but | Probably faster to restore, Probably slower to restore,but | |||
Bernstein/Mannie/Sharma Expires January 2005 10 | ||||
GMPLS based Control of SDH/SONET July 2004 | ||||
but more difficult to have could effect reliable | but more difficult to have could effect reliable | |||
reliable restoration. restoration. | reliable restoration. restoration. | |||
Internet Draft Expires March 2005 Page 10 | ||||
Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | ||||
High scalability Limited scalability: #nodes, | High scalability Limited scalability: #nodes, | |||
(hierarchical) links, circuits, messages | (hierarchical) links, circuits, messages | |||
Planning (optimization) Planning is a background | Planning (optimization) Planning is a background | |||
harder to achieve centralized activity | harder to achieve centralized activity | |||
Easier future integration | Easier future integration | |||
with other control plane | with other control plane | |||
layers | layers | |||
Table 1. Qualitative comparison between centralized and distributed | Table 1. Qualitative comparison between centralized and distributed | |||
approaches. | approaches. | |||
2.5. Why SDH/SONET will not Disappear Tomorrow | 1.5. Why SDH/SONET will not Disappear Tomorrow | |||
As IP traffic becomes the dominant traffic transported over the | As IP traffic becomes the dominant traffic transported over the | |||
transport infrastructure, it is useful to compare the statistical | transport infrastructure, it is useful to compare the statistical | |||
multiplexing of IP with the time division multiplexing of SDH and | multiplexing of IP with the time division multiplexing of SDH and | |||
SONET. | SONET. | |||
Consider, for instance, a scenario where IP over WDM is used | Consider, for instance, a scenario where IP over WDM is used | |||
everywhere and lambdas are optically switched. In such a case, a | everywhere and lambdas are optically switched. In such a case, a | |||
carrier's carrier would sell dynamically controlled lambdas with | carrier's carrier would sell dynamically controlled lambdas with | |||
each customers building their own IP backbones over these lambdas. | each customers building their own IP backbones over these lambdas. | |||
This simple model implies that a carrier would sell lambdas instead | This simple model implies that a carrier would sell lambdas instead | |||
of bandwidth. The carrierÆs goal will be to maximize the number of | of bandwidth. The carrier's goal will be to maximize the number of | |||
wavelengths/lambdas per fiber, with each customer having to fully | wavelengths/lambdas per fiber, with each customer having to fully | |||
support the cost for each end-to-end lambda whether or not the | support the cost for each end-to-end lambda whether or not the | |||
wavelength is fully utilized. Although, in the near future, we may | wavelength is fully utilized. Although, in the near future, we may | |||
have technology to support up to several hundred lambdas per fiber, | have technology to support up to several hundred lambdas per fiber, | |||
a world where lambdas are so cheap and abundant that every | a world where lambdas are so cheap and abundant that every | |||
individual customer buys them, from one point to any other point, | individual customer buys them, from one point to any other point, | |||
appears an unlikely scenario today. | appears an unlikely scenario today. | |||
More realistically, there is still room for a multiplexing | More realistically, there is still room for a multiplexing | |||
technology that provides circuits with a lower granularity than a | technology that provides circuits with a lower granularity than a | |||
skipping to change at line 594 | skipping to change at line 592 | |||
SDH and SONET possess a rich multiplexing hierarchy that permits | SDH and SONET possess a rich multiplexing hierarchy that permits | |||
fairly fine granularity and that provides a very cheap and simple | fairly fine granularity and that provides a very cheap and simple | |||
physical separation of the transported traffic between circuits, | physical separation of the transported traffic between circuits, | |||
i.e., QoS. Moreover, even IP datagrams cannot be transported | i.e., QoS. Moreover, even IP datagrams cannot be transported | |||
directly over a wavelength. A framing or encapsulation is always | directly over a wavelength. A framing or encapsulation is always | |||
required to delimit IP datagrams. The Total Length field of an IP | 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 | 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. | it could be corrupted and would result in a loss of synchronization. | |||
The typical framing used today for IP over DWDM is defined in | The typical framing used today for IP over DWDM is defined in | |||
Bernstein/Mannie/Sharma Expires January 2005 11 | ||||
GMPLS based Control of SDH/SONET July 2004 | ||||
RFC1619/RFC2615 and known as POS (Packet Over SDH/SONET), i.e., IP | RFC1619/RFC2615 and known as POS (Packet Over SDH/SONET), i.e., IP | |||
over PPP (in HDLC-like format) over SDH/SONET. SDH and SONET are | over PPP (in HDLC-like format) over SDH/SONET. SDH and SONET are | |||
Internet Draft Expires March 2005 Page 11 | ||||
Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | ||||
actually efficient encapsulations for IP. For instance, with an | actually efficient encapsulations for IP. For instance, with an | |||
average IP datagram length of 350 octets, an IP over GBE | average IP datagram length of 350 octets, an IP over GBE | |||
encapsulation using an 8B/10B encoding results in 28% overhead, an | encapsulation using an 8B/10B encoding results in 28% overhead, an | |||
IP/ATM/SDH encapsulation results in 22% overhead and an IP/PPP/SDH | IP/ATM/SDH encapsulation results in 22% overhead and an IP/PPP/SDH | |||
encapsulation results in only 6% overhead. | encapsulation results in only 6% overhead. | |||
Any encapsulation of IP over WDM should, in the data plane, at least | Any encapsulation of IP over WDM should, in the data plane, at least | |||
provide error monitoring capabilities (to detect signal | provide error monitoring capabilities (to detect signal | |||
degradation); error correction capabilities, such as FEC (Forward | degradation); error correction capabilities, such as FEC (Forward | |||
Error Correction) that are particularly needed for ultra long haul | Error Correction) that are particularly needed for ultra long haul | |||
skipping to change at line 630 | skipping to change at line 628 | |||
associated signaling, as would happen with an out-of-band control | associated signaling, as would happen with an out-of-band control | |||
plane network is another equally valid option.) | plane network is another equally valid option.) | |||
Since IP encapsulated in SDH/SONET is efficient and widely used, the | 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 | 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 | 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 | 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 and optical layers. In the second case, it can take place at | |||
the IP, SDH/SONET, and optical layers. | the IP, SDH/SONET, and optical layers. | |||
Almost all transmission networks today are based on SDH or SONET. A | Almost all transmission networks today are based on SDH or SONET. | |||
client is connected either directly through an SDH or SONET | A client is connected either directly through an SDH or SONET | |||
interface or through a PDH interface, the PDH signal being | interface or through a PDH interface, the PDH signal being | |||
transported between the ingress and the egress interfaces over SDH | transported between the ingress and the egress interfaces over SDH | |||
or SONET. What we are arguing here is that it makes sense to do | or SONET. What we are arguing here is that it makes sense to do | |||
switching or forwarding at all these layers. | switching or forwarding at all these layers. | |||
3. GMPLS Applied to SDH/SONET | 2. GMPLS Applied to SDH/SONET | |||
3.1. Controlling the SDH/SONET Multiplex | 2.1. Controlling the SDH/SONET Multiplex | |||
Controlling the SDH/SONET multiplex implies deciding which of the | Controlling the SDH/SONET multiplex implies deciding which of the | |||
different switchable components of the SDH/SONET multiplex do we | different switchable components of the SDH/SONET multiplex do we | |||
wish to control using GMPLS. Essentially, every SDH/SONET element | wish to control using GMPLS. Essentially, every SDH/SONET element | |||
that is referenced by a pointer can be switched. These component | 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; | 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 | and the VT and STS SPEs in the SONET case. The SPEs in SONET do not | |||
have individual names, although they can be referred to simply as | have individual names, although they can be referred to simply as | |||
VT-N SPEs. We will refer to them by identifying the structure that | 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. | contains them, namely STS-1, VT-6, VT-3, VT-2 and VT-1.5. | |||
Bernstein/Mannie/Sharma Expires January 2005 12 | Internet Draft Expires March 2005 Page 12 | |||
GMPLS based Control of SDH/SONET July 2004 | Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | |||
The STS-1 SPE corresponds to a VC-3, a VT-6 SPE corresponds to a VC- | 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 | 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 | 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. | SDH's VC-4 corresponds to SONET's STS-3c SPE. | |||
In addition, it is possible to concatenate some of the structures | In addition, it is possible to concatenate some of the structures | |||
that contain these elements to build larger elements. For instance, | that contain these elements to build larger elements. For instance, | |||
SDH allows the concatenation of X contiguous AU-4s to build a VC-4- | 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- | 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. Note that | 4-Xc or a VC-2-mc can be switched and controlled by GMPLS. SDH also | |||
SDH also defines virtual (non-contiguous) concatenation of TU- 2s, | defines virtual (non-contiguous) concatenation of TU- 2s, however | |||
but in that case each constituent VC-2 is switched individually. | in that case each constituent VC-2 is switched individually. | |||
3.2. SDH/SONET LSR and LSP Terminology | 2.2. SDH/SONET LSR and LSP Terminology | |||
Let a SDH or SONET Terminal Multiplexer (TM), Add-Drop Multiplexer | Let a SDH or SONET Terminal Multiplexer (TM), Add-Drop Multiplexer | |||
(ADM) or cross-connect (i.e. a switch) be called an SDH/SONET LSR. A | (ADM) or cross-connect (i.e. a switch) be called an SDH/SONET LSR. A | |||
SDH/SONET path or circuit between two SDH/SONET LSRs now becomes a | 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 | GMPLS LSP. An SDH/SONET LSP is a logical connection between the | |||
point at which a tributary signal (client layer) is adapted into its | 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, and the point at which it is extracted from its | |||
virtual container. | virtual container. | |||
To establish such an LSP, a signaling protocol is required to | To establish such an LSP, a signaling protocol is required to | |||
skipping to change at line 691 | skipping to change at line 689 | |||
no merging is possible with SDH/SONET signals. | no merging is possible with SDH/SONET signals. | |||
To facilitate the signaling and setup of SDH/SONET circuits, an | To facilitate the signaling and setup of SDH/SONET circuits, an | |||
SDH/SONET LSR must, therefore, identify each possible signal | SDH/SONET LSR must, therefore, identify each possible signal | |||
individually per interface, since each signal corresponds to a | individually per interface, since each signal corresponds to a | |||
potential LSP that can be established through the SDH/SONET LSR. It | potential LSP that can be established through the SDH/SONET LSR. It | |||
turns out, however, that not all SDH signals correspond to an LSP | turns out, however, that not all SDH signals correspond to an LSP | |||
and therefore not all of them need be identified. In fact, only | and therefore not all of them need be identified. In fact, only | |||
those signals that can be switched need identification. | those signals that can be switched need identification. | |||
4. Decomposition of the MPLS Circuit-Switching Problem Space | 3. Decomposition of the GMPLS Circuit-Switching Problem Space | |||
Although those familiar with MPLS may be familiar with its | Although those familiar with GMPLS may be familiar with its | |||
application in a variety of application areas, e.g., ATM, Frame | application in a variety of application areas, e.g., ATM, Frame | |||
Relay, and so on, here we quickly review its decomposition when | Relay, and so on, here we quickly review its decomposition when | |||
applied to the optical switching problem space. | applied to the optical switching problem space. | |||
(i) Information needed to compute paths must be made globally | (i) Information needed to compute paths must be made globally | |||
available throughout the network. Since this is done via the link | available throughout the network. Since this is done via the link | |||
state routing protocol, any information of this nature must either | state routing protocol, any information of this nature must either | |||
be in the existing link state advertisements (LSAs) or the LSAs must | be in the existing link state advertisements (LSAs) or the LSAs must | |||
be supplemented to convey this information. For example, if it is | be supplemented to convey this information. For example, if it is | |||
desirable to offer different levels of service in a network based on | desirable to offer different levels of service in a network based on | |||
whether a circuit is routed over SDH/SONET lines that are ring | whether a circuit is routed over SDH/SONET lines that are ring | |||
protected versus being routed over those that are not ring protected | protected versus being routed over those that are not ring protected | |||
Bernstein/Mannie/Sharma Expires January 2005 13 | Internet Draft Expires March 2005 Page 13 | |||
GMPLS based Control of SDH/SONET July 2004 | Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | |||
(differentiation based on reliability), the type of protection on a | (differentiation based on reliability), the type of protection on a | |||
SDH/SONET line would be an important topological parameter that | SDH/SONET line would be an important topological parameter that | |||
would have to be distributed via the link state routing protocol. | would have to be distributed via the link state routing protocol. | |||
(ii) Information that is only needed between two "adjacent" switches | (ii) Information that is only needed between two "adjacent" switches | |||
for the purposes of connection establishment is appropriate for | for the purposes of connection establishment is appropriate for | |||
distribution via one of the label distribution protocols. In fact, | distribution via one of the label distribution protocols. In fact, | |||
this information can be thought of as the "virtual" label. For | this information can be thought of as the "virtual" label. For | |||
example, in SONET networks, when distributing information to | example, in SONET networks, when distributing information to | |||
skipping to change at line 736 | skipping to change at line 734 | |||
identifies the signal locally on the link between the two switches. | identifies the signal locally on the link between the two switches. | |||
(iii) Information that all switches in the path need to know about a | (iii) Information that all switches in the path need to know about a | |||
circuit will also be distributed via the label distribution | circuit will also be distributed via the label distribution | |||
protocol. Examples of such information include bandwidth, priority, | protocol. Examples of such information include bandwidth, priority, | |||
and preemption for instance. | and preemption for instance. | |||
(iv) Information intended only for end systems of the connection. | (iv) Information intended only for end systems of the connection. | |||
Some of the payload type information in may fall into this category. | Some of the payload type information in may fall into this category. | |||
5. GMPLS Routing for SDH/SONET | 4. GMPLS Routing for SDH/SONET | |||
Modern transport networks based on SDH/SONET excel at | Modern SDH/SONET transport networks excel at interoperability in the | |||
interoperability in the performance monitoring (PM) and fault | performance monitoring (PM) and fault management (FM) areas [10], | |||
management (FM) areas [10], [11]. They do not, however, inter- | [11]. They do not, however, interoperate in the areas of topology | |||
operate in the areas of topology discovery or resource status. | discovery or resource status. Although link state routing protocols, | |||
Although link state routing protocols, such as IS-IS and OSPF, have | such as IS-IS and OSPF, have been used for some time in the IP world | |||
been used for some time in the IP world to compute destination-based | to compute destination-based next hops for routes (without routing | |||
next hops for routes (without routing loops), they are particularly | loops), they are particularly valuable for providing timely topology | |||
valuable for providing timely topology and network status | and network status information in a distributed manner, i.e., at any | |||
information in a distributed manner, i.e., at any network node. If | network node. If resource utilization information is disseminated | |||
resource utilization information is disseminated along with the link | along with the link status (as done in ATM's PNNI routing protocol) | |||
status (as was done in ATM's PNNI routing protocol) then a very | then a very complete picture of network status is available to a | |||
complete picture of network status is available to a network | network operator for use in planning, provisioning and operations. | |||
operator for use in planning, provisioning and operations. | ||||
The information needed to compute the path a connection will take | The information needed to compute the path a connection will take | |||
through a network is important to distribute via the routing | through a network is important to distribute via the routing | |||
protocol. In the TDM case, this information includes, but is not | protocol. In the TDM case, this information includes, but is not | |||
limited to: the available capacity of the network links, the | limited to: the available capacity of the network links, the | |||
switching and termination capabilities of the nodes and interfaces, | switching and termination capabilities of the nodes and interfaces, | |||
and the protection properties of the link. This is what is being | and the protection properties of the link. This is what is being | |||
proposed in the GMPLS extensions to IP routing protocols | proposed in the GMPLS extensions to IP routing protocols [12], [13], | |||
[12],[13],[14]. | [14]. | |||
When applying routing to circuit switched networks it is useful to | When applying routing to circuit switched networks it is useful to | |||
compare and contrast this situation with the datagram routing case | compare and contrast this situation with the datagram routing case | |||
Bernstein/Mannie/Sharma Expires January 2005 14 | Internet Draft Expires March 2005 Page 14 | |||
GMPLS based Control of SDH/SONET July 2004 | Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | |||
[15]. In the case of routing datagrams, all routes on all nodes | [15]. In the case of routing datagrams, all routes on all nodes | |||
must be calculated exactly the same to avoid loops and "black | must be calculated exactly the same to avoid loops and "black | |||
holes". In circuit switching, this is not the case since routes are | holes". In circuit switching, this is not the case since routes are | |||
established per circuit and are fixed for that circuit. Hence, | established per circuit and are fixed for that circuit. Hence, | |||
unlike the datagram case, routing is not service impacting in the | unlike the datagram case, routing is not service impacting in the | |||
circuit switched case. This is helpful, because, to accommodate the | circuit switched case. This is helpful, because, to accommodate the | |||
optical layer, routing protocols need to be supplemented with new | optical layer, routing protocols need to be supplemented with new | |||
information, much more than the datagram case. This information is | information, much more than the datagram case. This information is | |||
also likely to be used in different ways for implementing different | also likely to be used in different ways for implementing different | |||
skipping to change at line 791 | skipping to change at line 788 | |||
Indeed, from the carriers' perspective, the up-to-date dissemination | Indeed, from the carriers' perspective, the up-to-date dissemination | |||
of all link properties is essential and desired, and the use of a | of all link properties is essential and desired, and the use of a | |||
link-state routing protocol to distribute this information provides | link-state routing protocol to distribute this information provides | |||
timely and efficient delivery. If GMPLS-based networks got to the | timely and efficient delivery. If GMPLS-based networks got to the | |||
point that bandwidth updates happen very frequently, it makes sense, | point that bandwidth updates happen very frequently, it makes sense, | |||
from an efficiency point of view, to separate them out for update. | from an efficiency point of view, to separate them out for update. | |||
This situation is not yet seen in actual networks; however, if GMPLS | This situation is not yet seen in actual networks; however, if GMPLS | |||
signaling is put into widespread use then the need could arise. | signaling is put into widespread use then the need could arise. | |||
5.1. Switching Capabilities | 4.1. Switching Capabilities | |||
The main switching capabilities that characterize a SDH/SONET end | The main switching capabilities that characterize a SDH/SONET end | |||
system and thus need to be advertised via the link state routing | system and thus need to be advertised via the link state routing | |||
protocol are: the switching granularity, supported forms of | protocol are: the switching granularity, supported forms of | |||
concatenation, and the level of transparency. | concatenation, and the level of transparency. | |||
5.1.1. Switching Granularity | 4.1.1. Switching Granularity | |||
From references [4],[5] and the overview section on SDH/SONET we see | From references [4], [5] and the overview section on SDH/SONET we | |||
that there are a number of different signals that compose the | see that there are a number of different signals that compose the | |||
SDH/SONET hierarchies. Those signals that are referenced via a | SDH/SONET hierarchies. Those signals that are referenced via a | |||
pointer, i.e., the VCs in SDH and the SPEs in SONET are those that | pointer, i.e., the VCs in SDH and the SPEs in SONET are those that | |||
will actually be switched within a SDH/SONET network. These signals | will actually be switched within a SDH/SONET network. These signals | |||
are subdivided into lower order signals and higher order signals as | are subdivided into lower order signals and higher order signals as | |||
shown in Table 2. | shown in Table 2. | |||
Table 2. SDH/SONET switched signal groupings. | Table 2. SDH/SONET switched signal groupings. | |||
Signal Type SDH SONET | Signal Type SDH SONET | |||
Lower Order VC-11, VC-12, VC-2 VT-1.5 SPE, VT-2 SPE, | Lower Order VC-11, VC-12, VC-2 VT-1.5 SPE, VT-2 SPE, | |||
VT-3 SPE, VT-6 SPE | VT-3 SPE, VT-6 SPE | |||
Higher VC-3, VC-4 STS-1 SPE, STS-3c SPE | Higher VC-3, VC-4 STS-1 SPE, STS-3c SPE | |||
Order | Order | |||
Bernstein/Mannie/Sharma Expires January 2005 15 | Internet Draft Expires March 2005 Page 15 | |||
GMPLS based Control of SDH/SONET July 2004 | Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | |||
Manufacturers today differ in the types of switching capabilities | Manufacturers today differ in the types of switching capabilities | |||
their systems support. Many manufacturers today switch signals | their systems support. Many manufacturers today switch signals | |||
starting at VC-4 for SDH or STS-1 for SONET (i.e. the basic frame) | starting at VC-4 for SDH or STS-1 for SONET (i.e. the basic frame) | |||
and above (see Section 5.1.2 on concatenation), but they do not | 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 | switch lower order signals. Some of them only allow the switching of | |||
entire aggregates (concatenated or not) of signals such as 16 VC-4s, | 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 | 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 | 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 | 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 | VC-12s. In order to cover the needs of all manufacturers and | |||
operators, GMPLS signaling [6],[7],[8] covers both higher order and | operators, GMPLS signaling ([6], [7]) covers both higher order and | |||
lower order signals. | lower order signals. | |||
5.1.2. Signal Concatenation Capabilities | 4.1.2. Signal Concatenation Capabilities | |||
As stated in the SDH/SONET overview, to transport tributary signals | 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 | 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 | can be concatenated, i.e., glued together. Different types of | |||
concatenations are defined: contiguous standard concatenation, | concatenations are defined: contiguous standard concatenation, | |||
arbitrary concatenation, and virtual concatenation with different | arbitrary concatenation, and virtual concatenation with different | |||
rules concerning their size, placement, and binding. | rules concerning their size, placement, and binding. | |||
Standard SONET concatenation allows the concatenation of M x STS-1 | 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, | signals within an STS-N signal with M <= N, and M = 3, 12, 48, 192, | |||
skipping to change at line 873 | skipping to change at line 870 | |||
(where the rest of the signal gets put in terms of STS-1 slot | (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 | numbers) leads to the requirement for re-grooming (due to bandwidth | |||
fragmentation). | fragmentation). | |||
Due to these disadvantages some SONET framer manufacturers now | Due to these disadvantages some SONET framer manufacturers now | |||
support "flexible" or arbitrary concatenation, i.e., no restrictions | support "flexible" or arbitrary concatenation, i.e., no restrictions | |||
on the size of an STS-Mc (as long as M <= N) and no constraints on | 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 | the STS-1 timeslots used to convey it, i.e., the signals can use any | |||
combination of available time slots. | combination of available time slots. | |||
Bernstein/Mannie/Sharma Expires January 2005 16 | Internet Draft Expires March 2005 Page 16 | |||
GMPLS based Control of SDH/SONET July 2004 | Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | |||
Standard and flexible concatenations are network services, while | Standard and flexible concatenations are network services, while | |||
virtual concatenation is a SDH/SONET end-system service approved by | virtual concatenation is a SDH/SONET end-system service approved by | |||
the Committee T1 of ANSI [5] and the ITU-T [4]. The essence of this | the Committee T1 of ANSI [5] and the ITU-T [4]. The essence of this | |||
service is to have SDH/SONET end systems "glue" together the VCs or | service is to have SDH/SONET end systems "glue" together the VCs or | |||
SPEs of separate signals rather than requiring that he signals be | SPEs of separate signals rather than requiring that the signals be | |||
carried through the network as a single unit. In one example of | carried through the network as a single unit. In one example of | |||
virtual concatenation, two end systems supporting this feature could | virtual concatenation, two end systems supporting this feature could | |||
essentially "inverse multiplex" two STS-1s into a STS-1-2v for the | essentially "inverse multiplex" two STS-1s into a STS-1-2v for the | |||
efficient transport of 100 Mbps Ethernet traffic. Note that this | efficient transport of 100 Mbps Ethernet traffic. Note that this | |||
inverse multiplexing process (or virtual concatenation) can be | inverse multiplexing process (or virtual concatenation) can be | |||
significantly easier to implement with SDH/SONET signals rather than | significantly easier to implement with SDH/SONET than packet switched | |||
packets, because timing and in-order delivery of frames is more | circuits, because ensuring that timing and in-order frame delivery is | |||
easily ensured with SDH/SONET signals than it is with packets, where | preserved may be simpler to establish using SDH/SONET rather than | |||
more sophisticated techniques are needed. | packet switched circuits, where more sophisticated techniques may be | |||
needed. | ||||
Since virtual concatenation is provided by end systems, it is | Since virtual concatenation is provided by end systems, it is | |||
compatible with existing SDH/SONET networks. Virtual concatenation | compatible with existing SDH/SONET networks. Virtual concatenation | |||
is defined for both higher order signals and low order signals. | is defined for both higher order signals and low order signals. | |||
Table 3 shows the nomenclature and capacity for several lower-order | Table 3 shows the nomenclature and capacity for several lower-order | |||
virtually concatenated signals contained within different higher- | virtually concatenated signals contained within different higher- | |||
order signals. | order signals. | |||
Table 3 Capacity of Virtually Concatenated VTn-Xv (9/G.707) | Table 3 Capacity of Virtually Concatenated VTn-Xv (9/G.707) | |||
skipping to change at line 915 | skipping to change at line 913 | |||
VT2/ STS-1/VC-3 1 to 21 2176kbit/s to 2176kbit/s | VT2/ STS-1/VC-3 1 to 21 2176kbit/s to 2176kbit/s | |||
VC-12-Xv 45696kbit/s | VC-12-Xv 45696kbit/s | |||
VT1.5/ STS-3c/VC-4 1 to 64 1600kbit/s to 1600kbit/s | VT1.5/ STS-3c/VC-4 1 to 64 1600kbit/s to 1600kbit/s | |||
VC-11-Xv 102400kbit/s | VC-11-Xv 102400kbit/s | |||
VT2/ STS-3c/VC-4 1 to 63 2176kbit/s to 2176kbit/s | VT2/ STS-3c/VC-4 1 to 63 2176kbit/s to 2176kbit/s | |||
VC-12-Xv 137088kbit/s | VC-12-Xv 137088kbit/s | |||
5.1.3. SDH/SONET Transparency | 4.1.3. SDH/SONET Transparency | |||
The purposed of SDH/SONET is to carry its payload signals in a | The purposed of SDH/SONET is to carry its payload signals in a | |||
transparent manner. This can include some of the layers of SONET | transparent manner. This can include some of the layers of SONET | |||
itself. For example, situations where the path overhead can never be | itself. For example, situations where the path overhead can never be | |||
touched, since it actually belongs to the client. This was another | touched, since it actually belongs to the client. This was another | |||
reason for not coding an explicit label in the SDH/SONET path | reason for not coding an explicit label in the SDH/SONET path | |||
overhead. It may be useful to transport, multiplex and/or switch | overhead. It may be useful to transport, multiplex and/or switch | |||
lower layers of the SONET signal transparently. | lower layers of the SONET signal transparently. | |||
As mentioned in the introduction, SONET overhead is broken into | 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 | ||||
Bernstein/Mannie/Sharma Expires January 2005 17 | Internet Draft Expires March 2005 Page 17 | |||
GMPLS based Control of SDH/SONET July 2004 | Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | |||
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 framing, while the Line | |||
overhead is primarily concerned with multiplexing and protection. To | overhead is primarily concerned with multiplexing and protection. To | |||
perform pipe multiplexing (that is, multiplexing of 50 Mbps or 150 | perform pipe multiplexing (that is, multiplexing of 50 Mbps or 150 | |||
Mbps chunks), a SONET network element should be line terminating. | Mbps chunks), a SONET network element should be line terminating. | |||
However, not all SONET multiplexers/switches perform SONET pointer | However, not all SONET multiplexers/switches perform SONET pointer | |||
adjustments on all the STS-1s contained within a higher order SONET | adjustments on all the STS-1s contained within a higher order SONET | |||
signal passing through them. Alternatively, if they perform pointer | signal passing through them. Alternatively, if they perform pointer | |||
adjustments, they do not terminate the line overhead. For example, a | adjustments, they do not terminate the line overhead. For example, a | |||
multiplexer may take four SONET STS-48 signals and multiplex them | multiplexer may take four SONET STS-48 signals and multiplex them | |||
onto an STS-192 without performing standard line pointer adjustments | onto an STS-192 without performing standard line pointer adjustments | |||
skipping to change at line 967 | skipping to change at line 965 | |||
Line Level (or Section Preserves line overhead and switches | Line Level (or Section Preserves line overhead and switches | |||
Terminating) the entire line multiplex as a whole. | Terminating) the entire line multiplex as a whole. | |||
Section overhead is terminated or | Section overhead is terminated or | |||
modified. | modified. | |||
Section layer Preserves all section overhead, | Section layer Preserves all section overhead, | |||
Basically does not modify/terminate | Basically does not modify/terminate | |||
any of the SDH/SONET overhead bits. | any of the SDH/SONET overhead bits. | |||
5.2. Protection | 4.2. Protection | |||
SONET and SDH networks offer a variety of protection options at both | SONET and SDH networks offer a variety of protection options at both | |||
the SONET line (SDH multiplex section) and SDH/SONET path level | the SONET line (SDH multiplex section) and SDH/SONET path level | |||
[10],[11]. Standardized SONET line level protection techniques | [10],[11]. Standardized SONET line level protection techniques | |||
include: Linear 1+1 and linear 1:N automatic protection switching | include: Linear 1+1 and linear 1:N automatic protection switching | |||
(APS) and both two-fiber and four-fiber bi-directional line switched | (APS) and both two-fiber and four-fiber bi-directional line switched | |||
rings (BLSRs). At the path layer, SONET offers uni-directional path | rings (BLSRs). At the path layer, SONET offers uni-directional path | |||
switched ring protection. Likewise, standardized SDH multiplex | switched ring protection. Likewise, standardized SDH multiplex | |||
section protection techniques include linear 1+1 and 1:N automatic p | section protection techniques include linear 1+1 and 1:N automatic p | |||
protection switching and both two-fiber and four-fiber bi- | protection switching and both two-fiber and four-fiber bi- | |||
directional MS-SPRings (Multiplex Section-Shared Protection Rings). | directional MS-SPRings (Multiplex Section-Shared Protection Rings). | |||
At the path layer, SDH offers SNCP (sub-network connection | At the path layer, SDH offers SNCP (sub-network connection | |||
protection) ring protection. | protection) ring protection. | |||
Internet Draft Expires March 2005 Page 18 | ||||
Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | ||||
Both ring and 1:N line protection also allow for "extra traffic" to | 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 | 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 | used, i.e., when it is not carrying traffic for a failed working | |||
Bernstein/Mannie/Sharma Expires January 2005 18 | ||||
GMPLS based Control of SDH/SONET July 2004 | ||||
line. These protection methods are summarized in Table 5. It should | line. These protection methods are summarized in Table 5. It should | |||
be noted that these protection methods are completely separate from | be noted that these protection methods are completely separate from | |||
any MPLS layer protection or restoration mechanisms. | any GMPLS layer protection or restoration mechanisms. | |||
Table 5. Common SDH/SONET protection mechanisms. | Table 5. Common SDH/SONET protection mechanisms. | |||
Protection Type Extra Comments | Protection Type Extra Comments | |||
Traffic | Traffic | |||
Optionally | Optionally | |||
Supported | Supported | |||
1+1 No Requires no coordination | 1+1 No Requires no coordination | |||
Unidirectional between the two ends of the | Unidirectional between the two ends of the | |||
skipping to change at line 1037 | skipping to change at line 1034 | |||
UPSR (uni- No Dedicated protection via | UPSR (uni- No Dedicated protection via | |||
directional alternative ring path. | directional alternative ring path. | |||
path switched Typically used in access | path switched Typically used in access | |||
ring) networks. | ring) networks. | |||
It may be desirable to route some connections over lines that | It may be desirable to route some connections over lines that | |||
support protection of a given type, while others may be routed over | support protection of a given type, while others may be routed over | |||
unprotected lines, or as "extra traffic" over protection lines. | unprotected lines, or as "extra traffic" over protection lines. | |||
Also, to assist in the configuration of these various protection | Also, to assist in the configuration of these various protection | |||
methods it can be extremely valuable to advertise the link | methods it can be extremely valuable to advertise the link | |||
Internet Draft Expires March 2005 Page 19 | ||||
Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | ||||
protection attributes in the routing protocol, as is done in the | protection attributes in the routing protocol, as is done in the | |||
current GMPLS routing protocols. For example, suppose that a 1:N | current GMPLS routing protocols. For example, suppose that a 1:N | |||
protection group is being configured via two nodes. One must make | protection group is being configured via two nodes. One must make | |||
sure that the lines are "numbered the same" with respect to both | sure that the lines are "numbered the same" with respect to both | |||
Bernstein/Mannie/Sharma Expires January 2005 19 | ||||
GMPLS based Control of SDH/SONET July 2004 | ||||
ends of the connection or else the APS (K1/K2 byte) protocol will | ends of the connection or else the APS (K1/K2 byte) protocol will | |||
not correctly operate. | not correctly operate. | |||
Table 6. Parameters defining protection mechanisms. | Table 6. Parameters defining protection mechanisms. | |||
Protection Comments | Protection Comments | |||
Related Link | Related Link | |||
Information | Information | |||
Protection Type Indicates which of the protection types | Protection Type Indicates which of the protection types | |||
skipping to change at line 1090 | skipping to change at line 1087 | |||
line, Dedicated (1:1, 1+1)/Working Line, Enhanced (Ring) /Working | line, Dedicated (1:1, 1+1)/Working Line, Enhanced (Ring) /Working | |||
Line, represents the other. | Line, represents the other. | |||
There is also a potential implication for link bundling [16], [18] | There is also a potential implication for link bundling [16], [18] | |||
that is, for each link, the routing protocol could advertise whether | that is, for each link, the routing protocol could advertise whether | |||
that link is a working or protection link and possibly some | that link is a working or protection link and possibly some | |||
parameters from Table 6. A possible drawback of this scheme is that | parameters from Table 6. A possible drawback of this scheme is that | |||
the routing protocol would be burdened with advertising properties | the routing protocol would be burdened with advertising properties | |||
even for those protection links in the network that could not, in | even for those protection links in the network that could not, in | |||
fact, be used for routing working traffic, e.g., dedicated | fact, be used for routing working traffic, e.g., dedicated | |||
Internet Draft Expires March 2005 Page 20 | ||||
Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | ||||
protection links. An alternative method would be to bundle the | protection links. An alternative method would be to bundle the | |||
working and protection links together, and advertise the bundle | working and protection links together, and advertise the bundle | |||
instead. Now, for each bundled link, the protocol would have to | instead. Now, for each bundled link, the protocol would have to | |||
advertise the amount of bandwidth available on its working links, as | advertise the amount of bandwidth available on its working links, as | |||
well as the amount of bandwidth available on those protection links | well as the amount of bandwidth available on those protection links | |||
Bernstein/Mannie/Sharma Expires January 2005 20 | ||||
GMPLS based Control of SDH/SONET July 2004 | ||||
within the bundle that were capable of carrying "extra traffic." | within the bundle that were capable of carrying "extra traffic." | |||
This would reduce the amount of information to be advertised. An | This would reduce the amount of information to be advertised. An | |||
issue here would be to decide which types of working and protection | issue here would be to decide which types of working and protection | |||
links to bundle together. For instance, it might be preferable to | links to bundle together. For instance, it might be preferable to | |||
bundle working links (and their corresponding protection links) that | bundle working links (and their corresponding protection links) that | |||
are "shared" protected separately from working links that are | are "shared" protected separately from working links that are | |||
"dedicated" protected. | "dedicated" protected. | |||
5.3. Available Capacity Advertisement | 4.3. Available Capacity Advertisement | |||
Each SDH/SONET LSR must maintain an internal table per interface | Each SDH/SONET LSR must maintain an internal table per interface | |||
that indicates each signal in the multiplex structure that is | that indicates each signal in the multiplex structure that is | |||
allocated at that interface. This internal table is the most | allocated at that interface. This internal table is the most | |||
complete and accurate view of the link usage and available capacity. | complete and accurate view of the link usage and available capacity. | |||
For use in path computation, this information needs to be advertised | For use in path computation, this information needs to be advertised | |||
in some way to all others SDH/SONET LSRs in the same domain. There | in some way to all others SDH/SONET LSRs in the same domain. There | |||
is a trade off to be reached concerning: the amount of detail in the | is a trade off to be reached concerning: the amount of detail in the | |||
available capacity information to be reported via a link state | available capacity information to be reported via a link state | |||
skipping to change at line 1145 | skipping to change at line 1142 | |||
aggregate bandwidth usage in terms of number of whole STS-1s | aggregate bandwidth usage in terms of number of whole STS-1s | |||
(dedicated to DS3s) used and the number of STS-1s dedicated to | (dedicated to DS3s) used and the number of STS-1s dedicated to | |||
carrying DS1s allocated for this purpose. This way a network | carrying DS1s allocated for this purpose. This way a network | |||
optimization program could try to determine the optimal placement of | optimization program could try to determine the optimal placement of | |||
DS3s and DS1s to minimize wasted bandwidth due to half-empty STS-1s | DS3s and DS1s to minimize wasted bandwidth due to half-empty STS-1s | |||
at various places within the transport network. Similarly consider | at various places within the transport network. Similarly consider | |||
the set of super rate SONET signals (STS-Nc). If the links between | the set of super rate SONET signals (STS-Nc). If the links between | |||
the two switches support flexible concatenation then the reporting | the two switches support flexible concatenation then the reporting | |||
is particularly straightforward since any of the STS-1s within an | is particularly straightforward since any of the STS-1s within an | |||
STS-M can be used to comprise the transported STS- Nc. However, if | STS-M can be used to comprise the transported STS- Nc. However, if | |||
only standard concatenation is supported then reporting gets | ||||
Internet Draft Expires March 2005 Page 21 | ||||
Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | ||||
only standard concatenation is supported, then reporting gets | ||||
trickier since there are constraints on where the STS-1s can be | trickier since there are constraints on where the STS-1s can be | |||
placed. SDH has still more options and constraints, hence it is not | placed. SDH has still more options and constraints, hence it is not | |||
yet clear which is the best way to advertise bandwidth resource | yet clear which is the best way to advertise bandwidth resource | |||
availability/usage in SDH/SONET. At present, the GMPLS routing | availability/usage in SDH/SONET. At present, the GMPLS routing | |||
protocol extensions define minimum and maximum values for available | protocol extensions define minimum and maximum values for available | |||
Bernstein/Mannie/Sharma Expires January 2005 21 | ||||
GMPLS based Control of SDH/SONET July 2004 | ||||
bandwidth, which allows a remote node to make some deductions about | bandwidth, which allows a remote node to make some deductions about | |||
the amount of capacity available at a remote link and the types of | the amount of capacity available at a remote link and the types of | |||
signals it can accommodate. However, due to the multiplexed nature | signals it can accommodate. However, due to the multiplexed nature | |||
of the signals, the authors are of the opinion that reporting of | of the signals, reporting of bandwidth particular to signal types | |||
bandwidth particular to signal types rather than as a single | rather than as a single aggregate bit rate may be desirable. For | |||
aggregate bit rate is probably very desirable. For more details on | details on why this may be the case, we refer the reader to ITU-T | |||
why this is so, we refer the reader to ITU-T G.7715.1 [19] and to | publications G.7715.1 [19] and to Chapter 12 of [20]. | |||
Chapter 12 of [20]. | ||||
5.4. Path Computation | 4.4. Path Computation | |||
Although a link state routing protocol can be used to obtain network | Although a link state routing protocol can be used to obtain network | |||
topology and resource information, this does not imply the use of an | topology and resource information, this does not imply the use of an | |||
"open shortest path first" route [9]. The path must be open in the | "open shortest path first" route [9]. The path must be open in the | |||
sense that the links must be capable of supporting the desired | sense that the links must be capable of supporting the desired | |||
signal type and that capacity must be available to carry the | signal type and that capacity must be available to carry the | |||
signal. Other constraints may include hop count, total delay | signal. Other constraints may include hop count, total delay | |||
(mostly propagation), and underlying protection. In addition, it may | (mostly propagation), and underlying protection. In addition, it may | |||
be desirable to route traffic in order to optimize overall network | be desirable to route traffic in order to optimize overall network | |||
capacity, or reliability, or some combination of the two. Dikstra's | capacity, or reliability, or some combination of the two. Dikstra's | |||
skipping to change at line 1189 | skipping to change at line 1185 | |||
optimize network link utilization. One can think of this along the | optimize network link utilization. One can think of this along the | |||
lines of global or local optimization of the network in time. | lines of global or local optimization of the network in time. | |||
Due to the complexity of some of the connection routing algorithms | Due to the complexity of some of the connection routing algorithms | |||
(high dimensionality, non-linear integer programming problems) and | (high dimensionality, non-linear integer programming problems) and | |||
various criteria by which one may optimize a network, it may not be | various criteria by which one may optimize a network, it may not be | |||
possible or desirable to run these algorithms on network nodes. | possible or desirable to run these algorithms on network nodes. | |||
However, it may still be desirable to have some basic path | However, it may still be desirable to have some basic path | |||
computation ability running on the network nodes, particularly for | computation ability running on the network nodes, particularly for | |||
use during restoration situations. Such an approach is in line with | use during restoration situations. Such an approach is in line with | |||
the use of MPLS for traffic engineering, but is much different than | 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 | typical OSPF or IS-IS usage where all nodes must run the same | |||
routing algorithm. | routing algorithm. | |||
6. LSP Provisioning/Signaling for SDH/SONET | 5. LSP Provisioning/Signaling for SDH/SONET | |||
Traditionally, end-to-end circuit connections in SDH/SONET networks | Traditionally, end-to-end circuit connections in SDH/SONET networks | |||
have been set up via network management systems (NMSs), which issue | have been set up via network management systems (NMSs), which issue | |||
commands (usually under the control of a human operator) to the | commands (usually under the control of a human operator) to the | |||
various network elements involved in the circuit, via an equipment | various network elements involved in the circuit, via an equipment | |||
vendor's element management system (EMS). Very little multi-vendor | vendor's element management system (EMS). Very little multi-vendor | |||
interoperability has been achieved via management systems. Hence, | interoperability has been achieved via management systems. Hence, | |||
Internet Draft Expires March 2005 Page 22 | ||||
Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | ||||
end-to-end circuits in a multi-vendor environment typically require | end-to-end circuits in a multi-vendor environment typically require | |||
the use of multiple management systems and the infamous configuration | the use of multiple management systems and the infamous configuration | |||
via "yellow sticky notes". As discussed in Section 3, a common | via "yellow sticky notes". As discussed in Section 3, a common | |||
signaling protocol, such as RSVP with TE extensions or CR- LDP | signaling protocol, such as RSVP with TE extensions or CR- LDP | |||
appropriately extended for circuit switching applications, could | appropriately extended for circuit switching applications, could | |||
therefore help to solve these interoperability problems. In this | therefore help to solve these interoperability problems. In this | |||
Bernstein/Mannie/Sharma Expires January 2005 22 | ||||
GMPLS based Control of SDH/SONET July 2004 | ||||
section, we examine the various components involved in the automated | section, we examine the various components involved in the automated | |||
provisioning of SDH/SONET LSPs. | provisioning of SDH/SONET LSPs. | |||
6.1. What do we Label in SDH/SONET? Frames or Circuits? | 5.1. What do we Label in SDH/SONET? Frames or Circuits? | |||
MPLS was initially introduced to control asynchronous technologies | GMPLS was initially introduced to control asynchronous technologies | |||
like IP, where a label was attached to each individual block of | 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, | data, such as an IP packet or a Frame Relay frame. SONET and SDH, | |||
however, are synchronous technologies that define a multiplexing | however, are synchronous technologies that define a multiplexing | |||
structure (see Section 4), which we referred to as the SDH (or | structure (see Section 3), which we referred to as the SDH (or | |||
SONET) multiplex. This multiplex involves a hierarchy of signals, | SONET) multiplex. This multiplex involves a hierarchy of signals, | |||
lower order signals embedded within successive higher order ones | lower order signals embedded within successive higher order ones | |||
(see Fig. 1). Thus, depending on its level in the hierarchy, each | (see Fig. 1). Thus, depending on its level in the hierarchy, each | |||
signal consists of frames that repeat periodically, with a certain | signal consists of frames that repeat periodically, with a certain | |||
number of byte time slots per frame. | number of byte time slots per frame. | |||
The question then arises: is it these frames that we label in GMPLS? | 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" | 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 | need not have its own label, nor is it necessary to switch frames | |||
individually. Rather, the unit that is switched is a "flow" | individually. Rather, the unit that is switched is a "flow" | |||
skipping to change at line 1259 | skipping to change at line 1255 | |||
would limit the scope of the services that SDH/SONET can provide. | would limit the scope of the services that SDH/SONET can provide. | |||
Instead, GMPLS tunnels should be used to dynamically and | Instead, GMPLS tunnels should be used to dynamically and | |||
hierarchically control the SDH/SONET multiplex. For example, one | hierarchically control the SDH/SONET multiplex. For example, one | |||
unstructured VC-4 LSP may be established between two nodes, and | unstructured VC-4 LSP may be established between two nodes, and | |||
later lower order LSPs (e.g. VC-12) may be created within that | 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 | higher order LSP. This VC-4 LSP can, in fact, be established | |||
between two non-adjacent internal nodes in an SDH network, and later | between two non-adjacent internal nodes in an SDH network, and later | |||
advertised by a routing protocol as a new (virtual) link called a | advertised by a routing protocol as a new (virtual) link called a | |||
Forwarding Adjacency (FA) [17]. | Forwarding Adjacency (FA) [17]. | |||
Internet Draft Expires March 2005 Page 23 | ||||
Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | ||||
A SDH/SONET-LSR will have to identify each possible signal | A SDH/SONET-LSR will have to identify each possible signal | |||
individually per interface to fulfill the GMPLS operations. In order | individually per interface to fulfill the GMPLS operations. In order | |||
to stay transparent the LSR obviously should not touch the SDH/SONET | to stay transparent the LSR obviously should not touch the SDH/SONET | |||
overheads; this is why an explicit label is not encoded in the | overheads; this is why an explicit label is not encoded in the | |||
SDH/SONET overheads. Rather, a label is associated with each | SDH/SONET overheads. Rather, a label is associated with each | |||
Bernstein/Mannie/Sharma Expires January 2005 23 | ||||
GMPLS based Control of SDH/SONET July 2004 | ||||
individual signal. This approach is similar to the one considered | individual signal. This approach is similar to the one considered | |||
for lambda switching, except that it is more complex, since SONET | for lambda switching, except that it is more complex, since SONET | |||
and SDH define a richer multiplexing structure. Therefore a label | and SDH define a richer multiplexing structure. Therefore a label | |||
is associated with each signal, and is locally unique for each | is associated with each signal, and is locally unique for each | |||
signal at each interface. This signal could, and will most probably, | signal at each interface. This signal could, and will most probably, | |||
occupy different time-slots at different interfaces. | occupy different time-slots at different interfaces. | |||
6.2. Label Structure in SDH/SONET | 5.2. Label Structure in SDH/SONET | |||
The signaling protocol used to establish an SDH/SONET LSP must have | The signaling protocol used to establish an SDH/SONET LSP must have | |||
specific information elements in it to map a label to the particular | specific information elements in it to map a label to the particular | |||
signal type that it represents, and to the position of that signal | signal type that it represents, and to the position of that signal | |||
in the SDH/SONET multiplex. As we will see shortly, with a | in the SDH/SONET multiplex. As we will see shortly, with a | |||
carefully chosen label structure, the label itself can be made to | carefully chosen label structure, the label itself can be made to | |||
function as this information element. | function as this information element. | |||
In general, there are two ways to assign labels for signals between | In general, there are two ways to assign labels for signals between | |||
neighboring SDH/SONET LSRs. One way is for the labels to be | neighboring SDH/SONET LSRs. One way is for the labels to be | |||
skipping to change at line 1308 | skipping to change at line 1303 | |||
multiplex entry a unique associated value. This allows the unique | multiplex entry a unique associated value. This allows the unique | |||
identification of each multiplex entry (signal) in terms of its type | identification of each multiplex entry (signal) in terms of its type | |||
and position in the multiplex tree. By using this multiplex entry | and position in the multiplex tree. By using this multiplex entry | |||
value itself as the label, we automatically add SDH/SONET semantics | value itself as the label, we automatically add SDH/SONET semantics | |||
to the label! Thus, simply by examining the label, one can now | to the label! Thus, simply by examining the label, one can now | |||
directly deduce the signal that it represents, as well as its | directly deduce the signal that it represents, as well as its | |||
position in the SDH/SONET multiplex. We refer to this as | position in the SDH/SONET multiplex. We refer to this as | |||
multiplex-based labeling. This is the idea that was incorporated in | multiplex-based labeling. This is the idea that was incorporated in | |||
the GMPLS signaling specifications for SDH/SONET [18]. | the GMPLS signaling specifications for SDH/SONET [18]. | |||
6.3. Signaling Elements | 5.3. Signaling Elements | |||
In the preceding sections, we defined the meaning of a SDH/SONET | In the preceding sections, we defined the meaning of a SDH/SONET | |||
label and specified its structure. A question that arises naturally | label and specified its structure. A question that arises naturally | |||
at this point is the following. In an LSP or connection setup | 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 | request, how do we specify the signal for which we want to establish | |||
a path (and for which we desire a label)? | a path (and for which we desire a label)? | |||
Internet Draft Expires March 2005 Page 24 | ||||
Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | ||||
Clearly, information that is required to completely specify the | Clearly, information that is required to completely specify the | |||
desired signal and its characteristics must be transferred via the | desired signal and its characteristics must be transferred via the | |||
label distribution protocol, so that the switches along the path can | label distribution protocol, so that the switches along the path can | |||
be configured to correctly handle and switch the signal. This | be configured to correctly handle and switch the signal. This | |||
Bernstein/Mannie/Sharma Expires January 2005 24 | ||||
GMPLS based Control of SDH/SONET July 2004 | ||||
information is specified in three parts [18], each of which refers | information is specified in three parts [18], each of which refers | |||
to a different network layer. | to a different network layer. | |||
1. GENERALIZED_LABEL REQUEST (as in [6], [7]), which contains three | 1. GENERALIZED_LABEL REQUEST (as in [6], [7]), which contains three | |||
parts: LSP Encoding Type, Switching Type, and G-PID. | parts: LSP Encoding Type, Switching Type, and G-PID. | |||
The first specifies the nature/type of the LSP or the desired | The first specifies the nature/type of the LSP or the desired | |||
SDH/SONET channel, in terms of the particular signal (or collection | SDH/SONET channel, in terms of the particular signal (or collection | |||
of signals) within the SDH/SONET multiplex that the LSP represents, | of signals) within the SDH/SONET multiplex that the LSP represents, | |||
and is used by all the nodes along the path of the LSP. | and is used by all the nodes along the path of the LSP. | |||
The second specifies certain link selection constraints, which | The second specifies certain link selection constraints, which | |||
control, at each hop, the selection of the underlying link that is | control, at each hop, the selection of the underlying link that is | |||
used to transport this LSP. | used to transport this LSP. | |||
The third specifies the payload carried by the LSP or SDH/SONET | The third specifies the payload carried by the LSP or SDH/SONET | |||
channel, in terms of the termination and adaptation functions | channel, in terms of the termination and adaptation functions | |||
required at the end points, and is used by the source and | required at the end points, and is used by the source and | |||
destination nodes of the LSP. | destination nodes of the LSP. | |||
2. SONET/SDH TRAFFIC_PARAMETERS (as in [17], Section 2.1) used as a | 2. SONET/SDH TRAFFIC_PARAMETERS (as in [18], Section 2.1) used as a | |||
SENDER_TSPEC/FLOWSPEC, which contains 6 parts: Signal Type, | SENDER_TSPEC/FLOWSPEC, which contains 7 parts: Signal Type, | |||
(Requested Contiguous Concatenation (RCC), Number of Contiguous | (Requested Contiguous Concatenation (RCC), Number of Contiguous | |||
Components (NCC), Number of Virtual Components (NVC)), Multiplier | Components (NCC), Number of Virtual Components (NVC)), Multiplier | |||
(MT), Transparency, and Profile. | (MT), Transparency, and Profile. | |||
The Signal Type indicates the type of elementary signal comprising | The Signal Type indicates the type of elementary signal comprising | |||
the LSP, while the remaining fields indicate transforms that can be | the LSP, while the remaining fields indicate transforms that can be | |||
applied to the basic signal to build the final signal that | applied to the basic signal to build the final signal that | |||
corresponds to the LSP actually being requested. For instance (see | corresponds to the LSP actually being requested. For instance (see | |||
[18] for details): | [18] for details): | |||
skipping to change at line 1372 | skipping to change at line 1366 | |||
a virtually concatenated signal. | a virtually concatenated signal. | |||
- Third, some transparency (by using the Transparency field) | - Third, some transparency (by using the Transparency field) | |||
can be optionally specified when requesting a frame as | can be optionally specified when requesting a frame as | |||
signal rather than an SPE or VC based signal. | signal rather than an SPE or VC based signal. | |||
- Fourth, a multiplication (by using the Multiplier field) | - Fourth, a multiplication (by using the Multiplier field) | |||
can be optionally applied either directly on the Elementary | can be optionally applied either directly on the Elementary | |||
Signal, or on the contiguously concatenated signal obtained | Signal, or on the contiguously concatenated signal obtained | |||
from the first phase, or on the virtually concatenated signal | from the first phase, or on the virtually concatenated signal | |||
Internet Draft Expires March 2005 Page 25 | ||||
Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | ||||
obtained from the second phase, or on these signals combined | obtained from the second phase, or on these signals combined | |||
with some transparency. | with some transparency. | |||
Transparency indicates precisely which fields in these overheads | Transparency indicates precisely which fields in these overheads | |||
must be delivered unmodified at the other end of the LSP. An ingress | must be delivered unmodified at the other end of the LSP. An ingress | |||
Bernstein/Mannie/Sharma Expires January 2005 25 | ||||
GMPLS based Control of SDH/SONET July 2004 | ||||
LSR requesting transparency will pass these overhead fields that | LSR requesting transparency will pass these overhead fields that | |||
must be delivered to the egress LSR without any change. From the | 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 | ingress and egress LSRs point of views, these fields must be seen as | |||
unmodified. | unmodified. | |||
Transparency is not applied at the interfaces with the initiating | Transparency is not applied at the interfaces with the initiating | |||
and terminating LSRs, but is only applied between intermediate LSRs. | and terminating LSRs, but is only applied between intermediate LSRs. | |||
The transparency field is used to request an LSP that supports the | The transparency field is used to request an LSP that supports the | |||
requested transparency type; it may also be used to setup the | requested transparency type; it may also be used to setup the | |||
transparency process to be applied at each intermediate LSR. | transparency process to be applied at each intermediate LSR. | |||
Finally, the profile field is intended particular capabilities that | Finally, the profile field is intended particular capabilities that | |||
must be supported for the LSP, for example monitoring capabilities. | must be supported for the LSP, for example monitoring capabilities. | |||
No standard profile is currently defined, however. | No standard profile is currently defined, however. | |||
3. UPSTREAM_LABEL for Bi-directional LSP's (as in [6], [7]). | 3. UPSTREAM_LABEL for Bi-directional LSP's (as in [6], [7]). | |||
4. Local Link Selection e.g. IF_ID_RSVP_HOP Object (as in [7]). | 4. Local Link Selection e.g. IF_ID_RSVP_HOP Object (as in [7]). | |||
7. Summary and Conclusions | 6. Summary and Conclusions | |||
We provided a detailed account of the issues involved in applying | We provided a detailed account of the issues involved in applying | |||
generalized MPLS-based control (GMPLS) to TDM networks. | generalized GMPLS-based control (GMPLS) to TDM networks. | |||
We began with a brief overview of MPLS and SDH/SONET networks, | We began with a brief overview of GMPLS and SDH/SONET networks, | |||
discussing current circuit establishment in TDM networks, and | discussing current circuit establishment in TDM networks, and | |||
arguing why SDH/SONET technologies will not be "outdated" in the | arguing why SDH/SONET technologies will not be "outdated" in the | |||
foreseeable future. Next, we looked at IP/MPLS applied to SDH/SONET | foreseeable future. Next, we looked at IP/MPLS applied to SDH/SONET | |||
networks, where we considered why such an application makes sense, | networks, where we considered why such an application makes sense, | |||
and reviewed some MPLS terminology as applied to TDM networks. | and reviewed some GMPLS terminology as applied to TDM networks. | |||
We considered the two main areas of application of IP/MPLS methods | We considered the two main areas of application of IP/MPLS methods | |||
to TDM networks, namely routing and signaling, and discussed how | to TDM networks, namely routing and signaling, and discussed how | |||
Generalized MPLS routing and signaling are used in the context of | Generalized MPLS routing and signaling are used in the context of | |||
TDM networks. We reviewed in detail the switching capabilities of | TDM networks. We reviewed in detail the switching capabilities of | |||
TDM equipment, and the requirement to learn about the protection | TDM equipment, and the requirement to learn about the protection | |||
capabilities of underlying links, and how these influence the | capabilities of underlying links, and how these influence the | |||
available capacity advertisement in TDM networks. | available capacity advertisement in TDM networks. | |||
We focused briefly on path computation methods, pointing out that | We focused briefly on path computation methods, pointing out that | |||
these were not subject to standardization. We then examined optical | these were not subject to standardization. We then examined optical | |||
path provisioning or signaling, considering the issue of what | path provisioning or signaling, considering the issue of what | |||
constitutes an appropriate label for TDM circuits and how this label | constitutes an appropriate label for TDM circuits and how this label | |||
should be structured, and we focused on the importance of | should be structured, and we focused on the importance of | |||
hierarchical label allocation in a TDM network. Finally, we reviewed | hierarchical label allocation in a TDM network. Finally, we reviewed | |||
Internet Draft Expires March 2005 Page 26 | ||||
Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | ||||
the signaling elements involved when setting up an TDM circuit, | the signaling elements involved when setting up an TDM circuit, | |||
focusing on the nature of the LSP, the type of payload it carries, | 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 | and the characteristics of the links that the LSP wishes to use at | |||
each hop along its path for achieving a certain reliability. | each hop along its path for achieving a certain reliability. | |||
Bernstein/Mannie/Sharma Expires January 2005 26 | 7. Security Considerations | |||
GMPLS based Control of SDH/SONET July 2004 | ||||
8. Security Considerations | ||||
This draft raises no new security issues in the MPLS specifications. | This document describes the framework for GMPLS extensions for use | |||
in SDH/SONET control. As such, it introduces no new security issues | ||||
with respect to GMPLS specifications. GMPLS protocol specifications | ||||
should identify and address security issues specific to protocol. | ||||
9. Acknowledgments | 8. Acknowledgments | |||
We acknowledge all the participants of the MPLS and CCAMP WGs, whose | We acknowledge all the participants of the MPLS and CCAMP WGs, whose | |||
constant enquiry about GMPLS issues in TDM networks motivated the | constant enquiry about GMPLS issues in TDM networks motivated the | |||
writing of this document, and whose questions helped shape its | writing of this document, and whose questions helped shape its | |||
contents. Also, thanks to Kireeti Kompella for his careful reading | contents. Also, thanks to Kireeti Kompella for his careful reading | |||
of the last version of this draft, and for his helpful comments and | of the last version of this document, and for his helpful comments | |||
feedback, and to Dimitri Papadimitriou for his review on behalf of | and feedback, and to Dimitri Papadimitriou for his review on behalf | |||
the Routing Area Directorate, which provided many useful inputs to | of the Routing Area Directorate, which provided many useful inputs | |||
help update the document to confirm to the standards evolutions | to help update the document to conform to the standards evolutions | |||
since this document passed last call. | since this document passed last call. | |||
10.Author's Addresses | 9. Author's Addresses | |||
Greg Bernstein | Greg Bernstein | |||
Grotto Networking | Grotto Networking | |||
Phone: +1 510 573-2237 | Phone: +1 510 573-2237 | |||
E-mail: gregb@grotto-networking.com | E-mail: gregb@grotto-networking.com | |||
Eric Mannie | Eric Mannie | |||
InterAir Link | InterAir Link | |||
Phone: +32 2 790 34 25 | Phone: +32 2 790 34 25 | |||
E-mail: eric_mannie@hotmail.com | E-mail: eric_mannie@hotmail.com | |||
Vishal Sharma | Vishal Sharma | |||
Metanoia, Inc. | Metanoia, Inc. | |||
888 Villa Street, Suite 200B | 888 Villa Street, Suite 200B | |||
Mountain View, CA 94041 | Mountain View, CA 94041 | |||
Phone: +1 408 530 8313 | Phone: +1 408 530 8313 | |||
Email: v.sharma@ieee.org | Email: v.sharma@ieee.org | |||
11.References | Eric Gray | |||
Marconi Communications | ||||
E-mail: Eric.Gray@Marconi.com | ||||
11.1. Normative References | Internet Draft Expires March 2005 Page 27 | |||
Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | ||||
[1] Bradner, S., "The Internet Standards Process -- Revision 3", | 10. References | |||
BCP 9, RFC 2026, October 1996. | ||||
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement | 10.1. Normative References | |||
Levels", BCP 14, RFC 2119, March 1997. | ||||
[1] Bradner, S., "IETF Rights in Contributions" BCP 78, RFC 3667, | ||||
February, 2004. | ||||
[2] Bradner, S., "Intellectual Property Rights in IETF Technology", | ||||
BCP 79, RFC 3668, February, 2004. | ||||
10.2. 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. | ||||
[3] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol | [3] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol | |||
Label Switching Architecture", RFC 3031, January 2001. | Label Switching Architecture", RFC 3031, January 2001. | |||
Bernstein/Mannie/Sharma Expires January 2005 27 | ||||
GMPLS based Control of SDH/SONET July 2004 | ||||
[4] G.707, Network Node Interface for the Synchronous Digital | [4] G.707, Network Node Interface for the Synchronous Digital | |||
Hierarchy (SDH), International Telecommunication Union, March | Hierarchy (SDH), International Telecommunication Union, March | |||
1996. | 1996. | |||
[5] ANSI T1.105-1995, Synchronous Optical Network (SONET) Basic | [5] ANSI T1.105-1995, Synchronous Optical Network (SONET) Basic | |||
Description including Multiplex Structure, Rates, and Formats, | Description including Multiplex Structure, Rates, and Formats, | |||
American National Standards Institute. | American National Standards Institute. | |||
[6] Berger, L. (Editor), "Generalized MPLS - - Signaling Functional | [6] Berger, L. (Editor), "Generalized MPLS - Signaling Functional | |||
Description," RFC 3471, January 2003. | Description," RFC 3471, January 2003. | |||
[7] Berger, L. (Editor), "Generalized MPLS Signaling - - RSVP-TE | [7] Berger, L. (Editor), "Generalized MPLS Signaling - RSVP-TE | |||
Extensions," RFC 3473, January 2003. | Extensions," RFC 3473, January 2003. | |||
[8] Berger, L. (Editor), "Generalized MPLS Signaling - - CR-LDP | [8] Omitted. | |||
Extensions," RFC 3473, January 2003. | ||||
[9] Bernstein, G., Yates, J., Saha, D., "IP-Centric Control and | [9] Bernstein, G., Yates, J., Saha, D., "IP-Centric Control and | |||
Management of Optical Transport Networks," IEEE Communications | Management of Optical Transport Networks," IEEE Communications | |||
Mag., Vol. 40, Issue 10, October 2000. | Mag., Vol. 40, Issue 10, October 2000. | |||
[10] ANSI T1.105.01-1995, Synchronous Optical Network (SONET) | [10] ANSI T1.105.01-1995, Synchronous Optical Network (SONET) | |||
Automatic Protection Switching, American National Standards | Automatic Protection Switching, American National Standards | |||
Institute. | Institute. | |||
[11] G.841, Types and Characteristics of SDH Network Protection | [11] G.841, Types and Characteristics of SDH Network Protection | |||
Architectures, ITU-T, July 1995. | Architectures, ITU-T, July 1995. | |||
11.2. Informative References | ||||
[12] Kompella, K., et al, "Routing Extensions in Support of | [12] Kompella, K., et al, "Routing Extensions in Support of | |||
Generalized MPLS," Internet Draft, Work-in-Progress, draft- | Generalized MPLS," Internet Draft, Work-in-Progress, draft- | |||
ietf-ccamp-gmpls-routing-09.txt, October 2003. | ietf-ccamp-gmpls-routing-09.txt, October 2003. | |||
Internet Draft Expires March 2005 Page 28 | ||||
Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | ||||
[13] Kompella, K., et al, "OSPF Extensions in Support of Generalized | [13] Kompella, K., et al, "OSPF Extensions in Support of Generalized | |||
MPLS," Internet Draft, Work-in-Progress, draft-ietf-ccamp- | MPLS," Internet Draft, Work-in-Progress, draft-ietf-ccamp- | |||
ospf-extensions-12.txt, October 2003. | ospf-extensions-12.txt, October 2003. | |||
[14] Kompella, K., et al, "IS-IS Extensions in Support of | [14] Kompella, K., et al, "IS-IS Extensions in Support of | |||
Generalized MPLS," Internet Draft, Work-in-Progress, draft- | Generalized MPLS," Internet Draft, Work-in-Progress, draft- | |||
ietf-isis-gmpls-extensions-16.txt, August 2002. | ietf-isis-gmpls-extensions-16.txt, August 2002. | |||
[15] Bernstein, G., Sharma, V., Ong, L., "Inter-domain Optical | [15] Bernstein, G., Sharma, V., Ong, L., "Inter-domain Optical | |||
Routing, " OSA J. of Optical Networking, vol. 1, no. 2, pp. 80- | Routing, " OSA J. of Optical Networking, vol. 1, no. 2, pp. 80- | |||
92. | 92. | |||
[16] Kompella, K., Rekhter, Y., and Berger, L., "Link Bundling in | [16] Kompella, K., Rekhter, Y., and Berger, L., "Link Bundling in | |||
MPLS Traffic Engineering", Internet Draft, Work-in-Progress, | MPLS Traffic Engineering", Internet Draft, Work-in-Progress, | |||
draft-ietf-mpls-bundle-04.txt, July 2002. | draft-ietf-mpls-bundle-04.txt, July 2002. | |||
[17] Kompella, K., Rekhter, Y., "LSP Hierarchy with Generalized | [17] Kompella, K., Rekhter, Y., "LSP Hierarchy with Generalized | |||
MPLS-TE", Internet Draft, Work-in-Progress, draft-ietf-mpls- | MPLS-TE", Internet Draft, Work-in-Progress, draft-ietf-mpls- | |||
lsp-hierarchy-08.txt, September 2002. | lsp-hierarchy-08.txt, September 2002. | |||
Bernstein/Mannie/Sharma Expires January 2005 28 | ||||
GMPLS based Control of SDH/SONET July 2004 | ||||
[18] Mannie, E. (Editor), "GMPLS Extensions for SONET and SDH | [18] Mannie, E. (Editor), "GMPLS Extensions for SONET and SDH | |||
Control", Internet Draft, Work-in-Progress, draft-ietf-ccamp- | Control", Internet Draft, Work-in-Progress, draft-ietf-ccamp- | |||
gmpls-sonet-sdh-08.txt, February 2003. | gmpls-sonet-sdh-08.txt, February 2003. | |||
[19] G.7715.1, ASON Routing Architecture and Requirements for Link- | [19] G.7715.1, ASON Routing Architecture and Requirements for Link- | |||
State Protocols, International Telecommunications Union, | State Protocols, International Telecommunications Union, | |||
February 2004. | February 2004. | |||
[20] Bernstein, G., Rajagopalan, R., and Saha, D., "Optical Network | [20] Bernstein, G., Rajagopalan, R., and Saha, D., "Optical Network | |||
Control: Protocols, Architectures, and Standards," Addison- | Control: Protocols, Architectures, and Standards," Addison- | |||
Wesley, July 2003. | Wesley, July 2003. | |||
12.Intellectual Property Considerations | 11. Intellectual Property Statement | |||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
Intellectual Property Rights or other rights that might be claimed | Intellectual Property Rights or other rights that might be claimed | |||
to pertain to the implementation or use of the technology described | to pertain to the implementation or use of the technology described | |||
in this document or the extent to which any license under such | in this document or the extent to which any license under such | |||
rights might or might not be available; nor does it represent that | rights might or might not be available; nor does it represent that | |||
it has made any independent effort to identify any such rights. | it has made any independent effort to identify any such rights. | |||
Information on the procedures with respect to rights in RFC | Information on the procedures with respect to rights in RFC | |||
documents can be found in BCP 78 and BCP 79. | documents can be found in BCP 78 and BCP 79. | |||
Copies of IPR disclosures made to the IETF Secretariat and any | Copies of IPR disclosures made to the IETF Secretariat and any | |||
assurances of licenses to be made available, or the result of an | assurances of licenses to be made available, or the result of an | |||
attempt made to obtain a general license or permission for the use | attempt made to obtain a general license or permission for the use | |||
of such proprietary rights by implementers or users of this | of such proprietary rights by implementers or users of this | |||
specification can be obtained from the IETF on-line IPR repository | specification can be obtained from the IETF on-line IPR repository | |||
at http://www.ietf.org/ipr. | at http://www.ietf.org/ipr. | |||
The IETF invites any interested party to bring to its attention any | Internet Draft Expires March 2005 Page 29 | |||
copyrights, patents or patent applications, or other proprietary | Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | |||
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. | ||||
12.1. IPR Disclosure Acknowledgement | 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. | ||||
By submitting this Internet-Draft, I certify that any applicable | 12. Disclaimer of Validity | |||
patent or other IPR claims of which I am aware have been disclosed, | ||||
and any of which I become aware will be disclosed, in accordance | ||||
with RFC 3668. | ||||
13.Full Copyright Statement | 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. | ||||
13. Copyright Statement | ||||
"Copyright (C) The Internet Society (2004). This document is | "Copyright (C) The Internet Society (2004). This document is | |||
subject | subject to the rights, licenses and restrictions contained in BCP | |||
to the rights, licenses and restrictions contained in BCP 78, and | 78, and except as set forth therein, the authors retain all their | |||
except as set forth therein, the authors retain all their rights." | rights." | |||
Bernstein/Mannie/Sharma Expires January 2005 29 | 14. Acknowledgement | |||
GMPLS based Control of SDH/SONET July 2004 | ||||
"This document and the information contained herein are provided on | Funding for the RFC Editor function is currently provided by the | |||
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | Internet Society. | |||
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." | ||||
Bernstein/Mannie/Sharma Expires January 2005 30 | Internet Draft Expires March 2005 Page 30 | |||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |