The ITU term for an H-LSP is trail.
3.10. TE Domains
3.10.1 GMPLS Terms
TE link attribute is a parameter of the set of resources associated
with a TE link end that is significant in the context of path
computation.
Full TE visibility is a situation when a controller receives all
unmodified TE advertisements from every other controller in a
particular set of controllers.
Limited TE visibility is a situation when a controller receives
summarized TE information, or does not receive TE advertisements
from at least one of a particular set of controllers.
TE domain is a set of controllers each of which has full TE
visibility within the set.
TE database (TED) is a memory structure within a controller that
contains all TE advertisements generated by all controllers within
a particular TE domain.
Vertical network integration is a set of control plane mechanisms and
coordinated data plane mechanisms that span multiple layers. The
control plane mechanisms exist on one or more controllers and
operate either within a single control plane instance or between
control plane instances. The data plane mechanisms consist of
collaboration and adaptation between layers within a single
transport node.
Horizontal network integration is a set of control plane mechanisms
and coordinated data plane mechanisms that span multiple TE
domains within the same layer. The control plane mechanisms exist
on one or more controllers and operate either within a single
control plane instance or between control plane instances. The
data plane mechanisms consist of collaboration between TE domains.
3.11. Component Links and Bundles
3.11.1. GMPLS Terms
Component link end <Control Plane> is a grouping of resources of a
particular layer that is not advertised as an individual TE link
end. A component link end could represent one or more data link
ends or any subset of resources that belong to one or more data
link ends.
Component link <Control Plane> is a grouping of two or more component
link ends associated with neighboring transport nodes (that is,
directly interconnected by one or more data links) in a particular
layer. Component links are equivalent to TE links except that the
component link ends are not advertised separately.
TE bundle <Control Plane> is an association of several parallel (that
is, connecting the same pair of transport nodes) component links
whose attributes are identical or whose differences are
sufficiently negligible that the TE domain can view the entire
association as a single TE link. A TE bundle is advertised in the
same way as a TE link, that is, by representing the associated
component link ends as a single TE link end (TE bundle end) which
is advertised.
3.12. Regions
3.12.1. GMPLS Terms
TE region <Control Plane> is a set of one or more layers that are
associated with the same type of data plane technology. A TE
region is sometimes called an LSP region or just a region.
Examples of regions are: IP, ATM, TDM, photonic, fiber switching,
etc. Regions and region boundaries are significant for the
signaling sub-system of the control plane because LSPs are
signaled substantially differently (i.e., use different signaling
object formats and semantics) in different regions. Furthermore,
advertising, routing, and path computation could be performed
differently in different regions. For example, computation of
paths across photonic regions requires a wider set of constraints
(e.g., optical impairments, wavelength continuity, etc) and needs
to be performed in different terms (e.g., in terms of individual
resources -- lambda channels, rather than in terms of TE links)
compared to path computation in other regions like IP or TDM.
4. Guidance on the Application of this Lexicography
As discussed in the introduction to this document, this lexicography
is intended to bring the concepts and terms associated with GMPLS
into the context of the ITU-T’s ASON architecture. Thus, it should
help those familiar with ASON to see how they may use the features
and functions of GMPLS in order to meet the requirements of an ASON.
For example, service providers wishing to establish a protected end-
to-end service might read [SEG-PROT] and [E2E-PROT] and wish to
understand how the GMPLS terms used relate to the ASON architecture
so that they can confirm that they will satisfy their requirements.
This lexicography should not be used in order to obtain or derive
definitive definitions of GMPLS terms. To obtain definitions of
GMPLS terms that are applicable across all GMPLS architectural
models, the reader should refer to the RFCs listed in the references
sections of this document. [RFC3945] provides an overview of the
GMPLS architecture and should be read first.
5. Management Considerations
Both GMPLS and ASON networks require management. Both GMPLS and ASON
specifications include considerable efforts to provide operator
control and monitoring, as well as Operations and Management (OAM)
functionality.
These concepts are, however, out of scope of this document.
6. Security Considerations
Security is also a significant requirement of both GMPLS and ASON
architectures.
Again, however, this informational document is intended only to
provide a lexicography, and the security concerns are, therefore, out
of scope.
7. Acknowledgements
The authors would like to thank participants in the IETF’s CCAMP
working group and the ITU-T’s Study Group 15 for their help in
producing this document. In particular, all those who attended the
Study Group 15 Question 14 Interim Meeting in Holmdel, New Jersey
during January 2005. Further thanks to all participants of Study
Group 15 Questions 12 and 14 who have provided valuable discussion,
feedback and suggested text.
Many thanks to Ichiro Inoue for his useful review and input, and to
Scott Brim and Dimitri Papadimitriou for lengthy and constructive
discussions. Ben Mack-Crane and Jonathan Sadler provided very
helpful reviews and discussions of ASON terms. Thanks to Deborah
Brungard and Kohei Shiomoto for additional review comments.
8. Normative References
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, October
2004.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link
Bundling in MPLS Traffic Engineering (TE)", RFC
4201, October 2005.
[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in
Support of Generalized Multi-Protocol Label
Switching (GMPLS)", RFC 4202, October 2005.
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC
4204, October 2005.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths
(LSP) Hierarchy with Generalized Multi-Protocol
Label Switching (GMPLS) Traffic Engineering (TE)",
RFC 4206, October 2005.
9. Informative References
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
RFC 3471, January 2003.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
RFC 3471, January 2003.
[RFC4139] Papadimitriou, D., Drake, J., Ash, J., Farrel, A.,
and L. Ong, "Requirements for Generalized MPLS
(GMPLS) Signaling Usage and Extensions for
Automatically Switched Optical Network (ASON)", RFC
4139, July 2005.
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF
Extensions in Support of Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4205] 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.
[RFC4258] Brungard, D., Ed., "Requirements for Generalized
Multi-Protocol Label Switching (GMPLS) Routing for
the Automatically Switched Optical Network (ASON)",
RFC 4258, November 2005.
[RFC4394] Fedyk, D., Aboul-Magd, O., Brungard, D., Lang, J.,
and D. Papadimitriou, "A Transport Network View of
the Link Management Protocol (LMP)", RFC 4394,
February 2006.
[E2E-PROT] Lang, J., Ed., Rekhter, Y., Ed., and D.
Papadimitriou, D., Ed., "RSVP-TE Extensions in
support of End-to-End Generalized Multi-Protocol
Label Switching (GMPLS)-based Recovery", Work in
Progress, April 2005.
[SEG-PROT] Berger, L., Bryskin, I., Papadimitriou, D., and A.
Farrel, "GMPLS Based Segment Recovery", Work in
Progress, May 2005.
For information on the availability of the following documents,
please see http://www.itu.int.
[G-8080] ITU-T Recommendation G.8080/Y.1304, Architecture for
the automatically switched optical network (ASON).
[G-805] ITU-T Recommendation G.805 (2000), Generic
functional architecture of transport networks.
[G-807] ITU-T Recommendation G.807/Y.1302 (2001),
Requirements for the automatic switched transport
network (ASTN).
[G-872] ITU-T Recommendation G.872 (2001), Architecture of
optical transport networks.
[G-8081] ITU-T Recommendation G.8081 (2004), Terms and
definitions for Automatically Switched Optical
Networks (ASON).
[G-7713] ITU-T Recommendation G.7713 (2001), Distributed Call
and Connection Management.
[G-7714] ITU-T Recommendation G.7714 Revision (2005),
Generalized automatic discovery techniques.
[G-7715] ITU-T Recommendation G.7715 (2002), Architecture and
Requirements for the Automatically Switched Optical
Network (ASON).
Authors’ Addresses
Igor Bryskin
Independent Consultant
EMail: i_bryskin@yahoo.com
Adrian Farrel
Old Dog Consulting
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 provided by the IETF
Administrative Support Activity (IASA).