requested transparency type; it may also be used to setup the
transparency process to be applied at each intermediate LSR.
Finally, the profile field is intended to specify particular
capabilities that must be supported for the LSP, for example
monitoring capabilities. However, no standard profile is currently
defined.
3. UPSTREAM_LABEL for Bi-directional LSP’s (as in [4], [5]).
4. Local Link Selection, e.g., IF_ID_RSVP_HOP Object (as in [5]).
6. Summary and Conclusions
We provided a detailed account of the issues involved in applying
generalized GMPLS-based control (GMPLS) to TDM networks.
We began with a brief overview of GMPLS and SDH/SONET networks,
discussing current circuit establishment in TDM networks, and arguing
why SDH/SONET technologies will not be "outdated" in the foreseeable
future. Next, we looked at IP/MPLS applied to SDH/SONET networks,
where we considered why such an application makes sense, and reviewed
some GMPLS terminology as applied to TDM networks.
We considered the two main areas of application of IP/MPLS methods to
TDM networks, namely routing and signaling, and discussed how
Generalized MPLS routing and signaling are used in the context of TDM
networks. We reviewed in detail the switching capabilities of TDM
equipment, and the requirement to learn about the protection
capabilities of underlying links, and how these influence the
available capacity advertisement in TDM networks.
We focused briefly on path computation methods, pointing out that
these were not subject to standardization. We then examined optical
path provisioning or signaling, considering the issue of what
constitutes an appropriate label for TDM circuits and how this label
should be structured; and we focused on the importance of
hierarchical label allocation in a TDM network. Finally, we reviewed
the signaling elements involved when setting up a TDM circuit,
focusing on the nature of the LSP, the type of payload it carries,
and the characteristics of the links that the LSP wishes to use at
each hop along its path for achieving a certain reliability.
7. Security Considerations
The use of a control plane to provision connectivity through a
SONET/SDH network shifts the security burden significantly from the
management plane to the control plane. Before the introduction of a
control plane, the communications that had to be secured were between
the management stations (Element Management Systems or Network
Management Systems) and each network element that participated in the
network connection. After the introduction of the control plane, the
only management plane communication that needs to be secured is that
to the head-end (ingress) network node as the end-to-end service is
requested. On the other hand, the control plane introduces a new
requirement to secure signaling and routing communications between
adjacent nodes in the network plane.
The security risk from impersonated management stations is
significantly reduced by the use of a control plane. In particular,
where unsecure versions of network management protocols such as SNMP
versions 1 and 2 were popular configuration tools in transport
networks, the use of a control plane may significantly reduce the
security risk of malicious and false assignment of network resources
that could cause the interception or disruption of data traffic.
On the other hand, the control plane may increase the number of
security relationships that each network node must maintain. Instead
of a single security relationship with its management element, each
network node must now maintain a security relationship with each of
its signaling and routing neighbors in the control plane.
There is a strong requirement for signaling and control plane
exchanges to be secured, and any protocols proposed for this purpose
must be capable of secure message exchanges. This is already the
case for the existing GMPLS routing and signaling protocols.
8. Acknowledgements
We acknowledge all the participants of the MPLS and CCAMP WGs, whose
constant enquiry about GMPLS issues in TDM networks motivated the
writing of this document, and whose questions helped shape its
contents. Also, thanks to Kireeti Kompella for his careful reading
of the last version of this document, and for his helpful comments
and feedback, and to Dimitri Papadimitriou for his review on behalf
of the Routing Area Directorate, which provided many useful inputs to
help update the document to conform to the standards evolutions since
this document passed last call.
9. Informative References
In the ITU references below, please see http://www.itu.int for
availability of ITU documents. For ANSI references, please see the
Library available through http://www.ansi.org.
[1] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label
Switching Architecture", RFC 3031, January 2001.
[2] G.707, Network Node Interface for the Synchronous Digital
Hierarchy (SDH), International Telecommunication Union, March
1996.
[3] ANSI T1.105-1995, Synchronous Optical Network (SONET) Basic
Description including Multiplex Structure, Rates, and Formats,
American National Standards Institute.
[4] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description", RFC 3471, January 2003.
[5] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE) Extensions", RFC 3473, January 2003.
[6] Bernstein, G., Yates, J., Saha, D., "IP-Centric Control and
Management of Optical Transport Networks," IEEE Communications
Mag., Vol. 40, Issue 10, October 2000.
[7] ANSI T1.105.01-1995, Synchronous Optical Network (SONET)
Automatic Protection Switching, American National Standards
Institute.
[8] G.841, Types and Characteristics of SDH Network Protection
Architectures, ITU-T, July 1995.
[9] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4202, October 2005.
[10] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4203, October 2005.
[11] Kompella, K., Ed. and Y. Rekhter, Ed., "Intermediate System to
Intermediate System (IS-IS) Extensions in Support of Generalized
Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005.
[12] Bernstein, G., Sharma, V., Ong, L., "Inter-domain Optical
Routing," OSA J. of Optical Networking, vol. 1, no. 2, pp. 80-
92.
[13] Kompella, K., Rekhter, Y. and L. Berger, "Link Bundling in MPLS
Traffic Engineering (TE)", RFC 4201, October 2005.
[14] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[15] Mannie, E. and D. Papadimitriou, "Generalized Multi-Protocol
Label Switching (GMPLS) Extensions for Synchronous Optical
Network (SONET) and Synchronous Digital Hierarchy (SDH)
Control", RFC 3946, October 2004.
[16] G.7715.1, ASON Routing Architecture and Requirements for Link-
State Protocols, International Telecommunications Union,
February 2004.
[17] Bernstein, G., Rajagopalan, R., and Saha, D., "Optical Network
Control: Protocols, Architectures, and Standards," Addison-
Wesley, July 2003.
10. Acronyms
ANSI - American National Standards Institute
APS - Automatic Protection Switching
ATM - Asynchronous Transfer Mode
BLSR - Bi-directional Line Switch Ring
CPE - Customer Premise Equipment
DLCI - Data Link Connection Identifier
ETSI - European Telecommunication Standards Institute
FEC - Forwarding Equivalency Class
GMPLS - Generalized MPLS
IP - Internet Protocol
IS-IS - Intermediate System to Intermediate System (RP)
LDP - Label Distribution Protocol
LSP - Label Switched Path
LSR - Label Switching Router
MPLS - Multi-Protocol Label Switching
NMS - Network Management System
OSPF - Open Shortest Path First (RP)
PNNI - Private Network Node Interface
PPP - Point to Point Protocol
QoS - Quality of Service
RP - Routing Protocol
RSVP - ReSerVation Protocol
SDH - Synchronous Digital Hierarchy
SNMP - Simple Network Management Protocol
SONET - Synchronous Optical NETworking
SPE - SONET Payload Envelope
STM - Synchronous Transport Module (or Terminal Multiplexer)
STS - Synchronous Transport Signal
TDM - Time Division Multiplexer
TE - Traffic Engineering
TMN - Telecommunication Management Network
UPSR - Uni-directional Path Switch Ring
VC - Virtual Container (SDH) or Virtual Circuit
VCI - Virtual Circuit Identifier (ATM)
VPI - Virtual Path Identifier (ATM)
VT - Virtual Tributary
WDM - Wavelength-Division Multiplexing
Author’s Addresses
Greg Bernstein
Grotto Networking
Phone: +1 510 573-2237
EMail: gregb@grotto-networking.com
Eric Mannie
Perceval
Rue Tenbosch, 9
1000 Brussels
Belgium
Phone: +32-2-6409194
EMail: eric.mannie@perceval.net
Vishal Sharma
Metanoia, Inc.
888 Villa Street, Suite 500
Mountain View, CA 94041
Phone: +1 650 641 0082
Email: v.sharma@ieee.org
Eric Gray
Marconi Corporation, plc
900 Chelmsford Street
Lowell, MA 01851
USA
Phone: +1 978 275 7470
EMail: Eric.Gray@Marconi.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.