One document matched: draft-zhao-pce-pcep-inter-domain-p2mp-procedures-00.txt
Internet Engineering Task Force Q. Zhao
Internet-Draft Huawei Technology
Intended status: Standards Track David Amzallag
Created: March 4, 2009 BT
Expires: September 4, 2009 Daniel King
Old Dog Consulting
PCE-based Computation Procedure To Compute Shortest
Constrained P2MP Inter-domain Traffic Engineering Label Switched Paths
draft-zhao-pce-pcep-inter-domain-p2mp-procedures-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
Point-to-multipoint (P2MP) Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE
LSPs) may be established using signaling techniques, but their paths
must first be determined. The Path Computation Element (PCE) has
been identified as an appropriate technology for the determination of
the paths of P2MP TE LSPs.
This document describes the procedures and extensions to the PCE
communication Protocol (PCEP) to handle requests and responses for
the computation of inter-domain paths for P2MP TE LSPs.
Zhao, et el. [Page 1]
draft-zhao-pce-pcep-inter-domain-p2mp-procedures-00.txt March 2009
Contents
1. Introduction.....................................................3
1.1 Problem Statement.............................................3
1.2 Assumptions...................................................4
1.3 Requirements..................................................4
1.4 Objective Functions...........................................5
2. Terminology......................................................6
3. Procedures.......................................................7
3.1 Per Domain Path Computation...................................7
3.2 Backwards Recursive Path Computation..........................7
3.3 Core Tree Path Computation....................................7
3.3.1 Core Tree Based Procedure.................................7
4. Protocol Extensions for Core Tree Based Computation..............9
4.1 The Extension of RP Object....................................9
4.2 The PCE topology Object......................................10
5. IANA Considerations.............................................11
6. Manageability...................................................11
6.1 Scalability Considerations...................................11
7. Security........................................................11
8. Acknowledgement.................................................11
9. References......................................................12
9.1 Normative References.........................................12
9.2 Informative References.......................................12
10. Authors' Addresses.............................................13
11. Intellectual Property Consideration............................13
12. Disclaimer of Validity.........................................14
13. Full Copyright Statement.......................................14
Zhao, et el. [Page 2]
draft-zhao-pce-pcep-inter-domain-p2mp-procedures-00.txt March 2009
1. Introduction
Multicast services are increasingly in demand for high-capacity
applications such as multicast VPNs, IPTV (on-demand or streaming),
and content-rich media distribution (for example, software
distribution, financial streaming, or data-sharing). The inter-domain
P2MP TE LSP is a feature that facilities the deployment and operation
of these services across multi domains.
The need to establish point-to-multipoint (P2MP) traffic engineered
(TE) Label Switching Paths (LSPs) in Multiprotocol Label Switching
(MPLS) and Generalized MPLS (GMPLS) networks is covered in [RFC4461].
The applicability of the Path Computation Element (PCE) for the
computation of such paths is discussed in [PCE-P2MP-APP], and the
requirements placed on PCEP for this are given in [PCE-P2MP-REQ].
The static stitching or RSVP-TE extension based solution might solve
the issue in certain degree, but they cannot compute an optimal
inter-domain P2MP TE LSP. This document defines a PCE-based
solution which will give the optimal inter-domain P2MP TE LSP.
1.1 Problem Statement
The Path Computation Element (PCE) defined in [RFC4655] is an entity
that is capable of computing a network path or route based on a
network graph, and applying computational constraints. A Path
Computation Client (PCC) may make requests to a PCE for paths to be
computed.
[RFC4875] describes how to set up P2MPTE LSPs for use in MPLS GMPLS
networks.
The PCE is identified as a suitable application for the computation
of paths for P2MP TE LSPs [PCE-P2MP-APP].
The draft-ietf-pce-brpc-09.txt specifies a procedure relying on the
use of multiple Path Computation Elements (PCEs) to compute point-to-
point (P2P) inter-domain shortest constrained paths across a
predetermined sequence of domains, using a backward recursive path
computation technique. The technique preserves confidentiality across
domains, which is sometimes required when domains are managed by
different Service Providers.
The PCE communication protocol (PCEP) [PCEP] is extended as a
communication protocol between PCCs and PCEs for point-to-
multipoint(P2MP) path computations and is defined in [PCE-P2MP-EXT].
However, that specification does not provide a mechanism to request
path computation of inter-domain P2MP TE LSPs.
Zhao, et el. [Page 3]
draft-zhao-pce-pcep-inter-domain-p2mp-procedures-00.txt March 2009
This document presents a solution, and procedures and extensions to
PCEP to support P2MP inter-domain path computation.
2.2 Assumptions
It is assumed that due to deployment and commercial limitations
(e.g.,inter-AS peering agreements) the sequence of domains for a path
(the path domain tree) will be known in advance.
The examples and scenarios used in this document are also based on
the following assumptions:
- The PCE that serves each domain in the path domain tree is known
and the set of PCEs and their relationships is propagated to each
PCE during the first exchange of path computation requests;
- Each PCE knows about any leaf LSRs in the domain it serves;
- The boundary nodes to use on the LSP are pre-determined and form
path of the path domain tree. In this version of the document we
do not consider multi-homed domains.
1.3 Requirements
This section summarizes the PCEP requirements specific to computing
inter-domain P2MP paths. In these requirements we note that the
actual computation times by any PCE implementation are outside the
scope of this document, but we observe that reducing the complexity
of the required computations has a beneficial effect on the
computation time regardless of implementation. Additionally,
reducing the number of message exchanges and the amount of
information exchanged willreduce the overall computation time for
the entire P2MP tree. We refer to the "Complexity of the
computation" as the impact on these aspects of path computation
time as various parameters of the topology and the P2MP LSP are
changed.
1. The requirements specified in [RFC5376];
1.1 PCEP must allow an SP to hide from other SPs the set
of hops within its own ASes that are traversed by an inter-AS
inter-provider TE LSP for each inter-AS TE LSP path segment an
inter-AS PCE computes, it may return to the requesting inter-AS
PCE an inter-AS TE LSP path segment from its own ASes without
detailing the explicit intra-AS hops.
Zhao, et el. [Page 4]
draft-zhao-pce-pcep-inter-domain-p2mp-procedures-00.txt March 2009
2. The computed P2MP LSP should be optimal when only considering
The paths among the BNs.
3. Grafting and pruning of multicast destinations in a domain should
have no impact on other domains and on the paths among BNs.
4. The complexity of the computing for each sub-tree within each
domain should be only dependent on the topology of the domain and
it should be independent of the domain sequences.
5. The number of PCEP request and reply messages should be
independent of the number of multicast destinations in each
domain.
6. A number of additional requirements have also been identified in
[PCE-P2MP-REQ].
1.4 Objective Functions
During the computation of a single or a set of P2MP TE LSPs a request
to meet specific optimization criteria, called an Objective Function
(OF), may be requested.
The computation of one or more P2MP TE-LSPs maybe subject to an OF in
order to select the "best" candidate paths. A variety of objective
functions have been identified as being important during the
computation of inter-domain P2MP LSPs. These are:
1. The sub-tree within each domain should be optimized.
1.1 Minimum cost tree [PCE-P2MP-REQ].
1.2 Shortest path tree [PCE-P2MP-REQ].
2. The P2MP LSP paths should be optimal while only considering the
entry and exit nodes of each domain as the transit, branch and
leaf nodes of the P2MP LSP path. (That is, the Core Tree should be
optimized.)
3. It should be possible to limit the number of entry points to a
domain.
4. It should be possible to force the branches for all leaves within
a domain to be in that domain.
Zhao, et el. [Page 5]
draft-zhao-pce-pcep-inter-domain-p2mp-procedures-00.txt March 2009
2. Terminology
This document uses PCE terminology defined in [RFC4655], [RFC4875],
and [PCEP]. Additional terms are defined below and draw on the
concepts set out for P2MP LSPs in [RFC4461].
Boundary Nodes: Each Domain has entry LSRs and exit LSRs that can
either be ABRs or ASBRs. They are defined here as Boundary Nodes
(BNs).
Core Tree: The partial P2MP Path Tree with only the BNs added and
without the leaf nodes.
Leaf Boundary Nodes: The entry boundary node in the leaf domain.
Leaf Domain: A domain containing at least one leaf node of the P2MP
LSP. (Cf. Bud Domain.)
Leaf Nodes: The LSR in any domain which is the P2MP LSP's final
destination. (all the light blue nodes)
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].
Path Domain Sequence: The known sequence of domains for a path.
PCE Sequence: The known sequence of PCEs for calcaulting a path.
PCE Topology Tree: A list of PCE Sequences which has all the PCE
Sequence for each path of the P2MP LSP path tree.
Point-to-multipoint Path Tree: A set of LSRs and TE links
that comprise the path of a P2MP TE LSP from its ingress LSR to all
of its egress LSRs.
Root Boundary Node: The egress LSR from the root domain on the path
of the P2MP LSP.
Root Domain: The domain that includes the ingress (root) LSR.
Transit Domain: A domain that has an upstream and downstream
neighbour domain. (Cf. Branch Domain and Bud Domain)
Zhao, et el. [Page 6]
draft-zhao-pce-pcep-inter-domain-p2mp-procedures-00.txt March 2009
4..Procedures
3.1 Per Domain Path Computation
Computing P2P LSPs individually is an acceptable solution for
computing a P2MP tree. Per domain path computation [RFC5152] can be
used to compute P2P multi-domain paths, but does not guarantee to
find the optimal path. Furthermore, constructing a P2MP tree from
individual source to leaf P2P LSPs does not guarantee to produce a
least-cost tree; it does produce a least-cost-to-destination tree.
This approach may be considered to have scaling issues during LSP
setup. That is, the LSP to each leaf is signaled separately, and each
border node must perform path computation for each leaf possibly
invoking a PCE (although it may re-use path fragments already used
for other leaves if this information is retained in a stateful PCE).
3.2 Backwards Recursive Path Computation
Backward recursive path computation (BRPC) [BRPC] provides a
mechanism to compute optimal P2P LSPs. This overcomes one of the
issues raised in Section 3.1, but nevertheless, a P2MP tree
constructed from individually computed optimal P2P LSPs does not
guarantee to produce a least-cost tree; it does produce a least-cost-
to-destination tree.
This approach may have scaling issues during path computation as each
the path to each leaf must be computed separately. Although path
fragments already used for other leaves may be re-used by stateful
PCEs, the information must still be transmitted in a full exchange of
PCEP messages for each leaf.
3.3.1 Core Tree Based Path Computation
A core tree based solution provides an optimal inter-domain P2MP
TE LSP and meets the requirements and OFs outlined in previous
sections.
A core tree is a path tree with nodes from each domain corresponding
to the PCE topology which satisfies the following conditions:
- The root of the core tree is the ingress LSR in the root domain;
- The leaf of the core tree is the entry node in the leaf domain;
- The transit and branch node are from the entry and exit nodes from
the transit and branch domains.
Zhao, et el. [Page 7]
draft-zhao-pce-pcep-inter-domain-p2mp-procedures-00.txt March 2009
Computing the complete P2MP LSP path tree is done in two phases:
Procedure Phase 1: P2MP LSP Core Tree Building for the Boundary Nodes
(BNs).
Procedure Phase 2: Grafting destinations to the P2MP LSP Core Tree.
Once the core tree based inter-domain tree is built. The grafting of
all the leaf nodes from each domain to the core tree can be achieved.
The algorithms to compute the optimal large core tree are outside
scope of this document. In the case that the number of domains and
the number of BNs are not big, the following BRPC based procedure can
be used to compute the core tree.
BRPC Based CoreTree Path Computation Procedure
1. Using the BRPC procedures to compute the VSPT(i) for each BN(i),
i=1 to n, where n is the total number of entry nodes for all the
leaf domains. In each VSPT(i), there are number of P(i) paths.
2. When the root PCE has computed all the VSPT(i), i=1 to n,
take one path from each VSPT and form a set of paths, we call
it a PathSet(j), j=1 to M, where M=P(1)xP(2)...xP(n);
3. For each PathSet(j), there are n paths and form these n
paths into a CoreTree(j);
4. There will be M number of CoreTrees computed from step3.
Apply the OF to each of these M CoreTrees and find the
optimal CoreTree according to the OF.
Zhao, et el. [Page 8]
draft-zhao-pce-pcep-inter-domain-p2mp-procedures-00.txt March 2009
4. Protocol Extensions for Core Tree Based Computation
The following section describes the protocol extensions for Core Tree
based inter-domain P2MP path calculation.
4.1 The Extension of RP Object
The extended format of the RP object body to include the C bit as
follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |C|O|B|R| Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLV(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RP Object Body Format
The following flags are added in this draft:
C ( P2MP Inter-domain core tree bit - 1 bit):
0: This indicates that the message is for the normal leaf
grafting/pruning;
1: This indicates that the request associated with this RP is
core tree computation request or reply
Zhao, et el. [Page 9]
draft-zhao-pce-pcep-inter-domain-p2mp-procedures-00.txt March 2009
4.2. The PCE Sequence Object
The PCE Sequence Object is added to the existing PCE protocol. A list
of this objects will represent the PCE topology tree. A list of
Sequence Objects can be exchanged between PCEs during the PCE
capability exchange or on the first path computation request message
between PCEs. In this case, the request message format needs
to changed to include the list of PCE Sequence Objects for the PCE
inter-domain P2MP calculation request.
Each PCE Sequence is can be obtained from the domain sequence for
a specific path. All the PCE sequences for all the paths of P2MP
inter-domain form the PCE Topology Tree of the P2MP LSP.
The format of the new PCE Sequence Object for IPv4 (Object-Type 3)
is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object-Class | OT |Res|P|I| Object Length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address for root PCE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address for the downstream PCE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address for the downstream PCE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| !! |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address for the PCE corresponding to the leafDomain |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The New PCE Sequence Object Body Format for IPv4
The format of the new PCE Sequence Object for IPv6 is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object-Class | OT |Res|P|I| Object Length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address for root PCE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address for the downstream PCE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address for the downstream PCE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| !! |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address for the PCE corresponding to the leafDomain |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The New PCE Sequence Object Body Format for IPv6
Zhao, et el. [Page 10]
draft-zhao-pce-pcep-inter-domain-p2mp-procedures-00.txt March 2009
5. IANA Considerations
A number of IANA considerations have been highlighted in the relevant
sections of this document. Further clarifications of these requests
will be made in a future version of this document.
6. Manageability
TBD in a future version of the draft.
6.1 Scalability Considerations
TBD in a future version of the draft.]
7. Security
TBD in a future version of the draft.
8. Acknowledgement
The authors would like to thank Adrian Farrel for his
valuable comments on this draft.
9. References
9.1. Normative References
[RFC5152] Vasseur, J.P., Ed., Ayyangar, A., Ed., and R. Zhang,
"A Per-domain path computation method for computing
Inter-domain Traffic Engineering (TE) Label Switched
Path (LSP)",
[BRPC] J.P. Vasseur, Editor, "A Backward Recursive PCE-based
Computation (BRPC) procedure to compute shortest
inter-domain Traffic Engineering Label Switched
Paths", draft-ietf-pce-brpc, work in progress.
[PCEP] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow,
A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux,
"Path Computation Element (PCE) Communication Protocol
(PCEP)", draft-ietf-pce-pcep-19 (work in progress),
Novemeber 2008.
Zhao, et el. [Page 11]
draft-zhao-pce-pcep-inter-domain-p2mp-procedures-00.txt March 2009
[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.
9.2 Informative References
[RFC4461] S. Yasukawa, Editor, "Signaling Requirements for
Point-to-Multipoint Traffic Engineered MPLS LSPs",
RFC4461, April 2006.
[RFC5376] Bitar, N., Zhang, R,. Kumaki, K,.
"Inter-AS Requirements for the Path Computation Element
Communication Protocol (PCECP)", RFC 5376, November 2008.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 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.
[PCE-P2MP-REQ] Yasukawa, S. and A. Farrel, "PCC-PCE Communication
Requirements for Point to Multipoint Multiprotocol Label
Switching Traffic Engineering (MPLS-TE)",
draft-yasukawa-pce-p2mp-req-05 (work in progress),
May 2008.
[PCE-P2MP-APP] Yasukawa, S. and A. Farrel,
"draft-ietf-pce-p2mp-app-01.txt",
draft-ietf-pce-p2mp-app (work in progress), Feb 2009.
[PCE-P2MP-EXT] Takeda, T., Chaitou M., Le Roux, J.L., Ali Z.,
Zhao, Q., King, D.,
"draft-ietf-pce-pcep-p2mp-extensions-01,work in
progress, October , 2008.
Zhao, et el. [Page 12]
draft-zhao-pce-pcep-inter-domain-p2mp-procedures-00.txt March 2009
10. Authors' Addresses
Quintin Zhao
Huawei Technology
125 Nagog Technology Park
Acton, MA 01719
US
Email: qzhao@huawei.com
David Amzallag
British Telecommunications plc
Email: david.amazallag@bt.com
Daniel King
Old Dog Consulting
Email: daniel@olddog.co.uk
11. 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.
Zhao, et el. [Page 13]
draft-zhao-pce-pcep-inter-domain-p2mp-procedures-00.txt March 2009
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.
12. Disclaimer of Validity
All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
13. 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.
Zhao, et el. [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-23 09:57:32 |