1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc4003.txt b/doc/rfc/rfc4003.txt
new file mode 100644
index 0000000..e768ef4
--- /dev/null
+++ b/doc/rfc/rfc4003.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                          L. Berger
+Request for Comments: 4003                                Movaz Networks
+Updates: 3473                                              February 2005
+Category: Standards Track
+
+
+              GMPLS Signaling Procedure for Egress Control
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document clarifies the procedures for the control of the label
+   used on an output/downstream interface of the egress node of a Label
+   Switched Path (LSP).  This control is also known as "Egress Control".
+   Support for Egress Control is implicit in Generalized Multi-Protocol
+   Label Switching (GMPLS) Signaling.  This document clarifies the
+   specification of GMPLS Signaling and does not modify GMPLS signaling
+   mechanisms and procedures.
+
+1.  Background
+
+   The ability to control the label used on the output/downstream
+   interface of an egress node was one of the early requirements for
+   GMPLS.  In the initial GMPLS documents, this was called "Egress
+   Control".  As the GMPLS documents progressed, the ability to control
+   a label on an egress interface was generalized to support control of
+   a label on any interface.  This generalization is seen in Section 6
+   of [RFC3471] and Section 5.1 of [RFC3473].  When this functionality
+   was generalized, the procedures to support control of a label at the
+   egress were also generalized.  Although the result was intended to
+   cover egress control, this intention is not clear to all.  This note
+   reiterates the procedures to cover control of a label used on an
+   egress output/downstream interface.
+
+
+
+
+
+
+
+Berger                      Standards Track                     [Page 1]
+
+RFC 4003      GMPLS Signaling Procedure for Egress Control February 2005
+
+
+   For context, the following is the text from the GMPLS signalling
+   document dated June 2000 about how ERO (Explicit Route Object) for
+   egress control:
+
+      6. Egress Control
+
+      The LSR at the head-end of an LSP can control the termination of
+      the LSP by using the ERO.  To terminate an LSP on a particular
+      outgoing interface of the egress LSR, the head-end may specify the
+      IP address of that interface as the last element in the ERO,
+      provided that interface has an associated IP address.
+
+      There are cases where the use of IP address doesn't provide enough
+      information to uniquely identify the egress termination.  One case
+      is when the outgoing interface on the egress LSR is a component
+      link of a link bundle.  Another case is when it is desirable to
+      "splice" two LSPs together, i.e., where the tail of the first LSP
+      would be "spliced" into the head of the second LSP.  This last
+      case is more likely to be used in the non-PSC classes of links.
+
+      6.2. Procedures
+
+      The Egress Label subobject may appear only as the last subobject
+      in the ERO/ER.  Appearance of this subobject anywhere else in the
+      ERO/ER is treated as a "Bad strict node" error.
+
+      During an LSP setup, when a node processing the ERO/RR performs
+      Next Hop selection finds that the second subobject is an Egress
+      Label Subobject, the node uses the information carried in this
+      subobject to determine the handling of the data received over that
+      LSP.  Specifically, if the Link ID field of the subobject is non
+      zero, then this field identifies a specific (outgoing) link of the
+      node that should be used for sending all the data received over
+      the LSP.  If the Label field of the subobject is not Implicit NULL
+      label, this field specifies the label that should be used as an
+      outgoing label on the data received over the LSP.
+
+      Procedures by which an LSR at the head-end of an LSP obtains the
+      information needed to construct the Egress Label subobject are
+      outside the scope of this document.
+
+2.  Egress Control Procedures
+
+   This section is intended to complement Sections 5.1.1 and 5.2.1 of
+   [RFC3473].  The procedures described in those sections are not
+   modified.  This section clarifies procedures related to the label
+   used on an egress output/downstream interface.
+
+
+
+
+Berger                      Standards Track                     [Page 2]
+
+RFC 4003      GMPLS Signaling Procedure for Egress Control February 2005
+
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.1.  ERO Procedures
+
+   Egress Control occurs when the node processing an ERO is the egress
+   and the ERO contains one or more subobjects related to the
+   output/downstream interface.  In this case, the outgoing/downstream
+   interface is indicated in the ERO as the last listed local interface.
+   Note that an interface may be numbered or unnumbered.
+
+   To support Egress Control, an egress checks to see whether the
+   received ERO contains an outgoing/downstream interface.  If it does,
+   the type of the subobject or subobjects following the interface is
+   examined.  If the associated LSP is unidirectional, one subobject is
+   examined.  Two subobjects are examined for bidirectional LSPs.  If
+   the U-bit of the subobject being examined is clear (0), then the
+   value of the label MUST be used for transmitting traffic associated
+   with the LSP on the indicated outgoing/downstream interface.
+
+   If the U-bit of the subobject being examined is set (1), then the
+   value of the label is used for upstream traffic associated with the
+   bidirectional LSP.  Specifically, the label value will be used for
+   the traffic associated with the LSP that will be received on the
+   indicated outgoing/downstream interface.
+
+   Per [RFC3473], any errors encountered while processing the ERO,
+   including if the listed label(s) are not acceptable or cannot be
+   supported in forwarding, SHOULD result in the generation of a PathErr
+   message with the error code "Routing Error" and error value of "Bad
+   Explicit Route Object".
+
+2.2.  RRO Procedures
+
+   If an ERO is used to specify outgoing interface information at the
+   egress and label recording is indicated for the LSP, the egress
+   should include the specified interface information and the specified
+   label or labels in the corresponding RRO (Route Record Object).
+
+3.  Security Considerations
+
+   This document clarifies procedures defined in [RFC3473] but does not
+   define any new procedures.  As such, no new security considerations
+   are introduced.
+
+
+
+
+
+
+Berger                      Standards Track                     [Page 3]
+
+RFC 4003      GMPLS Signaling Procedure for Egress Control February 2005
+
+
+4.  Acknowledgments
+
+   Valuable comments and input were received from Adrian Farrel, Alan
+   Kullberg, and Dimitri Papadimitriou.
+
+5.  Normative References
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
+             (GMPLS) Signaling Functional Description", RFC 3471,
+             January 2003.
+
+   [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
+             (GMPLS) Signaling Resource ReserVation Protocol-Traffic
+             Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
+
+Author'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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berger                      Standards Track                     [Page 4]
+
+RFC 4003      GMPLS Signaling Procedure for Egress Control February 2005
+
+
+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 IETF's procedures with respect to rights in IETF 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.
+
+
+
+
+
+
+Berger                      Standards Track                     [Page 5]
+