One document matched: draft-king-pce-hierarchy-fwk-01.txt
Differences from draft-king-pce-hierarchy-fwk-00.txt
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| PAFTECH AB 2003-2026 | 2026-04-23 16:04:43 |