doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc5329.txt b/doc/rfc/rfc5329.txt
new file mode 100644
index 0000000..ce4567d
--- /dev/null
+++ b/doc/rfc/rfc5329.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                        K. Ishiguro
+Request for Comments: 5329                                     V. Manral
+Category: Standards Track                               IP Infusion, Inc
+                                                                A. Davey
+                                                 Data Connection Limited
+                                                          A. Lindem, Ed.
+                                                        Redback Networks
+                                                          September 2008
+
+
+            Traffic Engineering Extensions to OSPF Version 3
+
+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 IETF Trust (2008).
+
+Abstract
+
+   This document describes extensions to OSPFv3 to support intra-area
+   Traffic Engineering (TE).  This document extends OSPFv2 TE to handle
+   IPv6 networks.  A new TLV and several new sub-TLVs are defined to
+   support IPv6 networks.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ishiguro, et al.            Standards Track                     [Page 1]
+
+RFC 5329               OSPFv3-Traffic Engineering         September 2008
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Requirements Notation ......................................2
+   2. Intra-Area-TE-LSA ...............................................3
+      2.1. Intra-Area-TE-LSA Payload ..................................4
+   3. Router IPv6 Address TLV .........................................4
+   4. Link TLV ........................................................5
+      4.1. Link ID Sub-TLV ............................................6
+      4.2. Neighbor ID Sub-TLV ........................................6
+      4.3. Local Interface IPv6 Address Sub-TLV .......................6
+      4.4. Remote Interface IPv6 Address Sub-TLV ......................7
+   5. Security Considerations .........................................8
+   6. Management Considerations .......................................8
+   7. IANA Considerations .............................................9
+   8. References ......................................................9
+      8.1. Normative References .......................................9
+      8.2. Informative References ....................................10
+   Acknowledgments ...................................................10
+
+1.  Introduction
+
+   OSPFv3 has a very flexible mechanism for adding new LS types.
+   Unknown LS types are flooded properly based on the flooding scope
+   bits in the LS type [OSPFV3].  This document defines the Intra-Area-
+   TE-LSA to OSPFv3.
+
+   For Traffic Engineering, this document uses "Traffic Engineering
+   Extensions to OSPF" [TE] as a base for TLV definitions.  New TLVs and
+   sub-TLVs are added to [TE] to extend TE capabilities to IPv6
+   networks.  Some existing TLVs and sub-TLVs require clarification for
+   OSPFv3 applicability.
+
+   GMPLS [GMPLS] and the Diff-Serv MPLS extensions [TE-DIFF] are based
+   on [TE].  These functions can also be extended to OSPFv3 by utilizing
+   the TLVs and sub-TLVs described in this document.
+
+1.1.  Requirements Notation
+
+   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 RFC 2119
+   [RFC-KEYWORDS].
+
+
+
+
+
+
+
+
+Ishiguro, et al.            Standards Track                     [Page 2]
+
+RFC 5329               OSPFv3-Traffic Engineering         September 2008
+
+
+2.  Intra-Area-TE-LSA
+
+   A new LS type is defined for the Intra-Area-TE-LSA.  This is
+   different from OSPFv2 Traffic Engineering [TE] where opaque LSAs are
+   used to advertise TE information [OPAQUE].  The LSA function code is
+   10, the U-bit is set, and the scope is set to 01 for area-scoping.
+   When the U-bit is set to 1, an OSPFv3 router must flood the LSA at
+   its defined flooding scope even if it does not recognize the LS type
+   [OSPFV3].
+
+       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             |1|0|1|          10             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                    Link State ID                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                    Advertising Router                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                    LS sequence number                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        LS checksum            |            Length             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      +-                            TLVs                             -+
+      |                             ...                               |
+
+                           OSPFv3 Intra-Area-TE-LSA
+
+   The Link State ID of an Intra-Area-TE-LSA is an arbitrary value used
+   to maintain multiple Traffic Engineering LSAs.  The Link State ID has
+   no topological significance.
+
+   The format of the TLVs within the body of an Intra-Area-TE-LSA is the
+   same as the format used by the Traffic Engineering extensions to OSPF
+   [TE].  The LSA payload consists of one or more nested
+   Type/Length/Value (TLV) triplets.  The format of each TLV is:
+
+       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...                           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                                  TLV Format
+
+
+
+
+Ishiguro, et al.            Standards Track                     [Page 3]
+
+RFC 5329               OSPFv3-Traffic Engineering         September 2008
+
+
+   The Length field defines the length of the value portion in octets
+   (thus, a TLV with no value portion would have a length of 0).  The
+   TLV is padded to 4-octet alignment; padding is not included in the
+   Length field (so a 3-octet value would have a length of 3, but the
+   total size of the TLV would be 8 octets).  Nested TLVs are also 32-
+   bit aligned.  For example, a 1-byte value would have the Length field
+   set to 1, and 3 octets of padding would be added to the end of the
+   value portion of the TLV.  Unrecognized types are ignored.
+
+2.1.  Intra-Area-TE-LSA Payload
+
+   An Intra-Area-TE-LSA contains one top-level TLV.  There are two
+   applicable top-level TLVs:
+
+      2 - Link TLV
+
+      3 - Router IPv6 Address TLV
+
+3.  Router IPv6 Address TLV
+
+   The Router IPv6 Address TLV advertises a reachable IPv6 address.
+   This is a stable IPv6 address that SHOULD be reachable if there is
+   connectivity to the OSPFv3 router.
+
+   The Router IPv6 Address TLV has type 3, length 16, and a value
+   containing a 16-octet local IPv6 address.  A link-local address MUST
+   NOT be specified for this TLV.  It MUST appear in exactly one Traffic
+   Engineering LSA originated by an OSPFv3 router supporting the TE
+   extensions.  The Router IPv6 Address TLV is a top-level TLV as
+   defined in "Traffic Engineering Extensions to OSPF" [TE], and only
+   one top-level TLV may be contained in an LSA.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ishiguro, et al.            Standards Track                     [Page 4]
+
+RFC 5329               OSPFv3-Traffic Engineering         September 2008
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              3                |            16                 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      +-+-+-+-                                                 -+-+-+-+
+      |                                                               |
+      +-+-+-+-             Router IPv6 Address                 -+-+-+-+
+      |                                                               |
+      +-+-+-+-                                                 -+-+-+-+
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Type    A 16-bit field set to 3.
+      Length  A 16-bit field that indicates the length of the value
+              portion in octets.  For this TLV, it is always 16.
+      Value   A stable and routable IPv6 address.
+
+                           Router IPv6 Address TLV
+
+4.  Link TLV
+
+   The Link TLV describes a single link and consists of a set of sub-
+   TLVs [TE].  All of the sub-TLVs in [TE] other than the Link ID sub-
+   TLV are applicable to OSPFv3.  The Link ID sub-TLV can't be used in
+   OSPFv3 since it is defined to use the OSPFv2 identification for the
+   Designated Router (DR) on multi-access networks.  In OSPFv2,
+   neighbors on point-to-point networks and virtual links are identified
+   by their Router IDs while neighbors on broadcast, Non-Broadcast
+   Multi-Access (NBMA), and Point-to-Multipoint links are identified by
+   their IPv4 interface addresses (refer to section 8.2 in [OSPFV2]).
+   The IPv4 interface address is not known to OSPFv3.  In contrast to
+   OSPFv2, OSPFv3 always identifies neighboring routers by their Router
+   IDs (refer to section 2.11 in [OSPFV3]).
+
+   Three new sub-TLVs for the Link TLV are defined:
+
+      18 - Neighbor ID (8 octets)
+
+      19 - Local Interface IPv6 Address (16N octets, where N is the
+           number of IPv6 addresses)
+
+      20 - Remote Interface IPv6 Address (16N octets, where N is the
+           number of IPv6 addresses)
+
+
+
+
+
+
+Ishiguro, et al.            Standards Track                     [Page 5]
+
+RFC 5329               OSPFv3-Traffic Engineering         September 2008
+
+
+   The Neighbor ID sub-TLV is mandatory for OSPFv3 Traffic Engineering
+   support.  It MUST appear exactly once in a Link TLV.  All other sub-
+   TLVs defined in this document SHOULD NOT occur more than once in a
+   Link TLV.  If a sub-TLV is specified more than once, instances
+   subsequent to the first are ignored.
+
+4.1.  Link ID Sub-TLV
+
+   The Link ID sub-TLV is used in OSPFv2 to identify the other end of
+   the link.  In OSPFv3, the Neighbor ID sub-TLV MUST be used for link
+   identification.  In OSPFv3, the Link ID sub-TLV SHOULD NOT be sent
+   and MUST be ignored upon receipt.
+
+4.2.  Neighbor ID Sub-TLV
+
+   In OSPFv2, the Link ID is used to identify the other end of a link.
+   In OSPFv3, the combination of Neighbor Interface ID and Neighbor
+   Router ID is used for neighbor link identification.  Both are
+   advertised in the Neighbor ID sub-TLV.
+
+   Neighbor Interface ID and Neighbor Router ID values are the same as
+   described in RFC 5340 [OSPFV3], A.4.3 Router-LSAs.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              18               |             8                 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |             Neighbor Interface ID                             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |             Neighbor Router ID                                |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Type    A 16-bit field set to 18.
+      Length  A 16-bit field that indicates the length of the value
+              portion in octets.  For this sub-TLV, it is always 8.
+      Value   The neighbor's Interface ID and Router ID.
+
+                             Neighbor ID Sub-TLV
+
+4.3.  Local Interface IPv6 Address Sub-TLV
+
+   The Local Interface IPv6 Address sub-TLV specifies the IPv6
+   address(es) of the interface corresponding to this link.  If there
+   are multiple local addresses assigned to the link, then they MAY all
+   be listed in this sub-TLV.  Link-local addresses MUST NOT be included
+   in this sub-TLV.
+
+
+
+
+Ishiguro, et al.            Standards Track                     [Page 6]
+
+RFC 5329               OSPFv3-Traffic Engineering         September 2008
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              19               |              Length           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      +-+-+-+-                                                 -+-+-+-+
+      |                                                               |
+      +-+-+-+-          Local Interface IPv6 Address           -+-+-+-+
+      |                                                               |
+      +-+-+-+-                                                 -+-+-+-+
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         o                                     |
+      |                         o                                     |
+      |                         o                                     |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      +-+-+-+-                                                 -+-+-+-+
+      |                                                               |
+      +-+-+-+-          Local Interface IPv6 Address           -+-+-+-+
+      |                                                               |
+      +-+-+-+-                                                 -+-+-+-+
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Type    A 16-bit field set to 19.
+      Length  A 16-bit field that indicates the length of the value
+              portion in octets.  For this sub-TLV, it MUST always be a
+              multiple of 16 octets dependent on the number of IPv6
+              global addresses advertised.
+      Value   A list of one or more local IPv6 interface addresses each
+              consuming 16 octets.
+
+                         Local Interface IPv6 Address Sub-TLV
+
+4.4.  Remote Interface IPv6 Address Sub-TLV
+
+   The Remote Interface IPv6 Address sub-TLV advertises the IPv6
+   address(es) associated with the neighbor's interface.  This sub-TLV
+   and the Local Interface IPv6 Address sub-TLV are used to discern
+   amongst parallel links between OSPFv3 routers.  If the link type is
+   multi-access, the Remote Interface IPv6 Address MAY be set to ::.
+   Alternately, an implementation MAY choose not to send this sub-TLV.
+   Link-local addresses MUST NOT be advertised in this sub-TLV.
+   Neighbor addresses advertised in link-LSAs with a prefix length of
+   128 and the LA-bit set MAY be advertised.
+
+
+
+Ishiguro, et al.            Standards Track                     [Page 7]
+
+RFC 5329               OSPFv3-Traffic Engineering         September 2008
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              20               |              Length           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      +-+-+-+-                                                 -+-+-+-+
+      |                                                               |
+      +-+-+-+-             Remote Interface IPv6 Address       -+-+-+-+
+      |                                                               |
+      +-+-+-+-                                                 -+-+-+-+
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         o                                     |
+      |                         o                                     |
+      |                         o                                     |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      +-+-+-+-                                                 -+-+-+-+
+      |                                                               |
+      +-+-+-+-             Remote Interface IPv6 Address       -+-+-+-+
+      |                                                               |
+      +-+-+-+-                                                 -+-+-+-+
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Type    A 16-bit field set to 20.
+      Length  A 16-bit field that indicates the length of the value
+              portion in octets.  For this sub-TLV, it MUST be a
+              multiple of 16 octets dependent on the number of IPv6
+              global addresses advertised.
+      Value   A variable-length Remote Interface IPv6 Address list.
+
+                    Remote Interface IPv6 Address Sub-TLV
+
+5.  Security Considerations
+
+   The function described in this document does not create any new
+   security issues for the OSPFv3 protocol.  Security considerations for
+   the base OSPFv3 protocol [OSPFV3] and OSPFv2 Traffic Engineering [TE]
+   are applicable to OSPFv3 Traffic Engineering.
+
+6.  Management Considerations
+
+   The typical management interface for routers running the new
+   extensions to OSPF for intra-area Traffic Engineering is Simple
+   Network Management Protocol (SNMP) based.  The extra management
+
+
+
+Ishiguro, et al.            Standards Track                     [Page 8]
+
+RFC 5329               OSPFv3-Traffic Engineering         September 2008
+
+
+   objects for configuration operations and statistics are defined in
+   [OSPFV3-MIB], and an implementation of the extensions defined in this
+   document SHOULD provide for the appropriate hooks or instrumentation
+   that allow for the MIB objects to be implemented.
+
+   The following MIB variables have been added to the OSPFv3 MIB in
+   support of TE:
+
+   ospfv3AreaTEEnabled
+      This TruthValue MIB variable in the ospfv3AreaEntry table entry
+      indicates whether or not OSPFv3 TE advertisement for OSPFv3
+      interfaces is enabled for the corresponding area.  The default
+      value is FALSE.
+
+   ospfv3IfTEDisabled
+      This TruthValue MIB variable in the ospfv3IfEntry table entry
+      indicates whether or not OSPFv3 TE advertisement for OSPFv3 for
+      the corresponding interface is disabled.  This MIB variable is
+      only applicable if ospfv3AreaTEEnabled is TRUE for the interface's
+      area.  The default value is FALSE.
+
+7.  IANA Considerations
+
+   The following IANA assignments have been made from existing
+   registries:
+
+   1. The OSPFv3 LSA type function code 10 has been assigned to the
+      OSPFv3 Intra-Area-TE-LSA.
+
+   2. The Router IPv6 Address TLV type 3 has been assigned from the
+      existing registry for OSPF TE TLVs.
+
+   3. The Neighbor ID (18), Local Interface IPv6 Address (19), and
+      Remote Interface IPv6 Address (20) sub-TLVs have been assigned
+      from the existing registry for OSPF TE sub-TLVs.
+
+8.  References
+
+8.1.  Normative References
+
+   [OSPFV2]       Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
+                  1998.
+
+   [OSPFV3]       Coltun, R., Ferguson, D., Moy, J., and A. Lindem,
+                  "OSPF for IPv6", RFC 5340, July 2008.
+
+   [RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+                  Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+Ishiguro, et al.            Standards Track                     [Page 9]
+
+RFC 5329               OSPFv3-Traffic Engineering         September 2008
+
+
+   [TE]           Katz, D., Kompella, K., and D. Yeung, "Traffic
+                  Engineering (TE) Extensions to OSPF Version 2", RFC
+                  3630, September 2003.
+
+8.2.  Informative References
+
+   [GMPLS]        Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF
+                  Extensions in Support of Generalized Multi-Protocol
+                  Label Switching (GMPLS)", RFC 4203, October 2005.
+
+   [OPAQUE]       Berger, L., Bryskin, I., Zinin, A., and R. Coltun,
+                  "The OSPF Opaque LSA Option", RFC 5250, July 2008.
+
+   [OSPFV3-MIB]   Joyal, D. and V. Manral, "Management Information Base
+                  for OSPFv3", Work in Progress, September 2007.
+
+   [TE-DIFF]      Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
+                  Vaananen, P., Krishnan, R., Cheval, P., and J.
+                  Heinanen, "Multi-Protocol Label Switching (MPLS)
+                  Support of Differentiated Services", RFC 3270, May
+                  2002.
+
+Acknowledgments
+
+   Thanks to Kireeti Kompella, Alex Zinin, Adrian Farrell, and Mach Chen
+   for their comments.
+
+   Thanks to Vijay K. Gurbani for providing the General Area Review Team
+   (Gen-ART) review.
+
+   Thanks to Rob Austein for providing the Security Directorate (secdir)
+   review.
+
+   Thanks to Dan Romascanu for providing the text for the "Management
+   Considerations" section in the context of the IESG review.
+
+   Thanks to Dave Ward, Tim Polk, Jari Arkko, and Pasi Eronen for
+   comments and relevant discussion in the context of the IESG review.
+
+   The RFC text was produced using Marshall Rose's xml2rfc tool.
+
+
+
+
+
+
+
+
+
+
+
+Ishiguro, et al.            Standards Track                    [Page 10]
+
+RFC 5329               OSPFv3-Traffic Engineering         September 2008
+
+
+Authors' Addresses
+
+   Kunihiro Ishiguro
+   IP Infusion, Inc.
+   1188 East Arques Avenue,
+   Sunnyvale, CA  94085
+   USA
+
+   EMail: kunihiro@ipinfusion.com
+
+
+   Vishwas Manral
+   IP Infusion, Inc
+   #41, Ground Floor, 5th Cross Road
+   8th Main Road
+   Vasanth Nagar, Bangalore  560052
+   India
+
+   EMail: vishwas@ipinfusion.com
+
+
+   Alan Davey
+   Data Connection Limited
+   100 Church Street
+   Enfield
+   EN2 6BQ
+   UK
+
+   EMail: Alan.Davey@dataconnection.com
+
+
+   Acee Lindem
+   Redback Networks
+   102 Carric Bend Court
+   Cary, NC  27519
+   USA
+
+   EMail: acee@redback.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ishiguro, et al.            Standards Track                    [Page 11]
+
+RFC 5329               OSPFv3-Traffic Engineering         September 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   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, THE IETF TRUST 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Ishiguro, et al.            Standards Track                    [Page 12]
+