Network Working Group D. King Internet-Draft Old Dog Consulting Intended Status: Informational A. Farrel Created: March 4, 2009 Old Dog Consulting Expires: September 4, 2009 The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in Multi-Domain Multiprotocol Label Switching Traffic Engineering and Generalized Multiprotocol Label Switching draft-king-pce-brpc-app-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Computing optimum routes for Label Switched Paths (LSPs) across multiple domains in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) networks presents a problem because no single point of path computation is aware of all of the links and resources in each domain. A solution may be achieved using the Path Computation Element (PCE) architecture. Where the sequence of domains is known a priori, various techniques can be employed to derive an optimum path. If the domains are simply- connected, or if the preferred points of interconnection are also known, the Per-Domain Path Computation technique can be used. Where there are multiple connections between domains and there is no preference for the choice of points of interconnection, the Backward Recursive Path Computation Procedure (BRPC) can be used. King and Farrel [Page 1]
draft-king-pce-brpc-app-00.txt March 2009 This document examines techniques to establish the optimum path when the sequence of domains is not known in advance. That is, it provides mechanisms that allow the optimum sequence of domains to be selected and the optimum end-to-end path to be derived. Contents 1. Introduction..................................................3 1.1 Problem Statement............................................3 1.2 Definitions of a Domain......................................4 1.3 Requirements.................................................4 1.3.1 Domain Diversity...........................................4 1.3.2 Domain Path Diversity......................................5 1.3.3 Existing Traffic Engineering Constraints...................5 1.3.4 Commercial Constraints.....................................5 1.4 Terminology..................................................5 2. Per Domain Path Computation...................................6 3. Backwards Recursive Path Computation..........................7 3.1. Applicability of BRPC when the Domain Path is not Known.....7 4. Hierarchical PCE..............................................8 5.1 Procedures ..................................................8 5.1.1. Objective Functions.......................................8 5.1.2. Maintaining Domain Confidentiality........................8 5.2 Applicability to the ASON architecture (G7715.2).............9 5.3 Domain Traffic Engineering Abstraction.......................9 5.5 Determination of Destination Domain .........................10 5.6 Hierarchical PCE Examples....................................10 6. Management Considerations ....................................12 6.1 Policy Management............................................12 7. Security Considerations ......................................12 8. IANA Considerations ..........................................12 9. Acknowledgements .............................................12 10. References ..................................................12 10.1. Normative References.......................................12 10.2. Informative References ....................................13 11. Authors' Addresses ..........................................14 12. Intellectual Property Consideration .........................15 13. Disclaimer of Validity ......................................16 14. Full Copyright Statement ....................................16 King and Farrel [Page 2]
draft-king-pce-brpc-app-00.txt March 2009 1. Introduction The capability to compute, establish and control end-to-end inter- domain Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) and Generalized Multiprotocol Label Switching (GMPLS) paths, using a Path Computation Element is well known. The Path Computation Element (PCE) architecture is defined in [RFC4655]. The methods for establishing and controlling inter-domain MPLS and GMPLS are documented in [RFC4726] In a multi-domain environment, a PCE can be used to compute end-to-end paths using a per-domain path computation technique [RFC5152]. Alternatively, the backward recursive path computation (BRPC) mechanism [BRPC] allows multiple PCEs to collaborate in order to select an optimal end-to-end path that crosses multiple domains. A domain can be defined as separate administrative, geographic, or switching environment within the network. A domain may be further defined as a zone of routing or computational ability. These might be categorized as an Antonymous System (AS) or an Interior Gateway Protocol (IGP) [RFC4726] and [RFC4655]. Domains are connected through ingress and egress boundary nodes (BNs). This document examines techniques to establish the optimum path when the sequence of domains is not known in advance. It documents the architecture and mechanisms necessary to allow the optimum sequence of domains to be selected and the optimum end-to-end path to be derived. 1.1 Problem Statement Using a PCE to compute a path between nodes within a single domain is relatively straightforward. Computing an end-to-end path when the source and destination nodes are located in different domains requires co-operation between multiple PCEs, each responsible for its own domain. Both techniques, assume that the sequence of domains to be crossed from source to destination is well known. No explanation is given of how this sequence is generated or what criteria may be used for the selection of paths between domains. In small clusters of domains, such as simple cooperation between adjacent ISPs, this selection process is not complex. In more advanced deployments (such as optical networks constructed from multiple sub-domains, or multi- AS environments)the choice of domains in the end-to-end domain sequence can be critical to the determination of an optimum end-to-end path. King and Farrel [Page 3]
draft-king-pce-brpc-app-00.txt March 2009 The document introduces the concept of a hierarchical PCE architecture and shows how to coordinate PCEs in peer domains in order to derive an optimal end-to-end path. The work is currently scoped to operate with a small group of domains and there is no intent to apply this model to a large group of domains, e.g., the Internet. 1.2 Definitions of a Domain A domain is defined in [RFC4726] as any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include IGP areas and Autonomous Systems. Wholly or partially overlapping domains e.g., path computation sub-domains of areas or ASes) are not within the scope of this document. In the context of GMPLS, a particularly important example of a domain is the ASON subnetwork [G-8080]. In this case computation of an end-to-end path requires the selection of nodes and links within a parent domain where some nodes may in fact be subnetwork. Furthermore a domain might be an ASON routing area [G-7715]. A PCE may perform the path computation function of an ASON routing controller as described in [G-7715-2]. This document assumes that the selection of a sequence of domains for an end-to-end path is in some sense a hierarchical path computation problem. That is, where one mechanism is used to determine across a domain a separate mechanism (or at least a separate set of paradigms) is used to determine the sequence of domains. 1.3 Requirements The primary goal of this document is to define how to derive optimal end-to-end multi-domain paths when the destination is when the sequence of domains well-known. The solution needs to be scalable and maintain confidentiality while providing the optimal path. 1.3.1 Domain Diversity Domain diversity should facilitate the selection of paths that share ingress and egress domains, but do not share transit domains. This provides a way to ensure domain diversity for most of the path of the LSP. King and Farrel [Page 4]
draft-king-pce-brpc-app-00.txt March 2009 1.3.2 Domain Path Diversity Domain path selection should provide the capability to include or exclude specific border nodes, for an example to ensure path diversity for the path of the label switched path (LSP). 1.3.3 Existing Traffic Engineering Constraints Any solution should take advantage of typical traffic engineering constraints (hop count, bandwidth, lambda continuity, path cost, etc.[RFC4655)] 1.3.4 Commercial Constraints The solution should provide the capability to include commercially relevant constraints such as policy, SLAs, security, peering preferences, and dollar costs. 1.4 Terminology This document uses PCE terminology defined in [RFC4655], [RFC4875], and [PCEP]. Additional terms are defined below and draw on the concepts set out for P2MP LSPs in [RFC4461]. Boundary Nodes: Each Domain has entry LSRs and exit LSRs that can either be ABRs or ASBRs. They are defined here as Boundary Nodes (BNs). Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) along a determined sequence of domains. Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along a determined sequence of domains. OF: Objective Function: A set of one or more optimization criterion (criteria) used for the computation of a single path (e.g. path cost minimization), or the synchronized computation of a set of paths (e.g. aggregate bandwidth consumption minimization, etc.). See [RFC4655] and [PCE-OF]. Domain Path: The known sequence of domains for a path. Egress Domain: The domain that includes the egress LSR. Root Domain: The domain that includes the ingress LSR. Transit Domain: A domain that has an upstream and downstream neighbour domain. King and Farrel [Page 5]
draft-king-pce-brpc-app-00.txt March 2009 2. Per Domain Path Computation The per-domain path computation method for establishing inter-Domain TE-LSPs [RFC5152] defines a technique for establishing an inter-domain GMPLS TE Label Switched Path (LSP) whereby the path is computed during the signalling process on a per-domain basis by the entry boundary node of each domain (each node responsible for triggering the computation of a section of an inter-domain TE LSP path is always along the path of such TE LSP). Domain boundary LSRs may have different computation capabilities, run different path computation algorithms, apply different sets of constraints and optimization criteria, etc. During per domain path computation each border node must perform a computation and invoke its PCE. Each PCE selects the first available path, even though the path might be met the minimum constraints requested it may not represent the optimal path. Ultimately per domain path computation may lead to sub-optimal paths. In the case that the domain path (in particular the sequence of border nodes) is not known. A PCE must select an exit border node, based on some determination of how to reach the destination that is outside [RFC5152] the domain of which the PCE has computational responsibility. [RFC5152] suggest that this might be achieved using the IP shortest path as advertise by BGP. Not however that the existence of an IP forwarding path does guarantee the presence of sufficient bandwidth, let alone an optimal TE path. Furthermore in many GMPLS systems inter0domain iP routing will not be present. Thus, per domain path computation may require a significant crankback attempts to establish even a sub-optimal TE path. King and Farrel [Page 6]
draft-king-pce-brpc-app-00.txt March 2009 3. Backwards Recursive Path Computation The PCE-based Backwards Recursive Path Computation procedure [BRPC] also applies to the computation of an optimal constrained inter-domain TE LSP. The sequence of domains to be traversed can either be determined before or during the path computation procedure. The BRPC procedure communicates between cooperating PCEs in order to compute the end-to-end path across multiple domains. In the case where the sequence of domains is known. The source PCC (Path Computation Client) sends a path computation requests to the PCE responsible for its domain. This request is then forwarded between PCEs, domain-by-domain, to the PCE responsible for the destination domain. The PCE in the destination domain creates a Virtual Shortest Path Tree (VSPT), a tree of potential paths, to the destination and passes this back to the previous PCE. As the VSPT is passed back towards the source domain each PCE adds to the VSPT until it reached the PCE in the source domain uses the VSPT to select an end-to-end path that it sends to the initiating PCC. 3.1. Applicability of BRPC when the Domain Path is Not Known As described above BRPC can be used to determine an optimal inter-domain path when the sequence is known. Even when the sequence of domains is not known BRPC could be used as follows. - PCC sends PC request to its local PCE (ingress PCE) - The ingress PCE sends the path computation request direct to the PCE responsible for the domain containing the destination node (egress PCE) - The egress PCE computes an egress VSPT and passes it to a PCE responsible for each of the adjacent domains. - Each PCE in turn constructs a VSPT and passes it on to all of its neighboring PCEs. - When the ingress PCE has received a VSPT from each of its neighboring domains it is able to select the optimum path. Clearly this mechanism (which could be called path computation flooding) has significant scaling issues. It could be improved by the application of policy and filtering but such mechanisms are not simple and would still leave scaling concerns. King and Farrel [Page 7]
draft-king-pce-brpc-app-00.txt March 2009 4. Hierarchical PCE In the hierarchical PCE architecture, a parent PCE is aware of the topology and connections between domains, but is not aware of the contents of the domains. Discovery of the domain topology and interconnections is discussed in section 5.2. When a path is needed outside of the ingress domain, the ingress PCE sends a PCEP request the parent PCE. The parent PCE computes a domain path based on the current domain topology. The parent PCE selects candidate domain paths; it then sends computation requests to the child PCEs responsible for the domains on any candidate domain path. 5.1 Procedures 5.1.1. Objective Functions and Policy An Objective Function (OF) specifies the desired outcome of the computation. It does not describe the algorithm to use. When computing end-to-end inter-domain paths, required OFs may include: - Minimum cost path - Minimum load path - Maximum residual bandwidth path - Minimize aggregate bandwidth consumption Limit on number of domains crossed - Initially set by admin - Length of the shortest path found so far The objective function may be requested by the PCC, the ingress domain PCE (according to local policy), or a maybe applied by the hierarchical PCE according to inter-domain policy. 5.1.2. Maintaining Domain Confidentiality As described in early sections of this document, PCEs can exchange path information in order to achieve end-to-end inter-domain connectivity. Each path fragment, per domain, reveals information about a domain. Some management regions or ASes will not want to share this information. A PCE can replace a path segment with a path-key instead of the full path according to [PCE-KEY]. This mechanism effectively hides the content of a segment of a path. King and Farrel [Page 8]
draft-king-pce-brpc-app-00.txt March 2009 5.2 Applicability to ASON architecture (G-7715-2) The hierarchical PCE mechanism fits well within the ASON routing architecture. It can be used to provide paths across subnetworks, and to determine end-to-end paths in networks constructed from multiple subnetworks or routing areas. The routing controllers each implement a PCE that can be queried by any Network Element (NE) within the routing area for which the routing controller has responsibility. When a path is needed outside of the domain, the routing controllers use the hierarchical PCE model to fully match the hierarchical routing model of ASON. 5.3 PCE Discovery It is a simple matter for each Child PCE to be configured with the address of its parent PCE. Typical, there will only be one or two Parents of any Child. The Parent PCE also needs to be aware of the Child PCEs for all Child domains that it can see. This information is most likely to be configured (as part of the administrative definition of each domain). Consideration of discovery of hierarchical of PCE relationships is for future study. 5.4 Domain Traffic Engineering Abstraction The hierarchical PCE maintains a topology map of the Child domains and their interconnectivity. Where inter-domain connectivity is provide by TE links the capabilities of those links must also be known to the hierarchical PCE. Furthermore the hierarchical domain may contain nodes and links in its own right. Therefore, the hierarchical PCE maintains a traffic engineering database (TED) for its domain in the same way that any PCE does. The mechanism for building the parent TED is likely to rely heavily on administrative configuration and commercial issues. However in models such as ASON, it is possible to consider a separate instance of an IGP running within the parent domain where the participating protocol speakers are the nodes directly present in that domain and the PCEs (routing controllers) responsible for each of the child domains. King and Farrel [Page 9]
draft-king-pce-brpc-app-00.txt March 2009 5.5 Determination of Destination Domain The source node (PCC) is aware of the identity of the destination node. If it knows the destination domain it can supply this information as part of the PCEP request. However, if it does not know the destination domain this information must be determined by the PCEs. In some specialist topologies the Parent PCE could determine the destination domain based on the destination address, for example from configuration. However this is not appropriate for many multi-domain addressing scenarios. In IP based multi-domain networks the hierarchical may be able to determine the destination domain by participating in inter-domain routing. Finally, the Parent PCE could issue specific requests to the Child PCEs to discover if they contain the destination node. This topic will require continued study. 5.6 Hierarchical PCE Examples Figure 1 demonstrates four interconnected domains within a fifth hierarchical domain. Each domain contains a PCE. - Domain 1 is the ingress domain and contains Child PCE 1. Its neighbours are domain 2 (with Child PCE 2) and Domain 4 (with Child PCE 4. The domain also contains the source (S) label switch router (LSR) and three egress border nodes (BN11, B12 and BN13). - Domain 2 contains Child PCE 2. Its neighbours are domain 1 (with Child PCE 1) and domain 3 (with Child PCE 3). The domain also contains two ingress border nodes (BN21 and BN22) and two egress border nodes (BN23 and BN24). - Domain 3 is the egress domain and contains Child PCE 3. Its neighbours are domain 2 (with Child PCE 2) and domain 4 (with Child PCE 4). The domain also contains the destination (D) label switch router (LSR) and three ingress border nodes (BN31, BN32 and BN33). - Domain 4 contains Child PCE 4. Its neighbours are domain 2 (with Child PCE 2) and domain 3 (with Child PCE 3). The domain also contains an ingress border node (BN41) and an egress border node (BN42). All of these domains are encompassed within Domain 5 which contains the Parent PCE (PCE 5). King and Farrel [Page 10]
draft-king-pce-brpc-app-00.txt March 2009 ----------------------------------------------------------------- | Domain 5 | | ---- | | |PCE5| | | ---- | | | | ---------------- ---------------- ---------------- | | | Domain1 | | Domain2 | | Domain3 | | | | ---- | | ---- | | ---- | | | | |PCE1| | | |PCE2| | | |PCE3| | | | | ---- | | ---- | | ---- | | | | ----| |---- ----| |---- | | | | |BN11+---+BN21| |BN23+---+BN31| | | | | - ----| |---- ----| |---- - | | | | |S| | | | | |D| | | | | - ----| |---- ----| |---- - | | | | |BN12+---+BN22| |BN24+---+BN32| | | | | ----| |---- ----| |---- | | | | | | | | | | | | ---- | | | | ---- | | | | |BN13| | | | | |BN33| | | | -----------+---- ---------------- ----+----------- | | \ / | | \ ---------------- / | | \ | | / | | \ |---- ----| / | | ----+BN41| |BN42+---- | | |---- ----| | | | ---- | | | | |PCE4| | | | | ---- | | | | Domain4 | | | | | | | ---------------- | | | ----------------------------------------------------------------- Figure 1 : Sample Hierarchical Domain Topology Figure 2, demonstrates the view of the domain topology as seen by Parent PCE (PCE 5). This view is an abstracted topology; PCE 5 is aware of domain connectivity but not of the internal topology within each domain. King and Farrel [Page 11]
draft-king-pce-brpc-app-00.txt March 2009 ---------------------------- | Domain 5 | | ---- | | |PCE5| | | ---- | | | | ---- ---- ---- | | | |---| |---| | | | | D1 | | D2 | | D3 | | | | |---| |---| | | | ---- ---- ---- | | \ ---- / | | \ | | / | | ----| D4 |---- | | | | | | ---- | | | ---------------------------- Figure 2 Abstract Domain Topology as Seen by the hierarchical PCE 6. Management Considerations This section requires significant consideration and will be discussed in further revisions of this document. 6.1 Policy Management 7. Security Considerations 8. IANA Considerations This document makes no requests for IANA action. 9. Acknowledgements 10. References 10.1 Normative References King and Farrel [Page 12]
draft-king-pce-brpc-app-00.txt March 2009 10.2. Informative References [RFC5152] Vasseur, J.P., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-domain path computation method for computing Inter-domain Traffic Engineering (TE) Label Switched Path (LSP)", [BRPC] J.P. Vasseur, Editor, "A Backward Recursive PCE-based Computation (BRPC) procedure to compute shortest inter-domain Traffic Engineering Label Switched Paths", draft-ietf-pce-brpc, work in progress. [PCEP] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow, A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", draft-ietf-pce-pcep-19 (work in progress), Novemeber 2008. [RFC4461] S. Yasukawa, Editor "Signaling Requirements for Point-to-Multipoint Traffic Engineered MPLS LSPs", RFC4461, April 2006. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006. [RFC4875] Aggarwal, R., Papadimitriou, D., and Yasukawa, S., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007. [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, February 2008. [PCE-OF] Le Roux, J.L., Vasseur, J.P., and Lee, Y., "Encoding of Objective Functions in Path Computation Element communication Protocol (PCEP)", draft-ietf-pce-of, work in progress. [PCE-KEY] Brandford, R., Vasseur J.P., and Farrel A., "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Key-Based Mechanism draft-ietf-pce-path-key-05.txt, November 2008. King and Farrel [Page 13]
draft-king-pce-brpc-app-00.txt March 2009 [G-8080] ITU-T Recommendation G.8080/Y.1304, Architecture for the automatically switched optical network (ASON). [G-7715] ITU-T Recommendation G.7715 (2002), Architecture and Requirements for the Automatically Switched Optical Network (ASON). [G-7715-2] ITU-T Recommendation G.7715.2 (2007), ASON routing architecture and requirements for remote route query. 11. Authors' Addresses Daniel King Old Dog Consulting Email: daniel@olddog.co.uk Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk King and Farrel [Page 14]
draft-king-pce-brpc-app-00.txt March 2009 12. Intellectual Property Consideration The IETF Trust 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 any IETF 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. Copies of Intellectual Property 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 any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. King and Farrel [Page 15]
draft-king-pce-brpc-app-00.txt March 2009 13. Disclaimer of Validity All IETF Documents and the information contained therein 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 THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 13. Disclaimer of Validity All IETF Documents and the information contained therein 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 THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 14. Full Copyright Statement Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.