draft-ietf-ccamp-sdhsonet-control-04.txt | draft-ietf-ccamp-sdhsonet-control-05.txt | |||
---|---|---|---|---|
Network 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) | |||
Category: Informational V. Sharma (Metanoia, Inc.) | Category: Informational V. Sharma (Metanoia, Inc.) | |||
E. Gray (Marconi Communications) | E. Gray (Marconi Communications) | |||
Expires March 30, 2005 September 2004 | Expires August 2005 February 2005 | |||
Framework for GMPLS-based Control of SDH/SONET Networks | Framework for GMPLS-based Control of SDH/SONET Networks | |||
<draft-ietf-ccamp-sdhsonet-control-04.txt> | <draft-ietf-ccamp-sdhsonet-control-05.txt> | |||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft and is subject to all provisions | This document is an Internet-Draft and is subject to all provisions | |||
of section 3 of RFC 3667 [1]. By submitting this Internet-Draft, | of section 3 of RFC 3667 [1] and Section 6 of RFC 3668 [2]. | |||
each author represents that any applicable patent or other IPR | ||||
claims of which he or she is aware have been or will be disclosed, | By submitting this Internet-Draft, each author represents that any | |||
and any of which he or she becomes aware of will be disclosed, in | applicable patent or other IPR claims of which he or she is aware | |||
accordance with RFC 3668 [2]. | have been or will be disclosed, and any of which he or she becomes | |||
aware will be disclosed, in accordance with Section 6 of RFC 3668. | ||||
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 reference | at any time. It is inappropriate to use Internet-Drafts as 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 | |||
GMPLS consists of a suite of protocol extensions to MPLS to make | Generalized MPLS (GMPLS) is a suite of protocol extensions to MPLS | |||
these protocols more generally applicable, to include - for example | (Multi-Protocol Label Switching) to make it generally applicable, to | |||
- control of non-packet based switching, and particularly, optical | include - for example - control of non packet-based switching, and | |||
switching. One area of prime consideration is to use Generalized | particularly, optical switching. One consideration is to use GMPLS | |||
MPLS (GMPLS) protocols in upgrading the control plane of optical | protocols to upgrade the control plane of optical transport networks. | |||
transport networks. This document illustrates this process by | This document illustrates this process by describing those extensions | |||
describing those extensions to GMPLS protocols that are directed | to GMPLS protocols that are aimed at controlling Synchronous Digital | |||
towards controlling SDH/SONET networks. SDH/SONET networks make | Hierarchy (SDH) or Synchronous Optical Networking (SONET) networks. | |||
very good examples of this process since they possess a rich | SDH/SONET networks make good examples of this process for a variety | |||
multiplex structure, a variety of protection/restoration options, | of reasons. This document high-lights extensions to GMPLS-related | |||
are well defined, and are widely deployed. The document discusses | routing protocols to disseminate information needed in transport path | |||
extensions to GMPLS routing protocols to disseminate information | computation and network operations, together with (G)MPLS protocol | |||
needed in transport path computation and network operations, | extensions required for the provisioning of transport circuits. New | |||
together with the extensions to GMPLS label distribution protocols | capabilities that an GMPLS control plane would bring to SDH/SONET | |||
needed for the provisioning of transport circuits. New capabilities | networks, such as new restoration methods and multi-layer circuit | |||
that an GMPLS control plane would bring to SDH/SONET networks, such | establishment, are also discussed. | |||
as new restoration methods and multi-layer circuit establishment, | ||||
are also discussed. | ||||
Internet Draft Expires March 2005 Page 1 | ||||
Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | ||||
1. Introduction.................................................3 | 1. Introduction ................................................3 | |||
1.1. MPLS Overview..............................................3 | 1.1. MPLS Overview .............................................3 | |||
1.2. SDH/SONET Overview.........................................4 | 1.2. SDH/SONET Overview ........................................4 | |||
1.3. The Current State of Circuit Establishment in SDH/SONET | 1.3. The Current State of Circuit Establishment in SDH/SONET | |||
Networks...................................................7 | Networks ..................................................7 | |||
1.3.1. Administrative Tasks...................................7 | 1.3.1. Administrative Tasks ..................................7 | |||
1.3.2. Manual Operations......................................7 | 1.3.2. Manual Operations .....................................7 | |||
1.3.3. Planning Tool Operation................................7 | 1.3.3. Planning Tool Operation ...............................7 | |||
1.3.4. Circuit Provisioning...................................8 | 1.3.4. Circuit Provisioning ..................................8 | |||
1.4. Centralized Approach versus Distributed Approach...........8 | 1.4. Centralized Approach versus Distributed Approach ..........8 | |||
1.4.1. Topology Discovery and Resource Dissemination..........9 | 1.4.1. Topology Discovery and Resource Dissemination .........9 | |||
1.4.2. Path Computation (Route Determination).................9 | 1.4.2. Path Computation (Route Determination).................9 | |||
1.4.3. Connection Establishment (Provisioning)...............10 | 1.4.3. Connection Establishment (Provisioning)...............10 | |||
1.5. Why SDH/SONET will not Disappear Tomorrow.................11 | 1.5. Why SDH/SONET will not Disappear Tomorrow ................11 | |||
2. GMPLS Applied to SDH/SONET..................................12 | 2. GMPLS Applied to SDH/SONET .................................12 | |||
2.1. Controlling the SDH/SONET Multiplex.......................12 | 2.1. Controlling the SDH/SONET Multiplex ......................12 | |||
2.2. SDH/SONET LSR and LSP Terminology.........................13 | 2.2. SDH/SONET LSR and LSP Terminology ........................13 | |||
3. Decomposition of the GMPLS Circuit-Switching Problem Space..13 | 3. Decomposition of the GMPLS Circuit-Switching Problem Space .13 | |||
4. GMPLS Routing for SDH/SONET.................................14 | 4. GMPLS Routing for SDH/SONET ................................14 | |||
4.1. Switching Capabilities....................................15 | 4.1. Switching Capabilities ...................................15 | |||
4.1.1. Switching Granularity.................................15 | 4.1.1. Switching Granularity ................................15 | |||
4.1.2. Signal Concatenation Capabilities.....................16 | 4.1.2. Signal Concatenation Capabilities ....................16 | |||
4.1.3. SDH/SONET Transparency................................17 | 4.1.3. SDH/SONET Transparency ...............................17 | |||
4.2. Protection................................................18 | 4.2. Protection ...............................................18 | |||
4.3. Available Capacity Advertisement..........................21 | 4.3. Available Capacity Advertisement .........................21 | |||
4.4. Path Computation..........................................22 | 4.4. Path Computation .........................................22 | |||
5. LSP Provisioning/Signaling for SDH/SONET....................22 | 5. LSP Provisioning/Signaling for SDH/SONET ...................22 | |||
5.1. What do we Label in SDH/SONET? Frames or Circuits?........23 | 5.1. What do we Label in SDH/SONET? Frames or Circuits?........23 | |||
5.2. Label Structure in SDH/SONET..............................24 | 5.2. Label Structure in SDH/SONET .............................24 | |||
5.3. Signaling Elements........................................24 | 5.3. Signaling Elements .......................................24 | |||
6. Summary and Conclusions.....................................26 | 6. Summary and Conclusions ....................................26 | |||
7. Security Considerations.....................................27 | 7. Security Considerations ....................................27 | |||
8. Acknowledgments.............................................27 | 8. Acknowledgments ............................................27 | |||
9. Author's Addresses..........................................27 | 9. Author's Addresses .........................................27 | |||
10. References..................................................28 | 10. References .................................................28 | |||
10.1. Normative References....................................28 | 10.1. Normative References ...................................28 | |||
10.2. Informative References..................................28 | 10.2. Informative References .................................28 | |||
11. Intellectual Property Statement.............................29 | 11. Intellectual Property Statement ............................29 | |||
12. Disclaimer of Validity......................................30 | 12. Disclaimer .................................................30 | |||
13. Copyright Statement.........................................30 | 13. Copyright Statement ........................................30 | |||
14. Acknowledgement..............................................30 | 14. IANA Considerations .........................................30 | |||
15. Acronyms ....................................................30 | ||||
Internet Draft Expires March 2005 Page 2 | 16. Acknowledgement .............................................31 | |||
Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | ||||
1. Introduction | 1. Introduction | |||
The CCAMP Working Group of the IETF has the goal of extending MPLS | The CCAMP Working Group of the IETF has the goal of extending MPLS | |||
[3] protocols to support multiple network layers and new services. | [3] protocols to support multiple network layers and new services. | |||
This extended MPLS, which was initially known as Multi-Protocol | This extended MPLS, which was initially known as Multi-Protocol | |||
Lambda Switching, is now better referred to as Generalized MPLS (or | Lambda Switching, is now better referred to as 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 | |||
skipping to change at line 148 | skipping to change at line 143 | |||
1.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 | |||
based forwarding plane. | packet-based forwarding plane. | |||
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. | |||
skipping to change at line 211 | skipping to change at line 203 | |||
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. | |||
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 | |||
made of contiguous frames that consist of transport overhead | made of contiguous frames that consist of transport overhead | |||
(header) and payload. To solve synchronization issues, the actual | (header) and payload. To solve synchronization issues, the actual | |||
data is not transported directly in the payload but rather in | data is not transported directly in the payload but rather in | |||
another internal frame that is allowed to float over two successive | another internal frame that is allowed to float over two successive | |||
SDH/SONET payloads. This internal frame is named a Virtual Container | SDH/SONET payloads. This internal frame is named a Virtual Container | |||
(VC) in SDH and a Synchronous Payload Envelope (SPE) in SONET. | (VC) in SDH and a SONET Payload Envelope (SPE) in SONET. | |||
The SDH/SONET architecture identifies three different layers, each | The SDH/SONET architecture identifies three different layers, each | |||
of which corresponds to one level of communication between SDH/SONET | of which corresponds to one level of communication between SDH/SONET | |||
equipment. These are, starting with the lowest, the regenerator | equipment. These are, starting with the lowest, the regenerator | |||
section/section layer, the multiplex section/line layer, and (at the | section/section layer, the multiplex section/line layer, and (at the | |||
top) the path layer. Each of these layers in turn has its own | top) the path layer. Each of these layers in turn has its own | |||
overhead (header). The transport overhead of a SDH/SONET frame is | overhead (header). The transport overhead of a SDH/SONET frame is | |||
mainly sub-divided in two parts that contain the regenerator | mainly sub-divided in two parts that contain the regenerator | |||
section/section overhead and the multiplex section/line overhead. In | section/section overhead and the multiplex section/line overhead. In | |||
addition, a pointer (in the form of the H1, H2 and H3 bytes) | addition, a pointer (in the form of the H1, H2 and H3 bytes) | |||
skipping to change at line 267 | skipping to change at line 256 | |||
does not fill a time slot completely, and the mapping rules define | does not fill a time slot completely, and the mapping rules define | |||
precisely how to fill it. | precisely how to fill it. | |||
What is important for the GMPLS-based control of SDH/SONET circuits | What is important for the GMPLS-based control of SDH/SONET circuits | |||
is to identify the elements that can be switched from an input | is to identify the elements that can be switched from an input | |||
multiplex on one interface to an output multiplex on another | multiplex on one interface to an output multiplex on another | |||
interface. The only elements that can be switched are those that can | 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 | be re-aligned via a pointer, i.e. a VC-x in the case of SDH and a | |||
SPE in the case of SONET. | 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 | |||
STM-0<------------AU-3<---VC-3<-- I ---------------------I | STM-0<------------AU-3<---VC-3<-- I ---------------------I | |||
^ I | ^ I | |||
Ix7 Ix7 | Ix7 Ix7 | |||
skipping to change at line 319 | skipping to change at line 305 | |||
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, | |||
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. | |||
1.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 | |||
skipping to change at line 372 | skipping to change at line 355 | |||
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. | |||
1.3.3. Planning Tool Operation | 1.3.3. Planning Tool Operation | |||
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. | |||
skipping to change at line 427 | skipping to change at line 407 | |||
approach has its merits. The application of GMPLS to SDH/SONET | approach has its merits. The application of GMPLS to SDH/SONET | |||
networks does not preclude either model, although GMPLS 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 | |||
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 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 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. | |||
skipping to change at line 452 | skipping to change at line 428 | |||
are handled via the centralized and distributed approaches: | are handled via the centralized and distributed approaches: | |||
1.4.1. Topology Discovery and Resource Dissemination | 1.4.1. Topology Discovery and Resource Dissemination | |||
Currently an NMS maintains a consistent view of all the networking | Currently an NMS maintains a consistent view of all the networking | |||
layers under its 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 disseminate 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 | |||
skipping to change at line 484 | skipping to change at line 460 | |||
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 | |||
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. | |||
Internet Draft Expires March 2005 Page 9 | ||||
Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | ||||
1.4.3. Connection Establishment (Provisioning) | 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 | |||
skipping to change at line 522 | skipping to change at line 495 | |||
Distributed load Bottleneck: #requests and | Distributed load Bottleneck: #requests and | |||
actions to/from NMS | actions to/from NMS | |||
Individual local routing Centralized routing decision, | Individual local routing Centralized routing decision, | |||
decision can be done per block of | decision can be done per block of | |||
requests | requests | |||
Routing scalable as for the Assumes a few big | Routing scalable as for the Assumes a few big | |||
Internet administrative domains | Internet administrative domains | |||
Complex to change routing Very easy local upgrade (non- | Complex to change routing Very easy local upgrade (non | |||
protocol/algorithm intrusive) | protocol/algorithm intrusive) | |||
Requires enhanced routing Better consistency | Requires enhanced routing Better consistency | |||
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 | |||
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 | |||
skipping to change at line 594 | skipping to change at line 564 | |||
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 | |||
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 | |||
transmission; sufficient timing information, to allow robust | transmission; sufficient timing information, to allow robust | |||
synchronization (that is, to detect the beginning of a packet). In | synchronization (that is, to detect the beginning of a packet). In | |||
the case where associated signaling is used (that is the control and | the case where associated signaling is used (that is the control and | |||
data plane topologies are congruent) the encapsulation should also | data plane topologies are congruent) the encapsulation should also | |||
provide the capacity to transport signaling, routing and management | provide the capacity to transport signaling, routing and management | |||
messages, in order to control the optical switches. Rather SDH and | messages, in order to control the optical switches. Rather SDH and | |||
SONET cover all these aspects natively, except FEC, which tends to | SONET cover all these aspects natively, except FEC, which tends to | |||
be supported in a proprietary way. (We note, however, that | be supported in a proprietary way. (We note, however, that | |||
associated signaling is not a requirement for the GMPLS-based | associated signaling is not a requirement for the GMPLS-based | |||
control of SDH/SONET networks. Rather, it is just one option. Non- | control of SDH/SONET networks. Rather, it is just one option. Non | |||
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. | |||
skipping to change at line 649 | skipping to change at line 615 | |||
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. | |||
Internet Draft Expires March 2005 Page 12 | ||||
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. SDH also | 4-Xc or a VC-2-mc can be switched and controlled by GMPLS. SDH also | |||
skipping to change at line 677 | skipping to change at line 640 | |||
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 | |||
configure the input interface, switch fabric, and output interface | configure the input interface, switch fabric, and output interface | |||
of each SDH/SONET LSR along the path. An SDH/SONET LSP can be point- | of each SDH/SONET LSR along the path. An SDH/SONET LSP can be | |||
to-point or point-to-multipoint, but not multipoint-to-point, since | point-to-point or point-to-multipoint, but not multipoint-to-point, | |||
no merging is possible with SDH/SONET signals. | since 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. | |||
3. Decomposition of the GMPLS Circuit-Switching Problem Space | 3. Decomposition of the GMPLS Circuit-Switching Problem Space | |||
skipping to change at line 704 | skipping to change at line 667 | |||
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 | |||
Internet Draft Expires March 2005 Page 13 | ||||
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 | |||
switches concerning an end-to-end STS-1 path traversing a network, | switches concerning an end-to-end STS-1 path traversing a network, | |||
skipping to change at line 760 | skipping to change at line 719 | |||
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 [12], [13], | proposed in the GMPLS extensions to IP routing protocols [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 | |||
Internet Draft Expires March 2005 Page 14 | ||||
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 | |||
user services. Due to the increase in information transferred in | user services. Due to the increase in information transferred in | |||
skipping to change at line 814 | skipping to change at line 769 | |||
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 | |||
Internet Draft Expires March 2005 Page 15 | ||||
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 | |||
skipping to change at line 870 | skipping to change at line 821 | |||
(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. | |||
Internet Draft Expires March 2005 Page 16 | ||||
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 the 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 than packet switched | significantly easier to implement with SDH/SONET than packet switched | |||
circuits, because ensuring that timing and in-order frame delivery is | circuits, because ensuring that timing and in-order frame delivery is | |||
preserved may be simpler to establish using SDH/SONET rather than | preserved may be simpler to establish using SDH/SONET rather than | |||
packet switched circuits, where more sophisticated techniques may be | packet switched circuits, where more sophisticated techniques may be | |||
needed. | 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 | |||
order signals. | higher-order signals. | |||
Table 3 Capacity of Virtually Concatenated VTn-Xv (9/G.707) | Table 3 Capacity of Virtually Concatenated VTn-Xv (9/G.707) | |||
Carried In X Capacity In steps | Carried In X Capacity In steps | |||
of | of | |||
VT1.5/ STS-1/VC-3 1 to 28 1600kbit/s to 1600kbit/s | VT1.5/ STS-1/VC-3 1 to 28 1600kbit/s to 1600kbit/s | |||
VC-11-Xv 44800kbit/s | VC-11-Xv 44800kbit/s | |||
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 | |||
skipping to change at line 924 | skipping to change at line 872 | |||
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 | |||
Internet Draft Expires March 2005 Page 17 | ||||
Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | ||||
three layers: Section, Line and Path. Each of these layers is | three layers: Section, Line and Path. Each of these layers is | |||
concerned with fault and performance monitoring. The Section | 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 | |||
skipping to change at line 975 | skipping to change at line 919 | |||
4.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 | |||
directional MS-SPRings (Multiplex Section-Shared Protection Rings). | 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 | |||
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 GMPLS 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 | |||
skipping to change at line 1034 | skipping to change at line 976 | |||
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 | |||
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 | |||
skipping to change at line 1087 | skipping to change at line 1025 | |||
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 | |||
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 | |||
skipping to change at line 1142 | skipping to change at line 1076 | |||
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 | |||
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 | 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 | |||
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, reporting of bandwidth particular to signal types | of the signals, reporting of bandwidth particular to signal types | |||
rather than as a single aggregate bit rate may be desirable. For | rather than as a single aggregate bit rate may be desirable. For | |||
details on why this may be the case, we refer the reader to ITU-T | details on why this may be the case, we refer the reader to ITU-T | |||
publications G.7715.1 [19] and to Chapter 12 of [20]. | publications G.7715.1 [19] and to Chapter 12 of [20]. | |||
4.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. | |||
signal. Other constraints may include hop count, total delay | Other constraints may include hop count, total delay (mostly | |||
(mostly propagation), and underlying protection. In addition, it may | propagation), and underlying protection. In addition, it may be | |||
be desirable to route traffic in order to optimize overall network | 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 | |||
algorithm computes the shortest path with respect to link weights | algorithm computes the shortest path with respect to link weights | |||
for a single connection at a time. This can be much different than | for a single connection at a time. This can be much different than | |||
the paths that would be selected in response to a request to set up | the paths that would be selected in response to a request to set up | |||
a batch of connections between a set of endpoints in order to | a batch of connections between a set of endpoints in order to | |||
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 | |||
skipping to change at line 1197 | skipping to change at line 1127 | |||
routing algorithm. | routing algorithm. | |||
5. 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 | |||
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. | |||
5.1. What do we Label in SDH/SONET? Frames or Circuits? | 5.1. What do we Label in SDH/SONET? Frames or Circuits? | |||
GMPLS 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, | |||
skipping to change at line 1234 | skipping to change at line 1160 | |||
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" | |||
comprised of a continuous sequence of time slots that appear at a | comprised of a continuous sequence of time slots that appear at a | |||
given position in a frame. That is, we switch an individual SONET or | given position in a frame. That is, we switch an individual SONET or | |||
SDH signal, and a label associated with each given signal. | SDH signal, and a label associated with each given signal. | |||
For instance, the payload of an SDH STM-1 frame does not fully | For instance, the payload of an SDH STM-1 frame does not fully | |||
contain a complete unit of user data. In fact, the user data is | contain a complete unit of user data. In fact, the user data is | |||
contained in a virtual container (VC) that is allowed to float over | contained in a virtual container (VC) that is allowed to float over | |||
two contiguous frames for synchronization purposes. The H1-H2-H3 Au- | two contiguous frames for synchronization purposes. The H1-H2-H3 | |||
n pointer bytes in the SDH overhead indicates the beginning of the | Au-n pointer bytes in the SDH overhead indicates the beginning of the | |||
VC in the payload. Thus, frames are now inter-related, since each | VC in the payload. Thus, frames are now inter-related, since each | |||
consecutive pair may share a common virtual container. From the | consecutive pair may share a common virtual container. From the | |||
point of view of GMPLS, therefore, it is not the successive frames | point of view of GMPLS, therefore, it is not the successive frames | |||
that are treated independently or labeled, but rather the entire | that are treated independently or labeled, but rather the entire | |||
user signal. An identical argument applies to SONET. | user signal. An identical argument applies to SONET. | |||
Observe also that the GMPLS signaling used to control the SDH/SONET | Observe also that the GMPLS signaling used to control the SDH/SONET | |||
multiplex must honor its hierarchy. In other words, the SDH/SONET | multiplex must honor its hierarchy. In other words, the SDH/SONET | |||
layer should not be viewed as homogeneous and flat, because this | layer should not be viewed as homogeneous and flat, because this | |||
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 | |||
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, | |||
skipping to change at line 1310 | skipping to change at line 1233 | |||
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]. | |||
5.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 | |||
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. | |||
skipping to change at line 1366 | skipping to change at line 1285 | |||
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 | |||
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. | |||
skipping to change at line 1421 | skipping to change at line 1336 | |||
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. | |||
7. Security Considerations | 7. Security Considerations | |||
This document describes the framework for GMPLS extensions for use | This document describes the framework for GMPLS extensions for use | |||
in SDH/SONET control. As such, it introduces no new security issues | in SDH/SONET control. As such, it introduces no new security issues | |||
with respect to GMPLS specifications. GMPLS protocol specifications | with respect to GMPLS specifications. GMPLS protocol specifications | |||
should identify and address security issues specific to protocol. | should identify and address security issues specific to protocol. | |||
Among the considerations that should be addressed by GMPLS protocol | ||||
specifications, are any security vulnerabilities that are introduced | ||||
by specific GMPLS extensions added in each specification. | ||||
8. 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 document, and for his helpful comments | of the last version of this document, and for his helpful comments | |||
and feedback, and to Dimitri Papadimitriou for his review on behalf | and feedback, and to Dimitri Papadimitriou for his review on behalf | |||
of the Routing Area Directorate, which provided many useful inputs | of the Routing Area Directorate, which provided many useful inputs | |||
to help update the document to conform to the standards evolutions | to help update the document to conform to the standards evolutions | |||
skipping to change at line 1472 | skipping to change at line 1387 | |||
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 | |||
Eric Gray | Eric Gray | |||
Marconi Communications | Marconi Communications | |||
E-mail: Eric.Gray@Marconi.com | E-mail: Eric.Gray@Marconi.com | |||
Internet Draft Expires March 2005 Page 27 | ||||
Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | ||||
10. References | 10. References | |||
10.1. Normative References | 10.1. Normative References | |||
[1] Bradner, S., "IETF Rights in Contributions" BCP 78, RFC 3667, | [1] Bradner, S., "IETF Rights in Contributions" BCP 78, RFC 3667, | |||
February, 2004. | February, 2004. | |||
[2] Bradner, S., "Intellectual Property Rights in IETF Technology", | [2] Bradner, S., "Intellectual Property Rights in IETF Technology", | |||
BCP 79, RFC 3668, February, 2004. | BCP 79, RFC 3668, February, 2004. | |||
skipping to change at line 1522 | skipping to change at line 1434 | |||
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. | |||
[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, | |||
ietf-ccamp-gmpls-routing-09.txt, October 2003. | draft-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, | |||
ospf-extensions-12.txt, October 2003. | draft-ietf-ccamp-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, | |||
ietf-isis-gmpls-extensions-16.txt, August 2002. | draft-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. | |||
92. | 80-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, | |||
lsp-hierarchy-08.txt, September 2002. | draft-ietf-mpls-lsp-hierarchy-08.txt, February 2002. | |||
[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, | |||
gmpls-sonet-sdh-08.txt, February 2003. | draft-ietf-ccamp-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 | |||
State Protocols, International Telecommunications Union, | Link-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," | |||
Wesley, July 2003. | Addison-Wesley, July 2003. | |||
11. Intellectual Property Statement | 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 | |||
to pertain to the implementation or use of the technology described | pertain to the implementation or use of the technology described in | |||
in this document or the extent to which any license under such | this document or the extent to which any license under such rights | |||
rights might or might not be available; nor does it represent that | might or might not be available; nor does it represent that it has | |||
it has made any independent effort to identify any such rights. | made any independent effort to identify any such rights. Information | |||
Information on the procedures with respect to rights in RFC | on the procedures with respect to rights in RFC documents can be | |||
documents can be found in BCP 78 and BCP 79. | 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. | |||
Internet Draft Expires March 2005 Page 29 | ||||
Bernstein, et al GMPLS based Control of SDH/SONET September 2004 | ||||
The IETF invites any interested party to bring to its attention | The IETF invites any interested party to bring to its attention | |||
any copyrights, patents or patent applications, or other | any copyrights, patents or patent applications, or other | |||
proprietary rights that may cover technology that may be required | proprietary rights that may cover technology that may be required | |||
to implement this standard. Please address the information to the | to implement this standard. Please address the information to the | |||
IETF at ietf-ipr@ietf.org. | IETF at ietf-ipr@ietf.org. | |||
12. Disclaimer of Validity | 12. Disclaimer | |||
This document and the information contained herein are provided on | This document and the information contained herein are provided on an | |||
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | |||
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | |||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, | ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | |||
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT | INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | |||
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR | INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | |||
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |||
PARTICULAR PURPOSE. | ||||
13. Copyright Statement | 13. Copyright Statement | |||
"Copyright (C) The Internet Society (2004). This document is | Copyright (C) The Internet Society (2004). This document is | |||
subject to the rights, licenses and restrictions contained in BCP | subject to the rights, licenses and restrictions contained in BCP | |||
78, and except as set forth therein, the authors retain all their | 78, and except as set forth therein, the authors retain all their | |||
rights." | rights. | |||
14. Acknowledgement | 14. IANA Considerations | |||
There are no IANA considerations that apply to this document. | ||||
15. Acronyms | ||||
ANSI - American National Standards Institute | ||||
APS - Automatic Protection Switching | ||||
ATM - Asynchronous Transfer Mode | ||||
BLSR - Bi-directional Line Switch Ring | ||||
CPE - Customer Premise Equipment | ||||
DLCI - Data Link Connection Identifier | ||||
ETSI - European Telecommunication Standards Institute | ||||
FEC - Forwarding Equivalency Class | ||||
GMPLS - Generalized MPLS | ||||
IP - Internet Protocol | ||||
IS-IS - Intermediate System to Intermediate System (RP) | ||||
LDP - Label Distribution Protocol | ||||
LSP - Label Switched Path | ||||
LSR - Label Switching Router | ||||
MPLS - Multi-Protocol Label Switching | ||||
NMS - Network Management System | ||||
OSPF - Open Shortest Path First (RP) | ||||
PNNI - Private Network Node Interface | ||||
PPP - Point to Point Protocol | ||||
QoS - Quality of Service | ||||
RP - Routing Protocol | ||||
RSVP - ReSerVation Protocol | ||||
SDH - Synchronous Digital Hierarchy | ||||
SNMP - Simple Network Management Protocol | ||||
SONET - Synchronous Optical NETworking | ||||
SPE - SONET Payload Envelope | ||||
STM - Synchronous Transport Module (or Terminal Multiplexer) | ||||
STS - Synchronous Transport Signal | ||||
TDM - Time Division Multiplexer | ||||
TE - Traffic Engineering | ||||
TMN - Telecommunication Management Network | ||||
UPSR - Uni-directional Path Switch Ring | ||||
VC - Virtual Container (SDH) or Virtual Circuit | ||||
VCI - Virtual Circuit Identifier (ATM) | ||||
VPI - Virtual Path Identifier (ATM) | ||||
VT - Virtual Tributary | ||||
WDM - Wave-length Division Multiplexing | ||||
16. Acknowledgement | ||||
Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is currently provided by the | |||
Internet Society. | Internet Society. | |||
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/ |