protocol such as [LMP]). In all cases the choice of the data
interface is indicated by the upstream node using addresses and
identifiers used by the upstream node.
9.1.1. Required Information
The following information is carried in Interface_ID:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where each TLV has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: 16 bits
Indicates the total length of the TLV, i.e., 4 + the length of
the value field in octets. A value field whose length is not a
multiple of four MUST be zero-padded so that the TLV is four-
octet aligned.
Type: 16 bits
Indicates type of interface being identified. Defined values
are:
Type Length Format Description
--------------------------------------------------------------------
1 8 IPv4 Addr. IPv4
2 20 IPv6 Addr. IPv6
3 12 See below IF_INDEX (Interface Index)
4 12 See below COMPONENT_IF_DOWNSTREAM (Component interface)
5 12 See below COMPONENT_IF_UPSTREAM (Component interface)
For types 3, 4 and 5 the Value field has the format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Address: 32 bits
The IP address field may carry either an IP address of a link
or an IP address associated with the router, where associated
address is the value carried in a router address TLV of
routing.
Interface ID: 32 bits
For type 3 usage, the Interface ID carries an interface
identifier.
For types 4 and 5, the Interface ID indicates a bundled
component link. The special value 0xFFFFFFFF can be used to
indicate the same label is to be valid across all component
links.
9.2. Fault Handling
There are two new faults that must be handled when the control
channel is independent of the data channel. In the first, there is a
link or other type of failure that limits the ability of neighboring
nodes to pass control messages. In this situation, neighboring nodes
are unable to exchange control messages for a period of time. Once
communication is restored the underlying signaling protocol must
indicate that the nodes have maintained their state through the
failure. The signaling protocol must also ensure that any state
changes that were instantiated during the failure are synchronized
between the nodes.
In the second, a node's control plane fails and then restarts and
losses most of its state information. In this case, both upstream
and downstream nodes must synchronize their state information with
the restarted node. In order for any resynchronization to occur the
node undergoing the restart will need to preserve some information,
such as its mappings of incoming to outgoing labels.
Both cases are addressed in protocol specific fashions, see [RFC3473]
and [RFC3472].
Note that these cases only apply when there are mechanisms to detect
data channel failures independent of control channel failures.
10. Acknowledgments
This document is the work of numerous authors and consists of a
composition of a number of previous documents in this area.
Valuable comments and input were received from a number of people,
including Igor Bryskin, Adrian Farrel, Ben Mack-Crane, Dimitri
Papadimitriou, Fong Liaw and Juergen Heiles. Some sections of this
document are based on text proposed by Fong Liaw.
11. Security Considerations
This document introduce no new security considerations to either
[RFC3212] or [RFC3209]. The security considerations mentioned in
[RFC3212] or [RFC3209] apply to the respective protocol specific
forms of GMPLS, see [RFC3473] and [RFC3472].
12. IANA Considerations
The IANA will administer assignment of new values for namespaces
defined in this document. This section uses the terminology of BCP
26 "Guidelines for Writing an IANA Considerations Section in RFCs"
[BCP26].
This document defines the following namespaces:
o LSP Encoding Type: 8 bits
o Switching Type: 8 bits
o Generalized PID (G-PID): 16 bits
o Action: 8 bits
o Interface_ID Type: 16 bits
All future assignments should be allocated through IETF Consensus
action or documented in a Specification.
LSP Encoding Type - valid value range is 1-255. This document
defines values 1-11.
Switching Type - valid value range is 1-255. This document defines
values 1-4, 100, 150 and 200.
Generalized PID (G-PID) - valid value range is 0-1500. This document
defines values 0-46.
Action - valid value range is 0-255. This document defines values
0-3.
Interface_ID Type - valid value range is 1-65535. This document
defines values 1-5.
13. Intellectual Property Considerations
This section is taken from Section 10.4 of [RFC2026].
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, RFC2119, March 1997.
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A.
and B. Thomas, "LDP Specification", RFC3036,
January 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,
Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions
to RSVP for LSP Tunnels", RFC3209, December 2001.
[RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R.,
Wu, L., Doolan, P., Worster, T., Feldman, N.,
Fredette, A., Girish, M., Gray, E., Heinanen, J.,
Kilty, T. and A. Malis, "Constraint-Based LSP Setup
using LDP", RFC3212, January 2002.
[RFC3472] Ashwood-Smith, P. and L. Berger, Editors,
"Generalized Multi-Protocol Label Switching (GMPLS)
Signaling - Constraint-based Routed Label
Distribution Protocol (CR-LDP) Extensions", RFC
3472, January 2003.
[RFC3473] Berger, L., Editor "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling - Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC3473, January 2003.
14.2. Informative References
[GMPLS-RTG] Kompella, K., et al., "Routing Extensions in Support
of Generalized MPLS", Work in Progress.
[GMPLS-SONET] Ashwood-Smith, P., et al., "GMPLS - SONET / SDH
Specifics", Work in Progress.
[LMP] Lang, et al., "Link Management Protocol", Work in
Progress.
[MPLS-BUNDLE] Kompella, K., Rekhter, Y. and L. Berger, "Link
Bundling in MPLS Traffic Engineering", Work in
Progress.
[MPLS-HIERARCHY] Kompella, K. and Y. Rekhter, "LSP Hierarchy with
MPLS TE", Work in Progress.
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3," BCP 9, RFC2026, October 1996.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP
26, RFC2434, October 1998.
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon,
"Multiprotocol label switching Architecture", RFC
3031, January 2001.
15. Contributors
Peter Ashwood-Smith
Nortel Networks Corp.
P.O. Box 3511 Station C,
Ottawa, ON K1Y 4H7
Canada
Phone: +1 613 763 4534
EMail: petera@nortelnetworks.com
Ayan Banerjee
Calient Networks
5853 Rue Ferrari
San Jose, CA 95138
Phone: +1 408 972-3645
EMail: abanerjee@calient.net
Lou Berger
Movaz Networks, Inc.
7926 Jones Branch Drive
Suite 615
McLean VA, 22102
Phone: +1 703 847-1801
EMail: lberger@movaz.com
Greg Bernstein
EMail: gregb@grotto-networking.com
John Drake
Calient Networks
5853 Rue Ferrari
San Jose, CA 95138
Phone: +1 408 972 3720
EMail: jdrake@calient.net
Yanhe Fan
Axiowave Networks, Inc.
200 Nickerson Road
Marlborough, MA 01752
Phone: + 1 774 348 4627
EMail: yfan@axiowave.com
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
EMail: kireeti@juniper.net
Jonathan P. Lang
EMail: jplang@ieee.org
Eric Mannie
Independent Consultant
2 Avenue de la Folle Chanson
1050 Brussels
Belgium
EMail: eric_mannie@hotmail.com
Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Phone: +1 732 923 4237
Fax: +1 732 923 9804
EMail: braja@tellium.com
Yakov Rekhter
Juniper Networks, Inc.
EMail: yakov@juniper.net
Debanjan Saha
EMail: debanjan@acm.org
Vishal Sharma
Metanoia, Inc.
1600 Villa Street, Unit 352
Mountain View, CA 94041-1174
Phone: +1 650-386-6723
EMail: v.sharma@ieee.org
George Swallow
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
Phone: +1 978 244 8143
EMail: swallow@cisco.com
Z. Bo Tang
EMail: botang01@yahoo.com
16. Editor's Address
Lou Berger
Movaz Networks, Inc.
7926 Jones Branch Drive
Suite 615
McLean VA, 22102
Phone: +1 703 847-1801
EMail: lberger@movaz.com
17. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.