One document matched: draft-king-pce-hierarchy-fwk-00.txt
Network Working Group D. King
Internet-Draft Old Dog Consulting
Intended Status: Informational A. Farrel
Created: May 18, 2009 Old Dog Consulting
Expires: November 18, 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-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-hierarchy-fwk-01.txt March 2009
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.
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..........................................4
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.....................................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........................9
5.2 Applicability to the ASON architecture (G7715.2).............9
5.3 PCE Discovery................................................9
5.3 Domain Traffic Engineering Abstraction.......................10
5.5 Determination of Destination Domain .........................10
5.6 Hierarchical PCE Examples....................................10
6. Management Considerations ....................................13
6.1 Policy Management............................................13
7. Security Considerations ......................................13
8. IANA Considerations ..........................................13
9. Acknowledgements .............................................13
10. References ..................................................13
10.1. Normative References.......................................13
10.2. Informative References ....................................14
11. Authors' Addresses ..........................................16
12. Intellectual Property Consideration .........................16
13. Disclaimer of Validity ......................................17
14. Full Copyright Statement ....................................17
King and Farrel [Page 2]
draft-king-hierarchy-fwk-01.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 [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.
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-hierarchy-fwk-01.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 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
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
* Limit the number of domains crossed
King and Farrel [Page 4]
draft-king-hierarchy-fwk-01.txt March 2009
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.
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).
King and Farrel [Page 5]
draft-king-hierarchy-fwk-01.txt March 2009
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.
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.
King and Farrel [Page 6]
draft-king-hierarchy-fwk-01.txt March 2009
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.
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-hierarchy-fwk-01.txt March 2009
4. Hierarchical PCE
In the hierarchical PCE architecture, a Parent (hierarchical)
PCE maintains a domain topology map. The domain topology map contains
the domains and their interconnections, but has no information about
the contents of the domains.
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.
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.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
Parent PCE according to inter-domain policy.
King and Farrel [Page 8]
draft-king-hierarchy-fwk-01.txt March 2009
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 [RFC5520]. This
mechanism effectively hides the content of a segment of a path.
5.2 Applicability to 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.
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
King and Farrel [Page 9]
draft-king-hierarchy-fwk-01.txt March 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).
King and Farrel [Page 10]
draft-king-hierarchy-fwk-01.txt March 2009
- 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 11]
draft-king-hierarchy-fwk-01.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 12]
draft-king-hierarchy-fwk-01.txt March 2009
----------------------------
| Domain 5 |
| ---- |
| |PCE5| |
| ---- |
| |
| ---- ---- ---- |
| | |---| |---| | |
| | D1 | | D2 | | D3 | |
| | |---| |---| | |
| ---- ---- ---- |
| \ ---- / |
| \ | | / |
| ----| D4 |---- |
| | | |
| ---- |
| |
----------------------------
Figure 2 Abstract Domain Topology as Seen by the Parent 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
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
King and Farrel [Page 13]
draft-king-hierarchy-fwk-01.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)",
[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.
[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.
[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).
King and Farrel [Page 14]
draft-king-hierarchy-fwk-01.txt March 2009
[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.
King and Farrel [Page 15]
draft-king-hierarchy-fwk-01.txt March 2009
11. Authors' Addresses
Daniel King
Old Dog Consulting
Email: daniel@olddog.co.uk
Adrian Farrel
Old Dog Consulting
Email: adrian@olddog.co.uk
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 16]
draft-king-hierarchy-fwk-01.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.
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.
| PAFTECH AB 2003-2026 | 2026-04-23 16:07:56 |