Network Working Group D. King Internet-Draft Old Dog Consulting Intended Status: Informational A. Farrel Created: July 13, 2009 Old Dog Consulting Expires: December 13, 2009 The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS & GMPLS draft-king-pce-hierarchy-fwk-01.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. This document examines techniques to establish the optimum path when the sequence of domains is not known in advance. The document provides mechanisms that allow the optimum sequence of domains to be selected and the optimum end-to-end path to be derived. King and Farrel [Page 1]
draft-king-hierarchy-fwk-01.txt July 2009 Contents 1. Introduction..................................................3 1.1 Problem Statement............................................3 1.2 Definition of a Domain............. .........................4 1.3 Requirements.................................................4 1.3.1 Metric Objectives..........................................5 1.3.2 Domain Diversity...........................................5 1.3.3 Domain Path Diversity......................................5 1.3.4 Existing Traffic Engineering Constraints...................5 1.3.5 Commercial Constraints.....................................5 1.3.6 Domain Confidentiality.....................................6 1.4 Terminology..................................................6 2. Per Domain Path Computation...................................7 3. Backwards Recursive Path Computation..........................7 3.1. Applicability of BRPC when the Domain Path is not Known.....8 4. Hierarchical PCE..............................................8 5. Hierarchical PCE Procedures...................................9 5.1 Objective Functions..........................................9 5.2 Maintaining Domain Confidentiality...........................10 5.3 PCE Discovery................................................10 5.4 Domain Traffic Engineering Abstraction.......................11 5.5 Determination of Destination Domain .........................11 5.6 Hierarchical PCE Examples....................................11 5.6.1 Hierarchical PCE Initial Information Exchange..............13 5.6.2 Hierarchical PCE End-to-End Path Computation Procedure Example..........................................................14 6. Hierarchical PCE Applicability................................14 6.1 Antonymous Systems...........................................14 6.2 ASON architecture (G-7715-2).................................15 6.3 IGP Areas....................................................15 7. Management Considerations ....................................15 7.1 Control of Function and Policy...............................15 7.2 Information and Data Models..................................15 7.3 Liveness Detection and Monitoring............................15 7.4 Verifying Correct Operation..................................15 7.5. Impact on Network Operation.................................15 8. Security Considerations ......................................15 9. IANA Considerations ..........................................15 10. Acknowledgements ............................................15 11. References ..................................................15 11.1. Normative References.......................................15 11.2. Informative References ....................................16 12. Authors' Addresses ..........................................17 12. Intellectual Property Consideration .........................18 13. Disclaimer of Validity ......................................18 14. Full Copyright Statement ....................................19 King and Farrel [Page 2]
draft-king-hierarchy-fwk-01.txt July 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 [RFC5441] 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. The model proposed in this document is applicable to environments with small groups of domains (where visibility is limited from the ingress LSR). Applying the hierarchical PCE model to large groups of domains such as the Internet, is not feasible or relevant. 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. King and Farrel [Page 3]
draft-king-hierarchy-fwk-01.txt July 2009 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. 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 Definition 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 Networks are often constructed from multiple domains. These domains are often interconnected via multiple interconnect points. Its assumed that the sequence of domains are not always well-known. The traffic engineering properties of a domain cannot be seen from outside the domain. Traffic engineering aggregation or abstraction, hides information and leads to failed path setup. Flooding TE information breaks confidentiality and does not scale in the routing protocol and in the aggregation process King and Farrel [Page 4]
draft-king-hierarchy-fwk-01.txt July 2009 The primary goal of this document is to define how to derive optimal end-to-end multi-domain paths when the sequence of domains is not known. The solution needs to be scalable, maintain internal domain topology confidentiality while providing the optimal end- to-end path. 1.3.1 Metric Objectives The definition of optimality is dependent on policy and will be based on a single objective or a group objectives. An objective may be requested during the path computation request. The following objectives have been initially identified but the list may be expanded in future versions of this document: * Minimum cost path * Minimum load path * Maximum residual bandwidth path * Minimize aggregate bandwidth consumption * Minimize the number of border routers used * Limit the number of domains crossed 1.3.2 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. 1.3.3 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.4 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.5 Commercial Constraints The solution should provide the capability to include commercially relevant constraints such as policy, SLAs, security, peering preferences, and dollar costs. Additionally it may be necessary for the service provider to request that specific domains are included or excluded based on commercial relationships, security implications, and reliability. King and Farrel [Page 5]
draft-king-hierarchy-fwk-01.txt July 2009 1.3.6 Domain Confidentiality A key requirement is the ability to maintain domain confidentiality when computing inter-domain end-to-end paths. When required by local policy, a PCE should not need to disclose to any other PCE the intra- domain paths it computes or the internal topology of the domain it serves.. 1.4 Terminology This document uses PCE terminology defined in [RFC4655], [RFC4875], and [RFC5440]. 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 [RFC5541]. 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 6]
draft-king-hierarchy-fwk-01.txt July 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 inter-domain 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. Per domain path computation may suit simply-connected domains and where the preferred points of interconnection are known 3. Backwards Recursive Path Computation The PCE-based Backwards Recursive Path Computation procedure [RFC5441] 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. King and Farrel [Page 7]
draft-king-hierarchy-fwk-01.txt July 2009 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. BRPC may suit environments where multiple connections exist between domains and there is no preference for the choice of points of interconnection. 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. 4. Hierarchical PCE In the hierarchical PCE architecture, a Parent (hierarchical) PCE maintains a domain topology map. The domain topology map contains the Child domains, seen as nodes, and their interconnections. The Parent PCE has no information about the contents of the Child domains. The Parent PCE is aware of the TE capabilities of the Child domain interconnections. King and Farrel [Page 8]
draft-king-hierarchy-fwk-01.txt July 2009 Each domain has a PCE responsible for computing paths across it. These PCEs are known as Child PCEs and have a relationship with the Parent PCE. Each Child PCE also knows the identity of the domains that neighbor its own domain. One Child PCE cannot know the topology of another Child domain. Child PCEs are also not aware of the general domain mesh connectivity. The Parent PCE learns from configuration or from each Child PCE how the domains are interconnected including the traffic engineering (TE) capabilities of domain interconnections, but does not know the contents of the domains. Discovery of the domain topology and interconnections is discussed further in section 5.3. 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. Hierarchical PCE Procedures 5.1 Objective Functions and Policy Deriving the optimal end-to-end domain path sequence will be dependent on the policy applied during the domain path computation. An Objective Function (OF), or set of OFs may be applied in order to define the policy being applied to the domain path computation. The 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 - Minimize the number of border routers used 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 Parent PCE according to inter-domain policy. King and Farrel [Page 9]
draft-king-hierarchy-fwk-01.txt July 2009 5.2 Maintaining Domain Confidentiality A Parent PCE is aware of the topology and connections between domains, but is not aware of the contents of the domains. Child domains are completely confidential. One Child PCE cannot know the topology of another Child domain. Child domains do not know the general domain mesh connectivity. 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 [RFC5520]. This mechanism effectively hides the content of a segment of a path. 5.3 PCE Discovery It is a simple matter for each Child PCE to be configured with the address of its Parent PCE. Typically, 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). The Parent PCE also needs to know the inter-domain connectivity. This information could be configured with suitable policy and commercial rules, or could be learned from the Child PCEs as described in Section 4. Consideration of discovery of Parent PCE relationships, between Parent PCEs and Child PCEs, is for future study. Mechanisms that rely on advertising or querying PCE locations across domains or provider boundaries are undesirable. In order for the Parent PCE to learn about domain interconnection the Child PCE will report the identity of its neighbor domains. The IGP in each neighbor domain can advertise its inter-domain TE link capability. Multi-domain and multi-provider discovery is undesirable due to security and scalability issues. King and Farrel [Page 10]
draft-king-hierarchy-fwk-01.txt July 2009 5.4 Domain Traffic Engineering Abstraction The Parent 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 Parent PCE. Furthermore the Parent domain may contain nodes and links in its own right. Therefore, the Parent 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. 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 Parent PCE 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 Parent 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). King and Farrel [Page 11]
draft-king-hierarchy-fwk-01.txt July 2009 - 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). ----------------------------------------------------------------- | 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 King and Farrel [Page 12]
draft-king-hierarchy-fwk-01.txt July 2009 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. ---------------------------- | Domain 5 | | ---- | | |PCE5| | | ---- | | | | ---- ---- ---- | | | |---| |---| | | | | D1 | | D2 | | D3 | | | | |---| |---| | | | ---- ---- ---- | | \ ---- / | | \ | | / | | ----| D4 |---- | | | | | | ---- | | | ---------------------------- Figure 2 Abstract Domain Topology as Seen by the Parent PCE 5.6.1 Hierarchical PCE Initial Information Exchange Based on the Figure 1 topology. The following is an illustration of the initial hierarchical PCE information exchange. 1. Child PCE 1, the PCE responsible for Domain 1, is configured with the location of its Parent PCE (PCE5). 2. Child PCE 1 establishes contact with its Parent PCE. 3. Child PCE 1 listens to Child IGP and learns its inter-domain connectivity. 4. Child PCE 1 reports its neighbor domain connectivity. 5. Child PCE reports inter-domain link status changes. Each Child PCE will perform the steps outlined above so the Parent PCE can create an abstracted domain topology view as described in Figure 2. King and Farrel [Page 13]
draft-king-hierarchy-fwk-01.txt July 2009 5.6.2 Hierarchical PCE End-to-End Path Computation Procedure The procedure below is an example of a source LSR (PCC) requesting an end toend path in a multi-domain environment. The topology is represented in Figure 1. It is assumed that the each Child PCE has connected to its Parent PCE and exchanged the initial information required for the Parent PCE to create its abstracted domain topology view. 1. The source (PCC), ingress LSR , sends a request to the PCE responsible for its domain (PCE1) for a path to the destination, egress LSR. 2. PCE 1 determines the destination, is not in domain 1. 3. PCE 1 sends a computation request to its Parent PCE (PCE 5). 4. PCE 5 determines the likely domain paths. 5. PCE 5 sends an edge to edge a path computation request to PCE 2 which is responsible for domain 2 and PCE 4 which is responsible for domain 4. 6. PCE 5 sends a source to an edge path computation request to PCE 1 which is responsible for domain 1. 7. PCE 5 sends an edge to egress request to PCE3 which is responsible for domain 3. 8. PCE 5 correlates all computation request responses and applies any requested policy requirements. 9. PCE 5 will then select the optimal end-to-end multi-domain path that meets any policy and objective functions and supplies the ERO to PCE 1. 10. PCE 1 will forward the ERO to the source, ingress LSR. 6. Hierarchical PCE Applicability 6.1 Antonymous Systems King and Farrel [Page 14]
draft-king-hierarchy-fwk-01.txt July 2009 6.2 ASON architecture (G-7715-2) The Parent 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. 6.3 IGP Areas. 7. Management Considerations This section requires significant consideration and will be discussed in further revisions of this document. 7.1 Control of Function and Policy 7.2 Information and Data Models 7.3 Liveness Detection and Monitoring 7.4 Verifying Correct Operation 7.5. Impact on Network Operation 8. Security Considerations 9. IANA Considerations This document makes no requests for IANA action. 10. Acknowledgements 11. References 11.1 Normative References [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. King and Farrel [Page 15]
draft-king-hierarchy-fwk-01.txt July 2009 12.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)", [RFC5441] Vasseur, J.P., Ed., "A Backward Recursive PCE-based Computation (BRPC) procedure to compute shortest inter-domain Traffic Engineering Label Switched Paths", RFC5441, April 2009. [RFC5440] 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)", RFC5440, March 2009. [RFC4461] S. Yasukawa, Editor "Signaling Requirements for Point-to-Multipoint Traffic Engineered MPLS LSPs", RFC4461, April 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. [RFC5541] Roux, J., Vasseur, J., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC5541, December 2008. [RFC5520] Brandford, R., Vasseur J.P., and Farrel A., "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Key-Based Mechanism RFC5520, April 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). King and Farrel [Page 16]
draft-king-hierarchy-fwk-01.txt July 2009 [G-7715-2] ITU-T Recommendation G.7715.2 (2007), ASON routing architecture and requirements for remote route query. 13. 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 17]
draft-king-hierarchy-fwk-01.txt July 2009 14. 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. 15. 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. King and Farrel [Page 18]
draft-king-hierarchy-fwk-01.txt July 2009 16. 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. King and Farrel [Page 19]
draft-king-hierarchy-fwk-01.txt July 2009