diff options
Diffstat (limited to 'doc/rfc/rfc5329.txt')
| -rw-r--r-- | doc/rfc/rfc5329.txt | 675 |
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] + |