diff options
Diffstat (limited to 'doc/rfc/rfc5073.txt')
| -rw-r--r-- | doc/rfc/rfc5073.txt | 731 |
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc5073.txt b/doc/rfc/rfc5073.txt new file mode 100644 index 0000000..475f303 --- /dev/null +++ b/doc/rfc/rfc5073.txt @@ -0,0 +1,731 @@ + + + + + + +Network Working Group J.P. Vasseur, Ed. +Request for Comments: 5073 Cisco Systems, Inc. +Category: Standards Track J.L. Le Roux, Ed. + France Telecom + December 2007 + + + IGP Routing Protocol Extensions for + Discovery of Traffic Engineering Node Capabilities + +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 + + It is highly desired, in several cases, to take into account Traffic + Engineering (TE) node capabilities during Multi Protocol Label + Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered + Label Switched Path (TE-LSP) selection, such as, for instance, the + capability to act as a branch Label Switching Router (LSR) of a + Point-To-MultiPoint (P2MP) LSP. This requires advertising these + capabilities within the Interior Gateway Protocol (IGP). For that + purpose, this document specifies Open Shortest Path First (OSPF) and + Intermediate System-Intermediate System (IS-IS) traffic engineering + extensions for the advertisement of control plane and data plane + traffic engineering node capabilities. + + + + + + + + + + + + + + + + + + + + +Vasseur & Le Roux Standards Track [Page 1] + +RFC 5073 IGP Ext for Discovery of TE Node Cap December 2007 + + +Table of Contents + + 1. Introduction.....................................................2 + 2. Terminology......................................................3 + 3. TE Node Capability Descriptor ...................................3 + 3.1. Description ................................................3 + 3.2. Required Information .......................................3 + 4. TE Node Capability Descriptor TLV Formats .......................4 + 4.1. OSPF TE Node Capability Descriptor TLV Format ..............4 + 4.2. IS-IS TE Node Capability Descriptor sub-TLV format .........5 + 5. Elements of Procedure ...........................................6 + 5.1. OSPF .......................................................6 + 5.2. IS-IS ......................................................7 + 6. Backward Compatibility ..........................................8 + 7. Security Considerations .........................................8 + 8. IANA Considerations .............................................8 + 8.1. OSPF TLV ...................................................8 + 8.2. ISIS sub-TLV ...............................................8 + 8.3. Capability Registry ........................................9 + 9. Acknowledgments .................................................9 + 10. References ....................................................10 + 10.1. Normative References .....................................10 + 10.2. Informative References ...................................11 + +1. Introduction + + Multi Protocol Label Switching-Traffic Engineering (MPLS-TE) routing + ([RFC3784], [RFC3630], [OSPFv3-TE]) relies on extensions to link + state Interior Gateway Protocols (IGP) ([IS-IS], [RFC1195], + [RFC2328], [RFC2740]) in order to advertise Traffic Engineering (TE) + link information used for constraint-based routing. Further + Generalized MPLS (GMPLS) related routing extensions are defined in + [RFC4205] and [RFC4203]. + + It is desired to complement these routing extensions in order to + advertise TE node capabilities, in addition to TE link information. + These TE node capabilities will be taken into account as constraints + during path selection. + + Indeed, it is useful to advertise data plane TE node capabilities, + such as the capability for a Label Switching Router (LSR) to be a + branch LSR or a bud-LSR of a Point-To-MultiPoint (P2MP) Label + Switched Path (LSP). These capabilities can then be taken into + account as constraints when computing the route of TE LSPs. + + It is also useful to advertise control plane TE node capabilities + such as the capability to support GMPLS signaling for a packet LSR, + or the capability to support P2MP (Point to Multipoint) TE LSP + + + +Vasseur & Le Roux Standards Track [Page 2] + +RFC 5073 IGP Ext for Discovery of TE Node Cap December 2007 + + + signaling. This allows selecting a path that avoids nodes that do + not support a given control plane feature, or triggering a mechanism + to support such nodes on a path. Hence, this facilitates backward + compatibility. + + For that purpose, this document specifies IGP (OSPF and IS-IS) + extensions in order to advertise data plane and control plane + capabilities of a node. + + A new TLV is defined for OSPF, the TE Node Capability Descriptor TLV, + to be carried within the Router Information LSA ([RFC4970]). A new + sub-TLV is defined for IS-IS, the TE Node Capability Descriptor + sub-TLV, to be carried within the IS-IS Capability TLV ([RFC4971]). + +2. Terminology + + This document uses terminologies defined in [RFC3031], [RFC3209], and + [RFC4461]. + + 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 [RFC2119]. + +3. TE Node Capability Descriptor + +3.1. Description + + LSRs in a network may have distinct control plane and data plane + Traffic Engineering capabilities. The TE Node Capability Descriptor + information defined in this document describes data and control plane + capabilities of an LSR. Such information can be used during path + computation so as to avoid nodes that do not support a given TE + feature either in the control or data plane, or to trigger procedures + to handle these nodes along the path (e.g., trigger LSP hierarchy to + support a legacy transit LSR on a P2MP LSP (see [RFC4875])). + +3.2. Required Information + + The TE Node Capability Descriptor contains a variable-length set of + bit flags, where each bit corresponds to a given TE node capability. + + + + + + + + + + + +Vasseur & Le Roux Standards Track [Page 3] + +RFC 5073 IGP Ext for Discovery of TE Node Cap December 2007 + + + Five TE Node Capabilities are defined in this document: + + - B bit: when set, this flag indicates that the LSR can act + as a branch node on a P2MP LSP (see [RFC4461]); + - E bit: when set, this flag indicates that the LSR can act + as a bud LSR on a P2MP LSP, i.e., an LSR that is both + transit and egress (see [RFC4461]); + - M bit: when set, this flag indicates that the LSR supports + MPLS-TE signaling ([RFC3209]); + - G bit: when set this flag indicates that the LSR supports + GMPLS signaling ([RFC3473]); + - P bit: when set, this flag indicates that the LSR supports + P2MP MPLS-TE signaling ([RFC4875]). + + Note that new capability bits may be added in the future if required. + +4. TE Node Capability Descriptor TLV Formats + +4.1. OSPF TE Node Capability Descriptor TLV Format + + The OSPF TE Node Capability Descriptor TLV is a variable length TLV + that contains a series of bit flags, where each bit correspond to a + TE node capability. The bit-field MAY be extended with additional + 32-bit words if more bit flags need to be assigned. Any unknown bit + flags SHALL be treated as Reserved bits. + + The OSPF TE Node Capability Descriptor TLV is carried within an OSPF + Router Information LSA, which is defined in [RFC4970]. + + The format of the OSPF TE Node Capability Descriptor TLV is the same + as the TLV format used by the Traffic Engineering Extensions to OSPF + [RFC3630]. That is, the TLV is composed of 2 octets for the type, 2 + octets specifying the length of the value field, and a value field. + + The OSPF TE Node Capability Descriptor TLV has the following format: + + TYPE: 5 (see Section 8.1) + LENGTH: Variable (multiple of 4). + VALUE: Array of units of 32 flags numbered from the most + significant bit as bit zero, where each bit represents + a TE node capability. + + + + + + + + + + +Vasseur & Le Roux Standards Track [Page 4] + +RFC 5073 IGP Ext for Discovery of TE Node Cap December 2007 + + + The following bits are defined: + + Bit Capabilities + + 0 B bit: P2MP Branch Node capability: When set, this indicates + that the LSR can act as a branch node on a P2MP LSP + [RFC4461]. + 1 E bit: P2MP Bud-LSR capability: When set, this indicates + that the LSR can act as a bud LSR on a P2MP LSP, i.e., an + LSR that is both transit and egress [RFC4461]. + 2 M bit: If set, this indicates that the LSR supports MPLS-TE + signaling ([RFC3209]). + 3 G bit: If set, this indicates that the LSR supports GMPLS + signaling ([RFC3473]). + 4 P bit: If set, this indicates that the LSR supports P2MP + MPLS-TE signaling ([RFC4875]). + + 5-31 Reserved for future assignments by IANA. + + Reserved bits MUST be set to zero on transmission, and MUST be + ignored on reception. If the length field is greater than 4, + implying that there are more than 32 bits in the value field, then + any additional bits (i.e., not yet assigned) are reserved. + +4.2. IS-IS TE Node Capability Descriptor sub-TLV format + + The IS-IS TE Node Capability Descriptor sub-TLV is a variable length + sub-TLV that contains a series of bit flags, where each bit + corresponds to a TE node capability. The bit-field MAY be extended + with additional bytes if more bit flags need to be assigned. Any + unknown bit flags SHALL be treated as Reserved bits. + + The IS-IS TE Node Capability Descriptor sub-TLV is carried within an + IS-IS CAPABILITY TLV, which is defined in [RFC4971]. + + The format of the IS-IS TE Node Capability sub-TLV is the same as the + sub-TLV format used by the Traffic Engineering Extensions to IS-IS + [RFC3784]. That is, the sub-TLV is composed of 1 octet for the type, + 1 octet specifying the length of the value field. + + The IS-IS TE Node Capability Descriptor sub-TLV has the following + format: + + TYPE: 1 (see Section 8.2) + LENGTH: Variable + VALUE: Array of units of 8 flags numbered from the most + significant bit as bit zero, where each bit represents + a TE node capability. + + + +Vasseur & Le Roux Standards Track [Page 5] + +RFC 5073 IGP Ext for Discovery of TE Node Cap December 2007 + + + The following bits are defined: + + Bit Capabilities + + 0 B bit: P2MP Branch Node capability: When set, this indicates + that the LSR can act as a branch node on a P2MP LSP + [RFC4461]. + 1 E bit: P2MP Bud-LSR capability: When set, this indicates + that the LSR can act as a bud LSR on a P2MP LSP, i.e., an + LSR that is both transit and egress [RFC4461]. + 2 M bit: If set, this indicates that the LSR supports MPLS-TE + signaling ([RFC3209]). + 3 G bit: If set, this indicates that the LSR supports GMPLS + signaling ([RFC3473]). + 4 P bit: If set, this indicates that the LSR supports P2MP + MPLS-TE signaling ([RFC4875]). + + 5-7 Reserved for future assignments by IANA. + + Reserved bits MUST be set to zero on transmission, and MUST be + ignored on reception. If the length field is great than 1, implying + that there are more than 8 bits in the value field, then any + additional bits (i.e., not yet assigned) are reserved. + +5. Elements of Procedure + +5.1. OSPF + + The TE Node Capability Descriptor TLV is advertised, within an OSPFv2 + Router Information LSA (Opaque type of 4 and Opaque ID of 0) or an + OSPFv3 Router Information LSA (function code of 12), which are + defined in [RFC4970]. As such, elements of procedure are inherited + from those defined in [RFC2328], [RFC2740], and [RFC4970]. + + The TE Node Capability Descriptor TLV advertises capabilities that + may be taken into account as constraints during path selection. + Hence, its flooding scope is area-local, and it MUST be carried + within an OSPFv2 type 10 Router Information LSA (as defined in + [RFC2370]) or an OSPFv3 Router Information LSA with the S1 bit set + and the S2 bit cleared (as defined in [RFC2740]). + + A router MUST originate a new OSPF Router Information LSA whenever + the content of the TE Node Capability Descriptor TLV changes or + whenever required by the regular OSPF procedure (LSA refresh (every + LSRefreshTime)). + + + + + + +Vasseur & Le Roux Standards Track [Page 6] + +RFC 5073 IGP Ext for Discovery of TE Node Cap December 2007 + + + The TE Node Capability Descriptor TLV is OPTIONAL and MUST NOT appear + more than once in an OSPF Router Information LSA. If a TE Node + Capability Descriptor TLV appears more than once in an OSPF Router + Information LSA, only the first occurrence MUST be processed and + others MUST be ignored. + + When an OSPF Router Information LSA does not contain any TE Node + Capability Descriptor TLV, this means that the TE node capabilities + of that LSR are unknown. + + Note that a change in any of these capabilities MAY trigger + Constrained Shortest Path First (CSPF) computation, but MUST NOT + trigger normal SPF computation. + + Note also that TE node capabilities are expected to be fairly static. + They may change as the result of configuration change or software + upgrade. This is expected not to appear more than once a day. + +5.2. IS-IS + + The TE Node Capability sub-TLV is carried within an IS-IS CAPABILITY + TLV defined in [RFC4971]. As such, elements of procedure are + inherited from those defined in [RFC4971]. + + The TE Node Capability Descriptor sub-TLV advertises capabilities + that may be taken into account as constraints during path selection. + Hence, its flooding is area-local, and it MUST be carried within an + IS-IS CAPABILITY TLV having the S flag cleared. + + An IS-IS router MUST originate a new IS-IS LSP whenever the content + of any of the TE Node Capability sub-TLV changes or whenever required + by the regular IS-IS procedure (LSP refresh). + + The TE Node Capability Descriptor sub-TLV is OPTIONAL and MUST NOT + appear more than once in an ISIS Router Capability TLV. + + When an IS-IS LSP does not contain any TE Node Capability Descriptor + sub-TLV, this means that the TE node capabilities of that LSR are + unknown. + + Note that a change in any of these capabilities MAY trigger CSPF + computation, but MUST NOT trigger normal SPF computation. + + Note also that TE node capabilities are expected to be fairly static. + They may change as the result of configuration change, or software + upgrade. This is expected not to appear more than once a day. + + + + + +Vasseur & Le Roux Standards Track [Page 7] + +RFC 5073 IGP Ext for Discovery of TE Node Cap December 2007 + + +6. Backward Compatibility + + The TE Node Capability Descriptor TLVs defined in this document do + not introduce any interoperability issues. For OSPF, a router not + supporting the TE Node Capability Descriptor TLV will just silently + ignore the TLV, as specified in [RFC4970]. For IS-IS, a router not + supporting the TE Node Capability Descriptor sub-TLV will just + silently ignore the sub-TLV, as specified in [RFC4971]. + + When the TE Node Capability Descriptor TLV is absent, this means that + the TE Capabilities of that LSR are unknown. + + The absence of a word of capability flags in OSPF or an octet of + capability flags in IS-IS means that these capabilities are unknown. + +7. Security Considerations + + This document specifies the content of the TE Node Capability + Descriptor TLV in IS-IS and OSPF to be used for (G)MPLS-TE path + computation. As this TLV is not used for SPF computation or normal + routing, the extensions specified here have no direct effect on IP + routing. Tampering with this TLV may have an effect on Traffic + Engineering computation. Mechanisms defined to secure IS-IS Link + State PDUs [RFC3567], OSPF LSAs [RFC2154], and their TLVs can be used + to secure this TLV as well. + +8. IANA Considerations + +8.1. OSPF TLV + + [RFC4970] defines a new codepoint registry for TLVs carried in the + Router Information LSA defined in [RFC4970]. + + IANA has made a new codepoint assignment from that registry for the + TE Node Capability Descriptor TLV defined in this document and + carried within the Router Information LSA. The value is 5. See + Section 4.1 of this document. + +8.2. ISIS sub-TLV + + IANA has defined a registry for sub-TLVs of the IS-IS CAPABILITY TLV + defined in [RFC4971]. + + IANA has made a new codepoint assignment from that registry for the + TE Node Capability Descriptor sub-TLV defined in this document, and + carried within the ISIS CAPABILITY TLV. The value is 1. See Section + 4.2 of this document. + + + + +Vasseur & Le Roux Standards Track [Page 8] + +RFC 5073 IGP Ext for Discovery of TE Node Cap December 2007 + + +8.3. Capability Registry + + IANA has created a new registry to manage the space of capability bit + flags carried within the OSPF and ISIS TE Node Capability Descriptor. + + A single registry must be defined for both protocols. A new base + registry has been created to cover IGP-TE registries that apply to + both OSPF and IS-IS, and the new registry requested by this document + is a sub-registry of this new base registry. + + Bits in the new registry should be numbered in the usual IETF + notation, starting with the most significant bit as bit zero. + + New bit numbers may be allocated only by an IETF Consensus action. + + Each bit should be tracked with the following qualities: + - Bit number + - Defining RFC + - Name of bit + + IANA has made assignments for the five TE node capabilities defined + in this document (see Sections 8.1 and 8.2) using the following + values: + + Bit No. Name Reference + --------+---------------------------------------+--------------- + 0 B bit: P2MP Branch LSR capability [RFC5073] + 1 E bit: P2MP Bud LSR capability [RFC5073] + 2 M bit: MPLS-TE support [RFC5073] + 3 G bit: GMPLS support [RFC5073] + 4 P bit: P2MP RSVP-TE support [RFC5073] + 5-7 Unassigned [RFC5073] + +9. Acknowledgments + + We would like to thank Benoit Fondeviole, Adrian Farrel, Dimitri + Papadimitriou, Acee Lindem, and David Ward for their useful comments + and suggestions. + + We would also like to thank authors of [RFC4420] and [RFC4970] by + which some text of this document has been inspired. + + Adrian Farrel prepared the final version of this document for + submission to the IESG. + + + + + + + +Vasseur & Le Roux Standards Track [Page 9] + +RFC 5073 IGP Ext for Discovery of TE Node Cap December 2007 + + +10. References + +10.1. Normative References + + [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and + dual environments", RFC 1195, December 1990. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. + + [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July + 1998. + + [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", + RFC 2740, December 1999. + + [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, + "Multiprotocol Label Switching Architecture", RFC 3031, + January 2001. + + [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, + V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP + Tunnels", RFC 3209, December 2001. + + [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Signaling Resource ReserVation + Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC + 3473, January 2003. + + [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic + Engineering (TE) Extensions to OSPF Version 2", RFC + 3630, September 2003. + + [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate + System (IS-IS) Extensions for Traffic Engineering (TE)", + RFC 3784, June 2004. + + [IS-IS] "Intermediate System to Intermediate System Intra-Domain + Routeing Exchange Protocol for use in Conjunction with + the Protocol for Providing the Connectionless-mode + Network Service (ISO 8473)", ISO 10589. + + [RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., + "Intermediate System to Intermediate System (IS-IS) + Extensions for Advertising Router Information", RFC + 4971, July 2007. + + + +Vasseur & Le Roux Standards Track [Page 10] + +RFC 5073 IGP Ext for Discovery of TE Node Cap December 2007 + + + [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., + and S. Shaffer, "Extensions to OSPF for Advertising + Optional Router Capabilities", RFC 4970, July 2007. + + [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. + Yasukawa, Ed., "Extensions to Resource Reservation + Protocol - Traffic Engineering (RSVP-TE) for Point-to- + Multipoint TE Label Switched Paths (LSPs)", RFC 4875, + May 2007. + +10.2. Informative References + + [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with + Digital Signatures", RFC 2154, June 1997. + + [RFC3567] Li, T. and R. Atkinson, "Intermediate System to + Intermediate System (IS-IS) Cryptographic + Authentication", RFC 3567, July 2003. + + [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions + in Support of Generalized Multi-Protocol Label Switching + (GMPLS)", RFC 4203, October 2005. + + [RFC4205] Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate + System to Intermediate System (IS-IS) Extensions in + Support of Generalized Multi-Protocol Label Switching + (GMPLS)", RFC 4205, October 2005. + + [RFC4420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and + A. Ayyangar, "Encoding of Attributes for Multiprotocol + Label Switching (MPLS) Label Switched Path (LSP) + Establishment Using Resource ReserVation Protocol- + Traffic Engineering (RSVP-TE)", RFC 4420, February 2006. + + [RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point- + to-Multipoint Traffic-Engineered MPLS Label Switched + Paths (LSPs)", RFC 4461, April 2006. + + [OSPFv3-TE] Ishiguro K., Manral V., Davey A., and Lindem A., + "Traffic Engineering Extensions to OSPF version 3", Work + in Progress. + + + + + + + + + + +Vasseur & Le Roux Standards Track [Page 11] + +RFC 5073 IGP Ext for Discovery of TE Node Cap December 2007 + + +Contributors' Addresses + + Seisho Yasukawa + NTT + 3-9-11 Midori-cho, + Musashino-shi, Tokyo 180-8585, Japan + EMail: s.yasukawa@hco.ntt.co.jp + + Stefano Previdi + Cisco Systems, Inc + Via Del Serafico 200 + Roma, 00142 + Italy + EMail: sprevidi@cisco.com + + Peter Psenak + Cisco Systems, Inc + Pegasus Park DE Kleetlaan 6A + Diegmen, 1831 + BELGIUM + EMail: ppsenak@cisco.com + + Paul Mabbey + Comcast + USA + +Editors' Addresses + + Jean-Philippe Vasseur + Cisco Systems, Inc. + 1414 Massachusetts Avenue + Boxborough, MA, 01719 + USA + EMail: jpv@cisco.com + + Jean-Louis Le Roux + France Telecom + 2, avenue Pierre-Marzin + 22307 Lannion Cedex + FRANCE + EMail: jeanlouis.leroux@orange-ftgroup.com + + + + + + + + + + +Vasseur & Le Roux Standards Track [Page 12] + +RFC 5073 IGP Ext for Discovery of TE Node Cap December 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + 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. + + + + + + + + + + + + +Vasseur & Le Roux Standards Track [Page 13] + |