doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc4203.txt b/doc/rfc/rfc4203.txt
new file mode 100644
index 0000000..c6e8269
--- /dev/null
+++ b/doc/rfc/rfc4203.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                   K. Kompella, Ed.
+Request for Comments: 4203                               Y. Rekhter, Ed.
+Updates: 3630                                           Juniper Networks
+Category: Standards Track                                   October 2005
+
+
+                     OSPF Extensions in Support of
+           Generalized Multi-Protocol Label Switching (GMPLS)
+
+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 specifies encoding of extensions to the OSPF routing
+   protocol in support of Generalized Multi-Protocol Label Switching
+   (GMPLS).
+
+1.  Introduction
+
+   This document specifies extensions to the OSPF routing protocol
+   [OSPF] in support of carrying link state information for Generalized
+   Multi-Protocol Label Switching (GMPLS).  The set of required
+   enhancements to OSPF are outlined in [GMPLS-ROUTING].
+
+   In this section, we define the enhancements to the Traffic
+   Engineering (TE) properties of GMPLS TE links that can be announced
+   in OSPF TE LSAs.  The TE LSA, which is an opaque LSA with area
+   flooding scope [OSPF-TE], has only one top-level Type/Length/Value
+   (TLV) triplet and has one or more nested sub-TLVs for extensibility.
+   The top-level TLV can take one of two values (1) Router Address or
+   (2) Link.  In this document, we enhance the sub-TLVs for the Link TLV
+   in support of GMPLS.  Specifically, we add the following sub-TLVs to
+   the Link TLV:
+
+
+
+
+
+
+
+
+Kompella & Rekhter          Standards Track                     [Page 1]
+
+RFC 4203                OSPF Extensions in MPLS             October 2005
+
+
+   Sub-TLV Type      Length    Name
+             11           8    Link Local/Remote Identifiers
+             14           4    Link Protection Type
+             15    variable    Interface Switching Capability Descriptor
+             16    variable    Shared Risk Link Group
+
+   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 BCP 14, RFC 2119
+   [RFC2119].
+
+1.1.  Link Local/Remote Identifiers
+
+   Link Local/Remote Identifiers is a sub-TLV of the Link TLV.  The type
+   of this sub-TLV is 11, and length is eight octets.  The value field
+   of this sub-TLV contains four octets of Link Local Identifier
+   followed by four octets of Link Remote Identifier (see Section
+   "Support for unnumbered links" of [GMPLS-ROUTING]).  If the Link
+   Remote Identifier is unknown, it is set to 0.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                  Link Local Identifier                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                  Link Remote Identifier                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   A node can communicate its Link Local Identifier to its neighbor
+   using a link local Opaque LSA, as described in Section "Exchanging
+   Link Local TE Information".
+
+1.2.  Link Protection Type
+
+   The Link Protection Type is a sub-TLV of the Link TLV.  The type of
+   this sub-TLV is 14, and length is four octets.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |Protection Cap |                    Reserved                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The first octet is a bit vector describing the protection
+   capabilities of the link (see Section "Link Protection Type" of
+   [GMPLS-ROUTING]).  They are:
+
+      0x01  Extra Traffic
+
+
+
+Kompella & Rekhter          Standards Track                     [Page 2]
+
+RFC 4203                OSPF Extensions in MPLS             October 2005
+
+
+      0x02  Unprotected
+
+      0x04  Shared
+
+      0x08  Dedicated 1:1
+
+      0x10  Dedicated 1+1
+
+      0x20  Enhanced
+
+      0x40  Reserved
+
+      0x80  Reserved
+
+   The remaining three octets SHOULD be set to zero by the sender, and
+   SHOULD be ignored by the receiver.
+
+   The Link Protection Type sub-TLV may occur at most once within the
+   Link TLV.
+
+1.3.  Shared Risk Link Group (SRLG)
+
+   The SRLG is a sub-TLV (of type 16) of the Link TLV.  The length is
+   the length of the list in octets.  The value is an unordered list of
+   32 bit numbers that are the SRLGs that the link belongs to.  The
+   format of the value field is as shown below:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                  Shared Risk Link Group Value                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        ............                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                  Shared Risk Link Group Value                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   This sub-TLV carries the Shared Risk Link Group information (see
+   Section "Shared Risk Link Group Information" of [GMPLS-ROUTING]).
+
+   The SRLG sub-TLV may occur at most once within the Link TLV.
+
+1.4.  Interface Switching Capability Descriptor
+
+   The Interface Switching Capability Descriptor is a sub-TLV (of type
+   15) of the Link TLV.  The length is the length of value field in
+   octets.  The format of the value field is as shown below:
+
+
+
+
+Kompella & Rekhter          Standards Track                     [Page 3]
+
+RFC 4203                OSPF Extensions in MPLS             October 2005
+
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Switching Cap |   Encoding    |           Reserved            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                  Max LSP Bandwidth at priority 0              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                  Max LSP Bandwidth at priority 1              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                  Max LSP Bandwidth at priority 2              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                  Max LSP Bandwidth at priority 3              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                  Max LSP Bandwidth at priority 4              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                  Max LSP Bandwidth at priority 5              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                  Max LSP Bandwidth at priority 6              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                  Max LSP Bandwidth at priority 7              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |        Switching Capability-specific information              |
+   |                  (variable)                                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The Switching Capability (Switching Cap) field contains one of the
+   following values:
+
+      1     Packet-Switch Capable-1 (PSC-1)
+      2     Packet-Switch Capable-2 (PSC-2)
+      3     Packet-Switch Capable-3 (PSC-3)
+      4     Packet-Switch Capable-4 (PSC-4)
+      51    Layer-2 Switch Capable  (L2SC)
+      100   Time-Division-Multiplex Capable (TDM)
+      150   Lambda-Switch Capable   (LSC)
+      200   Fiber-Switch Capable    (FSC)
+
+   The Encoding field contains one of the values specified in Section
+   3.1.1 of [GMPLS-SIG].
+
+   Maximum LSP Bandwidth is encoded as a list of eight 4 octet fields in
+   the IEEE floating point format [IEEE], with priority 0 first and
+   priority 7 last.  The units are bytes (not bits!) per second.
+
+   The content of the Switching Capability specific information field
+   depends on the value of the Switching Capability field.
+
+
+
+
+
+Kompella & Rekhter          Standards Track                     [Page 4]
+
+RFC 4203                OSPF Extensions in MPLS             October 2005
+
+
+   When the Switching Capability field is PSC-1, PSC-2, PSC-3, or PSC-4,
+   the Switching Capability specific information field includes Minimum
+   LSP Bandwidth, Interface MTU, and padding.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                  Minimum LSP Bandwidth                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Interface MTU       |            Padding            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The Minimum LSP Bandwidth is encoded in a 4 octets field in the IEEE
+   floating point format.  The units are bytes (not bits!) per second.
+   The Interface MTU is encoded as a 2 octets integer.  The padding is 2
+   octets, and is used to make the Interface Switching Capability
+   Descriptor sub-TLV 32-bits aligned.  It SHOULD be set to zero by the
+   sender and SHOULD be ignored by the receiver.
+
+   When the Switching Capability field is L2SC, there is no Switching
+   Capability specific information field present.
+
+   When the Switching Capability field is TDM, the Switching Capability
+   specific information field includes Minimum LSP Bandwidth, an
+   indication whether the interface supports Standard or Arbitrary
+   SONET/SDH, and padding.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                  Minimum LSP Bandwidth                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   Indication  |                 Padding                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The Minimum LSP Bandwidth is encoded in a 4 octets field in the IEEE
+   floating point format.  The units are bytes (not bits!) per second.
+   The indication whether the interface supports Standard or Arbitrary
+   SONET/SDH is encoded as 1 octet.  The value of this octet is 0 if the
+   interface supports Standard SONET/SDH, and 1 if the interface
+   supports Arbitrary SONET/SDH.  The padding is 3 octets, and is used
+   to make the Interface Switching Capability Descriptor sub-TLV 32-bits
+   aligned.  It SHOULD be set to zero by the sender and SHOULD be
+   ignored by the receiver.
+
+   When the Switching Capability field is LSC, there is no Switching
+   Capability specific information field present.
+
+
+
+
+Kompella & Rekhter          Standards Track                     [Page 5]
+
+RFC 4203                OSPF Extensions in MPLS             October 2005
+
+
+   To support interfaces that have more than one Interface Switching
+   Capability Descriptor (see Section "Interface Switching Capability
+   Descriptor" of [GMPLS-ROUTING]) the Interface Switching Capability
+   Descriptor sub-TLV may occur more than once within the Link TLV.
+
+2.  Implications on Graceful Restart
+
+   The restarting node should follow the OSPF restart procedures
+   [OSPF-RESTART], and the RSVP-TE restart procedures [GMPLS-RSVP].
+
+   When a restarting node is going to originate its TE LSAs, the TE LSAs
+   containing Link TLV should be originated with 0 unreserved bandwidth,
+   Traffic Engineering metric set to 0xffffffff, and if the Link has LSC
+   or FSC as its Switching Capability then also with 0 as Max LSP
+   Bandwidth, until the node is able to determine the amount of
+   unreserved resources taking into account the resources reserved by
+   the already established LSPs that have been preserved across the
+   restart.  Once the restarting node determines the amount of
+   unreserved resources, taking into account the resources reserved by
+   the already established LSPs that have been preserved across the
+   restart, the node should advertise these resources in its TE LSAs.
+
+   In addition in the case of a planned restart prior to restarting, the
+   restarting node SHOULD originate the TE LSAs containing Link TLV with
+   0 as unreserved bandwidth, and if the Link has LSC or FSC as its
+   Switching Capability then also with 0 as Max LSP Bandwidth.  This
+   would discourage new LSP establishment through the restarting router.
+
+   Neighbors of the restarting node should continue advertise the actual
+   unreserved bandwidth on the TE links from the neighbors to that node.
+
+   Regular graceful restart should not be aborted if a TE LSA or TE
+   topology changes.  TE graceful restart need not be aborted if a TE
+   LSA or TE topology changes.
+
+3.  Exchanging Link Local TE Information
+
+   It is often useful for a node to communicate some Traffic Engineering
+   information for a given interface to its neighbors on that interface.
+   One example of this is a Link Local Identifier.  If nodes X and Y are
+   connected by an unnumbered point-to-point interface I, then X's Link
+   Local Identifier for I is Y's Link Remote Identifier for I.  X can
+   communicate its Link Local Identifier for I by exchanging with Y a TE
+   link local opaque LSA described below.  Note that this information
+   need only be exchanged over interface I, hence the use of a link
+   local Opaque LSA.
+
+
+
+
+
+Kompella & Rekhter          Standards Track                     [Page 6]
+
+RFC 4203                OSPF Extensions in MPLS             October 2005
+
+
+   A TE Link Local LSA is an opaque LSA of type 9 (link-local flooding
+   scope) with Opaque Type 1 (TE LSA) and Opaque ID of 0.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |            LS age             |    Options    |       9       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Opaque Type  |                   Opaque ID                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Advertising Router                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     LS sequence number                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         LS checksum           |             length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   +-                            TLVs                             -+
+   |                             ...                               |
+
+   The format of the TLVs that make up the body of the TE Link Local LSA
+   is the same as that of the TE TLVs: a 2-octet Type field followed by
+   a 2-octet Length field which indicates the length of the Value field
+   in octets.  The Top Level Type for the Link Local TLV is 4.  The
+   Value field is zero-padded at the end to a four octet boundary.
+
+   The only TLV defined here is the Link Local Identifier TLV, with Type
+   1, Length 4 and Value the 32 bit Link Local Identifier for the link
+   over which the TE Link Local LSA is exchanged.
+
+4.  Contributors
+
+   Ayan Banerjee
+   Calient Networks
+   5853 Rue Ferrari
+   San Jose, CA 95138
+
+   Phone: +1.408.972.3645
+   EMail: abanerjee@calient.net
+
+   John Drake
+   Calient Networks
+   5853 Rue Ferrari
+   San Jose, CA 95138
+
+   Phone: +1.408.972.3720
+   EMail: jdrake@calient.net
+
+
+
+
+Kompella & Rekhter          Standards Track                     [Page 7]
+
+RFC 4203                OSPF Extensions in MPLS             October 2005
+
+
+   Greg Bernstein
+   Ciena Corporation
+   10480 Ridgeview Court
+   Cupertino, CA 94014
+
+   Phone: +1.408.366.4713
+   EMail: greg@ciena.com
+
+   Don Fedyk
+   Nortel Networks Corp.
+   600 Technology Park Drive
+   Billerica, MA 01821
+
+   Phone: +1.978.288.4506
+   EMail: dwfedyk@nortelnetworks.com
+
+   Eric Mannie
+   Independent Consultant
+
+   EMail: eric_mannie@hotmail.com
+
+   Debanjan Saha
+   Tellium Optical Systems
+   2 Crescent Place
+   P.O. Box 901
+   Ocean Port, NJ 07757
+
+   Phone: +1.732.923.4264
+   EMail: dsaha@tellium.com
+
+   Vishal Sharma
+   Metanoia, Inc.
+   335 Elan Village Lane, Unit 203
+   San Jose, CA 95134-2539
+
+   Phone: +1.408.943.1794
+   EMail: v.sharma@ieee.org
+
+5.  Acknowledgements
+
+   The authors would like to thank Suresh Katukam, Jonathan Lang,
+   Quaizar Vohra, and Alex Zinin for their comments on the document.
+
+
+
+
+
+
+
+
+
+Kompella & Rekhter          Standards Track                     [Page 8]
+
+RFC 4203                OSPF Extensions in MPLS             October 2005
+
+
+6.  Security Considerations
+
+   This document specifies the contents of Opaque LSAs in OSPFv2.  As
+   Opaque LSAs are not used for SPF computation or normal routing, the
+   extensions specified here have no direct effect on IP routing.
+   Tampering with GMPLS TE LSAs may have an effect on the underlying
+   transport (optical and/or SONET-SDH) network.  [OSPF-TE] suggests
+   mechanisms such as [OSPF-SIG] to protect the transmission of this
+   information, and those or other mechanisms should be used to secure
+   and/or authenticate the information carried in the Opaque LSAs.
+
+7.  IANA Considerations
+
+   The memo introduces four new sub-TLVs of the TE Link TLV in the TE
+   Opaque LSA for OSPF v2; [OSPF-TE] says that the sub-TLVs of the TE
+   Link TLV in the range 10-32767 must be assigned by Expert Review, and
+   must be registered with IANA.
+
+   The memo has four suggested values for the four sub-TLVs of the TE
+   Link TLV; it is strongly recommended that the suggested values be
+   granted, as there are interoperable implementations using these
+   values.
+
+   Finally, a new Top Level Type for OSPF TE LSAs for the Link Local TLV
+   has been allocated from the Standards Action space.
+
+8.  References
+
+8.1.  Normative References
+
+   [GMPLS-ROUTING] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
+                   Extensions in Support of Generalized Multi-Protocol
+                   Label Switching (GMPLS)", RFC 4202, October 2005.
+
+   [GMPLS-RSVP]    Berger, L., "Generalized Multi-Protocol Label
+                   Switching (GMPLS) Signaling Resource ReserVation
+                   Protocol-Traffic Engineering (RSVP-TE) Extensions",
+                   RFC 3473, January 2003.
+
+   [GMPLS-SIG]     Berger, L., "Generalized Multi-Protocol Label
+                   Switching (GMPLS) Signaling Functional Description",
+                   RFC 3471, January 2003.
+
+   [IEEE]          IEEE, "IEEE Standard for Binary Floating-Point
+                   Arithmetic", Standard 754-1985, 1985 (ISBN 1-5593-
+                   7653-8).
+
+
+
+
+
+Kompella & Rekhter          Standards Track                     [Page 9]
+
+RFC 4203                OSPF Extensions in MPLS             October 2005
+
+
+   [OSPF]          Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
+                   1998.
+
+   [OSPF-RESTART]  Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful
+                   OSPF Restart", RFC 3623, November 2003.
+
+   [OSPF-SIG]      Murphy, S., Badger, M., and B. Wellington, "OSPF with
+                   Digital Signatures", RFC 2154, June 1997.
+
+   [OSPF-TE]       Katz, D., Kompella, K., and Yeung, D., "Traffic
+                   Engineering (TE) Extensions to OSPF Version 2", RFC
+                   3630, September 2003.
+
+   [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
+                   Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+Authors' Addresses
+
+   Kireeti Kompella
+   Juniper Networks, Inc.
+   1194 N. Mathilda Ave
+   Sunnyvale, CA 94089
+
+   EMail: kireeti@juniper.net
+
+
+   Yakov Rekhter
+   Juniper Networks, Inc.
+   1194 N. Mathilda Ave
+   Sunnyvale, CA 94089
+
+   EMail: yakov@juniper.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kompella & Rekhter          Standards Track                    [Page 10]
+
+RFC 4203                OSPF Extensions in MPLS             October 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 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.
+
+
+
+
+
+
+
+Kompella & Rekhter          Standards Track                    [Page 11]
+