diff options
Diffstat (limited to 'doc/rfc/rfc5250.txt')
| -rw-r--r-- | doc/rfc/rfc5250.txt | 955 |
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc5250.txt b/doc/rfc/rfc5250.txt new file mode 100644 index 0000000..6abad9a --- /dev/null +++ b/doc/rfc/rfc5250.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group L. Berger +Request for Comments: 5250 LabN +Obsoletes: 2370 I. Bryskin +Category: Standards Track Adva + A. Zinin + Alcatel-Lucent + R. Coltun + Acoustra Productions + July 2008 + + + The OSPF Opaque LSA Option + +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. + +Abstract + + This document defines enhancements to the OSPF protocol to support a + new class of link state advertisements (LSAs) called Opaque LSAs. + Opaque LSAs provide a generalized mechanism to allow for the future + extensibility of OSPF. Opaque LSAs consist of a standard LSA header + followed by application-specific information. The information field + may be used directly by OSPF or by other applications. Standard OSPF + link-state database flooding mechanisms are used to distribute Opaque + LSAs to all or some limited portion of the OSPF topology. + + This document replaces RFC 2370 and adds to it a mechanism to enable + an OSPF router to validate Autonomous System (AS)-scope Opaque LSAs + originated outside of the router's OSPF area. + + + + + + + + + + + + + + + + +Berger, et al. Standards Track [Page 1] + +RFC 5250 OSPF Opaque LSA Option July 2008 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Organization of This Document ..............................3 + 1.2. Acknowledgments ............................................3 + 2. Conventions Used in This Document ...............................4 + 3. The Opaque LSA ..................................................4 + 3.1. Flooding Opaque LSAs .......................................5 + 3.2. Modifications to the Neighbor State Machine ................6 + 4. Protocol Data Structures ........................................7 + 4.1. Additions to the OSPF Neighbor Structure ...................8 + 5. Inter-Area Considerations .......................................8 + 6. Management Considerations .......................................9 + 7. Backward Compatibility ..........................................9 + 8. Security Considerations .........................................9 + 9. IANA Considerations ............................................11 + 10. References ....................................................12 + 10.1. Normative References .....................................12 + 10.2. Informative References ...................................12 + Appendix A. OSPF Data formats .....................................13 + A.1. The Options Field .........................................13 + A.2. The Opaque LSA ............................................14 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Berger, et al. Standards Track [Page 2] + +RFC 5250 OSPF Opaque LSA Option July 2008 + + +1. Introduction + + Over the last several years, the OSPF routing protocol [OSPF] has + been widely deployed throughout the Internet. As a result of this + deployment and the evolution of networking technology, OSPF has been + extended to support many options; this evolution will obviously + continue. + + This document defines enhancements to the OSPF protocol to support a + new class of link state advertisements (LSAs) called Opaque LSAs. + Opaque LSAs provide a generalized mechanism to allow for the future + extensibility of OSPF. The information contained in Opaque LSAs may + be used directly by OSPF or indirectly by some application wishing to + distribute information throughout the OSPF domain. The exact use of + Opaque LSAs is beyond the scope of this document. + + Opaque LSAs consist of a standard LSA header followed by a 32-bit + aligned application-specific information field. Like any other LSA, + the Opaque LSA uses the link-state database distribution mechanism + for flooding this information throughout the topology. The link- + state type field of the Opaque LSA identifies the LSA's range of + topological distribution. This range is referred to as the flooding + scope. + + It is envisioned that an implementation of the Opaque option provides + an application interface for 1) encapsulating application-specific + information in a specific Opaque type, 2) sending and receiving + application-specific information, and 3) if required, informing the + application of the change in validity of previously received + information when topological changes are detected. + +1.1. Organization of This Document + + This document first defines the three types of Opaque LSAs followed + by a description of OSPF packet processing. The packet processing + sections include modifications to the flooding procedure and to the + neighbor state machine. Appendix A then gives the packet formats. + +1.2. Acknowledgments + + We would like to thank Acee Lindem for his detailed review and useful + feedback. The handling of AS-scope Opaque LSAs described in this + document is taken from "Validation of OSPF AS-scope opaque LSAs" + (April 2006). + + + + + + + +Berger, et al. Standards Track [Page 3] + +RFC 5250 OSPF Opaque LSA Option July 2008 + + +2. Conventions Used in This Document + + 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]. + +3. The Opaque LSA + + Opaque LSAs are types 9, 10, and 11 link state advertisements. + Opaque LSAs consist of a standard LSA header followed by a 32-bit + aligned application-specific information field. Standard link-state + database flooding mechanisms are used for distribution of Opaque + LSAs. The range of topological distribution (i.e., the flooding + scope) of an Opaque LSA is identified by its link-state type. This + section documents the flooding of Opaque LSAs. + + The flooding scope associated with each Opaque link-state type is + defined as follows. + + o Link-state type-9 denotes a link-local scope. Type-9 Opaque LSAs + are not flooded beyond the local (sub)network. + + o Link-state type-10 denotes an area-local scope. Type-10 Opaque + LSAs are not flooded beyond the borders of their associated area. + + o Link-state type-11 denotes that the LSA is flooded throughout the + Autonomous System (AS). The flooding scope of type-11 LSAs are + equivalent to the flooding scope of AS-External (type-5) LSAs. + Specifically, type-11 Opaque LSAs are 1) flooded throughout all + transit areas, 2) not flooded into stub areas or Not-So-Stubby + Areas (NSSAs), see [NSSA], from the backbone, and 3) not + originated by routers into their connected stub areas or NSSAs. + As with type-5 LSAs, if a type-11 Opaque LSA is received in a stub + area or NSSA from a neighboring router within the stub area or + NSSA, the LSA is rejected. + + The link-state ID of the Opaque LSA is divided into an Opaque type + field (the first 8 bits) and a type-specific ID (the remaining 24 + bits). The packet format of the Opaque LSA is given in Appendix A. + Section 7 describes Opaque type allocation and assignment. + + The responsibility for proper handling of the Opaque LSA's flooding + scope is placed on both the sender and receiver of the LSA. The + receiver must always store a valid received Opaque LSA in its link- + state database. The receiver must not accept Opaque LSAs that + violate the flooding scope (e.g., a type-11 (domain-wide) Opaque LSA + + + + + +Berger, et al. Standards Track [Page 4] + +RFC 5250 OSPF Opaque LSA Option July 2008 + + + is not accepted in a stub area or NSSA). The flooding scope affects + both the synchronization of the link-state database and the flooding + procedure. + + The following describes the modifications to these procedures that + are necessary to insure conformance to the Opaque LSA's Scoping + Rules. + +3.1. Flooding Opaque LSAs + + The flooding of Opaque LSAs MUST follow the rules of flooding scope + as specified in this section. Section 13 of [OSPF] describes the + OSPF flooding procedure. Those procedures MUST be followed as + defined except where modified in this section. The following + describes the Opaque LSA's type-specific flooding restrictions. + + o If the Opaque LSA is type-9 (the flooding scope is link-local) and + the interface that the LSA was received on is not the same as the + target interface (e.g., the interface associated with a particular + target neighbor), the Opaque LSA MUST be discarded and not + acknowledged. An implementation SHOULD keep track of the IP + interface associated with each Opaque LSA having a link-local + flooding scope. + + o If the Opaque LSA is type-10 (the flooding scope is area-local) + and the area associated with the Opaque LSA (as identified during + origination or from a received LSA's associated OSPF packet + header) is not the same as the area associated with the target + interface, the Opaque LSA MUST be discarded and not acknowledged. + An implementation SHOULD keep track of the OSPF area associated + with each Opaque LSA having an area-local flooding scope. + + o If the Opaque LSA is type-11 (the LSA is flooded throughout the + AS) and the target interface is associated with a stub area or + NSSA, the Opaque LSA MUST NOT be flooded out the interface. A + type-11 Opaque LSA that is received on an interface associated + with a stub area or NSSA MUST be discarded and not acknowledged + (the neighboring router has flooded the LSA in error). + + When opaque-capable routers and non-opaque-capable OSPF routers are + mixed together in a routing domain, the Opaque LSAs are typically not + flooded to the non-opaque-capable routers. As a general design + principle, optional OSPF advertisements are only flooded to those + routers that understand them. + + An opaque-capable router learns of its neighbor's opaque capability + at the beginning of the "Database Exchange Process" (see Section 10.6 + of [OSPF] regarding receiving Database Description packets from a + + + +Berger, et al. Standards Track [Page 5] + +RFC 5250 OSPF Opaque LSA Option July 2008 + + + neighbor in state ExStart). A neighbor is opaque-capable if and only + if it sets the O-bit in the Options field of its Database Description + packets; the O-bit SHOULD NOT be set and MUST be ignored when + received in packets other than Database Description packets. Using + the O-bit in OSPF packets other than Database Description packets + will result in interoperability issues. The setting of the O-bit is + a "SHOULD NOT" rather than a "MUST NOT" to remain compatible with + earlier specifications. + + In the next step of the Database Exchange process, Opaque LSAs are + included in the Database summary list that is sent to the neighbor + (see Sections 3.2 below and 10.3 of [OSPF]) when the neighbor is + opaque capable. + + When flooding Opaque LSAs to adjacent neighbors, an opaque-capable + router looks at the neighbor's opaque capability. Opaque LSAs are + only flooded to opaque-capable neighbors. To be more precise, in + Section 13.3 of [OSPF], Opaque LSAs MUST be placed on the link-state + retransmission lists of opaque-capable neighbors and MUST NOT be + placed on the link-state retransmission lists of non-opaque-capable + neighbors. However, when sending Link State Update packets as + multicasts, a non-opaque-capable neighbor may (inadvertently) receive + Opaque LSAs. The non-opaque-capable router will then simply discard + the LSA (see Section 13 of [OSPF] regarding receiving LSAs having + unknown LS types). + + Information contained in received Opaque LSAs SHOULD only be used + when the router originating the LSA is reachable. As mentioned in + [OSPFv3], reachability validation MAY be done less frequently than + every SPF calculation. Additionally, routers processing received + Opaque LSAs MAY choose to give priority to processing base OSPF LSA + types over Opaque LSA types. + +3.2. Modifications to the Neighbor State Machine + + The state machine as it exists in Section 10.3 of [OSPF] remains + unchanged except for the action associated with State: ExStart, + Event: NegotiationDone, which is where the Database summary list is + built. To incorporate the Opaque LSA in OSPF, this action is changed + to the following. + + State(s): ExStart + + Event: NegotiationDone + + + + + + + +Berger, et al. Standards Track [Page 6] + +RFC 5250 OSPF Opaque LSA Option July 2008 + + + New state: Exchange + + Action: The router MUST list the contents of its entire area + link-state database in the neighbor Database summary + list. The area link-state database consists of the + Router LSAs, Network LSAs, Summary LSAs, type-9 Opaque + LSAs, and type-10 Opaque LSAs contained in the area + structure, along with AS External and type-11 Opaque LSAs + contained in the global structure. AS External and + type-11 Opaque LSAs MUST be omitted from a virtual + neighbor's Database summary list. AS External LSAs and + type-11 Opaque LSAs MUST be omitted from the Database + summary list if the area has been configured as a stub + area or NSSA (see Section 3.6 of [OSPF]). + + Type-9 Opaque LSAs MUST be omitted from the Database + summary list if the interface associated with the + neighbor is not the interface associated with the Opaque + LSA (as noted upon reception). + + Any advertisement whose age is equal to MaxAge MUST be + omitted from the Database summary list. It MUST instead + be added to the neighbor's link-state retransmission + list. A summary of the Database summary list will be + sent to the neighbor in Database Description packets. + Only one Database Description Packet is allowed to be + outstanding at any one time. For more detail on the + sending and receiving of Database Description packets, + see Sections 10.6 and 10.8 of [OSPF]. + +4. Protocol Data Structures + + The Opaque option is described herein in terms of its operation on + various protocol data structures. These data structures are included + for explanatory uses only. They are not intended to constrain an + implementation. In addition to the data structures listed below, + this specification references the various data structures (e.g., OSPF + neighbors) defined in [OSPF]. + + In an OSPF router, the following item is added to the list of global + OSPF data structures described in Section 5 of [OSPF]: + + o Opaque capability. Indicates whether the router is running the + Opaque option (i.e., capable of storing Opaque LSAs). Such a + router will continue to interoperate with non-opaque-capable OSPF + routers. + + + + + +Berger, et al. Standards Track [Page 7] + +RFC 5250 OSPF Opaque LSA Option July 2008 + + +4.1. Additions to the OSPF Neighbor Structure + + The OSPF neighbor structure is defined in Section 10 of [OSPF]. In + an opaque-capable router, the following items are added to the OSPF + neighbor structure: + + o Neighbor Options. This field was already defined in the OSPF + specification. However, in opaque-capable routers, there is a new + option that indicates the neighbor's Opaque capability. This new + option is learned in the Database Exchange process through + reception of the neighbor's Database Description packets and + determines whether Opaque LSAs are flooded to the neighbor. For a + more detailed explanation of the flooding of the Opaque LSA, see + Section 3 of this document. + +5. Inter-Area Considerations + + As defined above, link-state type-11 Opaque LSAs are flooded + throughout the Autonomous System (AS). One issue related to such + AS-scoped Opaque LSAs is that there must be a way for OSPF routers in + remote areas to check availability of the LSA originator. + Specifically, if an OSPF router originates a type-11 LSA and, after + that, goes out of service, OSPF routers located outside of the + originator's OSPF area have no way of detecting this fact and may use + the stale information for a considerable period of time (up to 60 + minutes). This could prove to be suboptimal for some applications + and may result in others not functioning. + + Type-9 Opaque LSAs and type-10 Opaque LSAs do not have this problem + as a receiving router can detect if the advertising router is + reachable within the LSA's respective flooding scope. In the case of + type-9 LSAs, the originating router must be an OSPF neighbor in + Exchange state or greater. In the case of type-10 Opaque LSAs, the + intra-area SPF calculation will determine the advertising router's + reachability. + + There is a parallel issue in OSPF for the AS-scoped AS External LSAs + (type-5 LSAs). OSPF addresses this by using AS border information + advertised in AS boundary router (ASBR) Summary LSAs (type-4 LSAs); + see Section 16.4 of [OSPF]. This same mechanism is reused by this + document for type-11 Opaque LSAs. + + To enable OSPF routers in remote areas to check availability of the + originator of link-state type-11 Opaque LSAs, the originators + advertise themselves as ASBRs. This will enable routers to track the + reachability of the LSA originator either directly via the SPF + calculation (for routers in the same area) or indirectly via type-4 + LSAs originated by ABRs (for routers in other areas). It is + + + +Berger, et al. Standards Track [Page 8] + +RFC 5250 OSPF Opaque LSA Option July 2008 + + + important to note that per [OSPF], this solution does not apply to + OSPF stub areas or NSSAs as AS-scoped Opaque LSAs are not flooded + into these area types. + + The procedures related to inter-area Opaque LSAs are as follows: + + (1) An OSPF router that is configured to originate AS-scope opaque + LSAs will advertise itself as an ASBR and MUST follow the + requirements related to setting of the Options field E-bit in + OSPF LSA headers as specified in [OSPF]. + + (2) When processing a received type-11 Opaque LSA, the router MUST + look up the routing table entries (potentially one per attached + area) for the ASBR that originated the LSA. If no entries exist + for the ASBR (i.e., the ASBR is unreachable), the router MUST do + nothing with this LSA. It also MUST discontinue using all Opaque + LSAs injected into the network by the same originator whenever it + is detected that the originator is unreachable. + +6. Management Considerations + + The updated OSPF MIB, [RFC4750], provides explicit support for Opaque + LSAs and SHOULD be used to support implementations of this document. + See Section 12.3 of [RFC4750] for details. In addition to that + section, implementations supporting [RFC4750] will also include + Opaque LSAs in all appropriate generic LSA objects, e.g., + ospfOriginateNewLsas and ospfLsdbTable. + +7. Backward Compatibility + + The solution proposed in this document introduces no interoperability + issues. In the case that a non-opaque-capable neighbor receives + Opaque LSAs, per [OSPF], the non-opaque-capable router will simply + discard the LSA. + + Note that OSPF routers that implement [RFC2370] will continue using + stale type-11 LSAs even when the LSA originator implements the + inter-area procedures described in Section 6 of this document. + +8. Security Considerations + + There are two types of issues that need be addressed when looking at + protecting routing protocols from misconfigurations and malicious + attacks. The first is authentication and certification of routing + protocol information. The second is denial-of-service attacks + resulting from repetitive origination of the same router + advertisement or origination of a large number of distinct + advertisements resulting in database overflow. Note that both of + + + +Berger, et al. Standards Track [Page 9] + +RFC 5250 OSPF Opaque LSA Option July 2008 + + + these concerns exist independently of a router's support for the + Opaque option. + + To address the authentication concerns, OSPF protocol exchanges are + authenticated. OSPF supports multiple types of authentication; the + type of authentication in use can be configured on a per-network- + segment basis. One of OSPF's authentication types, namely the + Cryptographic authentication option, is believed to be secure against + passive attacks and provide significant protection against active + attacks. When using the Cryptographic authentication option, each + router appends a "message digest" to its transmitted OSPF packets. + Receivers then use the shared secret key and received digest to + verify that each received OSPF packet is authentic. + + The quality of the security provided by the Cryptographic + authentication option depends completely on the strength of the + message digest algorithm (MD5 is currently the only message digest + algorithm specified), the strength of the key being used, and the + correct implementation of the security mechanism in all communicating + OSPF implementations. It also requires that all parties maintain the + secrecy of the shared secret key. None of the standard OSPF + authentication types provide confidentiality. Nor do they protect + against traffic analysis. For more information on the standard OSPF + security mechanisms, see Sections 8.1, 8.2, and Appendix D of [OSPF]. + + Repetitive origination of advertisements is addressed by OSPF by + mandating a limit on the frequency that new instances of any + particular LSA can be originated and accepted during the flooding + procedure. The frequency at which new LSA instances may be + originated is set equal to once every MinLSInterval seconds, whose + value is 5 seconds (see Section 12.4 of [OSPF]). The frequency at + which new LSA instances are accepted during flooding is once every + MinLSArrival seconds, whose value is set to 1 (see Section 13, + Appendix B, and G.5 of [OSPF]). + + Proper operation of the OSPF protocol requires that all OSPF routers + maintain an identical copy of the OSPF link-state database. However, + when the size of the link-state database becomes very large, some + routers may be unable to keep the entire database due to resource + shortages; we term this "database overflow". When database overflow + is anticipated, the routers with limited resources can be + accommodated by configuring OSPF stub areas and NSSAs. [OVERFLOW] + details a way of gracefully handling unanticipated database + overflows. + + + + + + + +Berger, et al. Standards Track [Page 10] + +RFC 5250 OSPF Opaque LSA Option July 2008 + + + In the case of type-11 Opaque LSAs, this document reuses an ASBR + tracking mechanism that is already employed in basic OSPF for type-5 + LSAs. Therefore, applying it to type-11 Opaque LSAs does not create + any threats that are not already known for type-5 LSAs. + +9. IANA Considerations + + This document updates the requirements for the OSPF Opaque LSA type + registry. Three following changes have been made: + + 1. References to [RFC2370] have been replaced with references to this + document. + + 2. The Opaque type values in the range of 128-255 have been reserved + for "Private Use" as defined in [RFC5226]. + + 3. The reference for Opaque type registry value 1, Traffic + Engineering LSA, has been updated to [RFC3630]. + + The registry now reads: + + Open Shortest Path First (OSPF) Opaque Link-State + Advertisements (LSA) Option Types + + Registries included below: + - Opaque Link-State Advertisements (LSA) Option Types + + Registry Name: Opaque Link-State Advertisements (LSA) Option Types + Reference: [RFC5250] + Range Registration Procedures Notes + -------- ------------------------------------------ -------- + 0-127 IETF Consensus + 128-255 Private Use + + Registry: + Value Opaque Type Reference + ------- ------------------------------------------ --------- + 1 Traffic Engineering LSA [RFC3630] + 2 Sycamore Optical Topology Descriptions [Moy] + 3 grace-LSA [RFC3623] + 4 Router Information (RI) [RFC4970] + 5-127 Unassigned + 128-255 Private Use + + + + + + + + +Berger, et al. Standards Track [Page 11] + +RFC 5250 OSPF Opaque LSA Option July 2008 + + +10. References + +10.1. Normative References + + [DEMD] Moy, J., "Extending OSPF to Support Demand Circuits", RFC + 1793, April 1995. + + [OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. + + [RFC2119] Bradner, S., "Key words for use in RFCs to indicate + requirements levels", BCP 14, RFC 2119, March 1997. + + [RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed., + Coltun, R., and F. Baker, "OSPF Version 2 Management + Information Base", RFC 4750, December 2006. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + +10.2. Informative References + + [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March + 1994. + + [NSSA] Murphy P., "The OSPF Not-So-Stubby Area (NSSA) Option", + RFC 3101, January 2003. + + [OSPF-MT] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. + Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC + 4915, June 2007. + + [OSPFv3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, Ed., + "OSPF for IPv6", Work in Progress, May 2008. + + [OVERFLOW] Moy, J., "OSPF Database Overflow", RFC 1765, March 1995. + + [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July + 1998. + + [RFC3630] Katz, D., Kompella, K., and D. Yeund, "Traffic Engineering + (TE) Extensions to OSPF Version 2", RFC 3630, September + 2003. + + [RFC4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a + Link State Advertisement (LSA) Options Bit to Prevent + Looping in BGP/MPLS IP Virtual Private Networks (VPNs)", + RFC 4576, June 2006. + + + +Berger, et al. Standards Track [Page 12] + +RFC 5250 OSPF Opaque LSA Option July 2008 + + +Appendix A. OSPF Data Formats + + This appendix describes the format of the Options Field followed by + the packet format of the Opaque LSA. + +A.1. The Options Field + + The OSPF Options field is present in OSPF Hello packets, Database + Description packets, and all link state advertisements. The Options + field enables OSPF routers to support (or not support) optional + capabilities, and to communicate their capability level to other OSPF + routers. Through this mechanism, routers of differing capabilities + can be mixed within an OSPF routing domain. + + When used in Hello packets, the Options field allows a router to + reject a neighbor because of a capability mismatch. Alternatively, + when capabilities are exchanged in Database Description packets a + router can choose not to flood certain link state advertisements to a + neighbor because of its reduced functionality. Lastly, listing + capabilities in link state advertisements allows routers to forward + traffic around reduced functionality routers by excluding them from + parts of the routing table calculation. + + All 8 bits of the OSPF Options field have been assigned, although + only the O-bit is described completely by this document. Each bit is + described briefly below. Routers SHOULD reset (i.e., clear) + unrecognized bits in the Options field when sending Hello packets or + Database Description packets and when originating link state + advertisements. Conversely, routers encountering unrecognized Option + bits in received Hello Packets, Database Description packets, or link + state advertisements SHOULD ignore the capability and process the + packet/advertisement normally. + + +--------------------------------------+ + | DN | O | DC | EA | N/P | MC | E | MT | + +--------------------------------------+ + + The Options Field + + MT-bit + This bit describes the router's multi-topology link-excluding + capability, as described in [OSPF-MT]. + + E-bit + This bit describes the way AS-External LSAs are flooded, as + described in Sections 3.6, 9.5, 10.8, and 12.1.2 of [OSPF]. + + + + + +Berger, et al. Standards Track [Page 13] + +RFC 5250 OSPF Opaque LSA Option July 2008 + + + MC-bit + This bit describes whether IP multicast datagrams are forwarded + according to the specifications in [MOSPF]. + + N/P-bit + This bit describes the handling of Type-7 LSAs, as specified in + [NSSA]. + + DC-bit + This bit describes the router's handling of demand circuits, as + specified in [DEMD]. + + EA-bit + This bit describes the router's willingness to receive and + forward External-Attributes-LSAs. While defined, the documents + specifying this bit have all expired. The use of this bit may + be deprecated in the future. + + O-bit + This bit describes the router's willingness to receive and + forward Opaque LSAs as specified in this document. + + DN-bit + This bit is used to prevent looping in BGP/MPLS IP VPNs, as + specified in [RFC4576]. + +A.2. The Opaque LSA + + Opaque LSAs are Type 9, 10, and 11 link state advertisements. These + advertisements MAY be used directly by OSPF or indirectly by some + application wishing to distribute information throughout the OSPF + domain. The function of the Opaque LSA option is to provide for + future OSPF extensibility. + + Opaque LSAs contain some number of octets (of application-specific + data) padded to 32-bit alignment. Like any other LSA, the Opaque LSA + uses the link-state database distribution mechanism for flooding this + information throughout the topology. However, the Opaque LSA has a + flooding scope associated with it so that the scope of flooding may + be link-local (type-9), area-local (type-10), or the entire OSPF + routing domain (type-11). Section 3 of this document describes the + flooding procedures for the Opaque LSA. + + + + + + + + + +Berger, et al. Standards Track [Page 14] + +RFC 5250 OSPF Opaque LSA Option July 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS age | Options | 9, 10, or 11 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Opaque Type | Opaque ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Advertising Router | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS Sequence Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS checksum | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | Opaque Information | + + + + | ... | + + Link-State Type + + The link-state type of the Opaque LSA identifies the LSA's range + of topological distribution. This range is referred to as the + flooding scope. The following explains the flooding scope of each + of the link-state types. + + o A value of 9 denotes a link-local scope. Opaque LSAs with a + link-local scope MUST NOT be flooded beyond the local + (sub)network. + + o A value of 10 denotes an area-local scope. Opaque LSAs with an + area-local scope MUST NOT be flooded beyond their area of + origin. + + o A value of 11 denotes that the LSA is flooded throughout the + Autonomous System (e.g., has the same scope as type-5 LSAs). + Opaque LSAs with AS-wide scope MUST NOT be flooded into stub + areas or NSSAs. + + Syntax of the Opaque LSA's Link-State ID + + The link-state ID of the Opaque LSA is divided into an Opaque Type + field (the first 8 bits) and an Opaque ID (the remaining 24 bits). + See section 7 of this document for a description of Opaque type + allocation and assignment. + + + + + + +Berger, et al. Standards Track [Page 15] + +RFC 5250 OSPF Opaque LSA Option July 2008 + + +Authors' Addresses + + Lou Berger + LabN Consulting, L.L.C. + EMail: lberger@labn.net + + Igor Bryskin + ADVA Optical Networking Inc + 7926 Jones Branch Drive + Suite 615 + McLean, VA 22102 + EMail: ibryskin@advaoptical.com + + Alex Zinin + Alcatel-Lucent + 750D Chai Chee Rd #06-06 + Technopark@ChaiChee + Singapore, 469004 + EMail: alex.zinin@alcatel-lucent.com + + Rob Coltun + Acoustra Productions + 3204 Brooklawn Terrace + Chevy Chase, MD 20815 + USA + + + + + + + + + + + + + + + + + + + + + + + + + + +Berger, et al. Standards Track [Page 16] + +RFC 5250 OSPF Opaque LSA Option July 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. + + + + + + + + + + + + +Berger, et al. Standards Track [Page 17] + |