Network work group Mach Chen
Internet Draft Huawei Technologies Co.,Ltd
Expires: April 2007 October 12, 2006
Inter-AS PCE Path Sequence Autoexplore
draft-chen-pce-interas-pce-sequence-autoexplore-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
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
This Internet-Draft will expire on April 12, 2007.
Abstract
In Inter-AS scenario, as usual, multiple Path Computation Elements
(PCEs) will take part in path computation. [PCE-DISCO-OSPF], [PCE-
DISCO-ISIS],PCE-DISCO-BGP] or some other means can be used to
discover all underling PCEs, but there is lack of solutions to find
out those PCEs and their sequence which are engaged in computing an
end-to-end inter-AS TE LSP. This document proposes a solution to
identify these PCEs and their sequence which can be used to compute a
TE LSP across multiple ASes.
Mach Expires April 12, 2007 [Page 1]
Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
Table of Contents
1. Introduction..................................................3
2. General assumptions...........................................4
3. Procedure.....................................................4
3.1. PCEP extension...........................................4
3.1.1. PCE Path Sequence Explore Request(PCPSReq) message..5
3.1.2. PCE Path Sequence Explore Reply(PCPSRep) message....5
3.1.3. Extension to PCReq message..........................6
3.2. PCE Path Sequence Explore................................7
3.3. PCE Path Sequence Explore flows..........................10
4. Objects format................................................12
4.1. END-POINTS object........................................12
4.2. SVEC object..............................................12
4.3. RP object................................................12
4.4. RRO object...............................................13
4.5. PCPSO object.............................................13
5. Security Considerations.......................................13
6. IANA Considerations...........................................13
6.1. PCPS Messages............................................13
7. References....................................................14
7.1. Normative References.....................................14
7.2. Informative References...................................14
Author's Addresses...............................................15
Intellectual Property Statement..................................15
Disclaimer of Validity...........................................16
Copyright Statement..............................................16
Acknowledgment...................................................16
Mach Expires April 12, 2007 [Page 2]
Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006
1. Introduction
+--------+ +--------+ +--------+
| AS1 | | AS2 | | AS5 |
| | | | | |
| +====+ | | | | +====+ |
| | Ra | |-------| |-------| | Rb | |
| +====+ | | | | +====+ |
| +====+ | | +====+ | | +====+ |
| |PCE1| | | |PCE2| | | |PCE5| |
| +====+ | | +====+ | | +====+ |
+--------+ +--------+ +--------+
\ / /
\ / /
\ / /
\ / /
+--------+ +--------+
| AS3 | | AS4 |
| | | |
| |-------| |
| +====+ | | +====+ |
| |PCE3| | | |PCE4| |
| +====+ | | +====+ |
+--------+ +--------+
Figure 1: Inter-AS TE and multiple PCE scenario
Multiple Protocol Label Switching (MPLS) Inter-AS Traffic Engineering
as a key requirement has been stated in [INERAS-TE-REG], and Path
Computation Element (PCE) has the ability to compute a TE LSP
spanning multiple ASes. These ASes MAY be under one Service
Provider(SP) administration or the administration of different SPs.
[PCE-ARCH] has defined several models which can be used to satisfy
different scenarios, one of them is "multiple PCE path computation"
where multiple PCEs cooperate in computing a TE LSP across multiple
domains.
[PCE-DISCO-OSPF], [PCE-DISCO-ISIS] and [PCE-DISCO-BGP] has proposed
some mechanisms to discover all underling PCEs automatically, but it
is not enough to know this information only. Consider that we want to
compute a TE LSP spanning multiple ASes and each AS has its own PCE
responsible for path computation. As illustrated above in Figure 1,
there are five ASes and five PCEs. We want to set up an end-to-end TE
LSP from Ra to Rb. Obviously, there are several possible paths we MAY
get, such as AS1->AS2->AS5, AS1->AS3-AS4->AS5, etc. According to
existing PCE discovery mechanisms we only know that a specific PCE
belongs to an AS and the PCE has some special capabilities. But we
SHOULD also know which PCEs are engaged to compute such an end-to-end
Mach Expires April 12, 2007 [Page 3]
Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006
path and where is the next PCE when we need to send a PCE Path
Request message. Otherwise, we will fail to compute such a end-to-end
path.
So, in order to perform path computation in such scenario, we need to
find out those PCEs which are engaged in computing a specific TE LSP,
and the sequence of those PCEs. As pointed out in [BPRC], before
sending path computation request to the next PCE, we need to know
where the next PCE is. Static configuration is an alternative method,
but it may not be desirable in some cases.
Therefore, it is desirable to find a way that can explore those
underling PCEs and their sequence for a specific TE LSP dynamically.
This document proposes a method which could easily explore those
underling PCEs and their sequence for a specific end-to-end TE LSP
automatically. The main idea is that a PCE uses the BGP AS_PATH
attribute to find out those PCEs and track their sequence.
2. General assumptions
In the rest of this document, there are some assumptions as follows:
- All the underling PCEs can be discovered by [PCE-DISCO-OSPF],
[PCE-DISCO-ISIS], [PCE-DISCO-BGP] or some other means (which is
outside the scope of this document), and each PCE is identified
with the AS which it belongs to.
- As stated in [INTER-AS-PCE] each Inter-AS PCE is assumed to run
BGP protocol (In fact, an Inter-AS PCE only needs to receive
routing updates and almost doesn't send any updates if it just is
a path computation engine. So, running BGP in an Inter-AS PCE is
not a problem.), so each Inter-AS PCE has full routing information.
- Each AS MAY have multiple PCEs, but for a specific TE LSP
computation we can make a decision according to the capability of
the PCE which one is the best(how to choose the best PCE is
outside the scope of this document).
3. Procedure
3.1. PCEP extension
In order to explore those PCEs and their sequence for a specific TE
LSP, in this document we define two new PCEP messages, namely PCE
Path Sequence Explore Request (PCPSReq) message and PCE Path Sequence
Explore Reply (PCPSRep) message. At the same time, we need to do some
extensions to PCReq message.
Mach Expires April 12, 2007 [Page 4]
Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006
3.1.1. PCE Path Sequence Explore Request(PCPSReq) message
A PCE Path Sequence Explore Request message (also referred to as a
PCPSReq message) is a message sent by a PCE to other PCEs(also
referred to as helper PCE) to explore the PCE Path Sequence (also
referred to as PCPS) for a specific TE LSP computation. The Message-
Type field of the PCEP common header for the PCPSReq message is set
to <TBD>.
A PCPSReq message MUST contain two objects: the END-POINTS object and
the RP object. Other objects are optional.
The format of a PCPSReq message is as follows:
<PCPSReq Message>::= <Common Header>
[<SVEC-list>]
<request-list>
Where:
<svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
[<END-POINTS>]
[<RRO>]
The SVEC, RP, END-POINTS, and RRO objects are defined in Section 4.
3.1.2. PCE Path Sequence Explore Reply(PCPSRep) message
A PCE Path Sequence Explore Reply message (also referred to as a
PCPSReq message) is a message sent by a PCE to a requesting PCE in
response to a previously received PCPSReq message. The Message-Type
field of the PCEP common header for the PCPSRep message is set to
<TBD>.
A PCPSRep message MUST contain two objects: the RP object and RRO
object. Other objects are optional.
The format of PCPSRep message is as follows:
<PCPSRep Message> ::= <Common Header>
[<svec-list>]
<response-list>
where:
Mach Expires April 12, 2007 [Page 5]
Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006
<svec-list>::=<SVEC>[<svec-list>]
<response-list>::=<response>[<response-list>]
<response>::=<RP>
[<NO-PATH>]
[<path-list>]
<path-list>::=<path>[<path-list>]
<path>::= <RRO>
The SVEC, RP, and RRO objects are defined in Section 4.
3.1.3. Extension to PCReq message
In order to finish the computation of a TE LSP spanning multiple ASes,
a PCReq message SHOULD carry a new object termed PCE Path Sequence
Object (PCPSO).
The format of a PCReq message is as follows:
<PCReq Message>::= <Common Header>
[<SVEC-list>]
<request-list>
where:
<svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>]
Mach Expires April 12, 2007 [Page 6]
Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006
<request>::= <RP>
[<END-POINTS>]
[<LSPA>]
[<BANDWIDTH>]
[<METRIC>]
[<RRO>]
[<BANDWIDTH>]
[<IRO>]
[<PCPSO>]
The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, ERO, and IRO
objects are defined in [PCEP] Section 7. The PCPSO object is defined
in Section 4.
3.2. PCE Path Sequence Explore
In section 2, we have made an assumption that each PCE needs to run
BGP protocol, so each PCE has full routing information.
When a PCE receives a Path Computation Request (PCReq) message from a
PCC, it MUST make a decision whether it could finish the path
computation by itself or need the help of other PCEs (the destination
node is in anther AS or some other factors, the detail procedure is
outside the scope of this document). If it is latter, the PCE MUST
find out those PCEs (also referred to as helper PCE) and the PCPS of
those PCES. The detail procedure is as follows:
First of all, according to the destination address where a specific
TE LSP will reach, the PCE (also referred to as an original PCE)
finds out all routes which can reach the destination by looking up
its local BGP rib. These routes not only include the best route, but
also non best routes. Then, the original PCE iterates these BGP
routes and checks their AS_PATH attribute. If the first segment of
AS_PATH of type is AS_SEQUENCE, the last element of the AS_SEQUENCE
is the AS (referred to as next AS) where the BGP route traversed
lastly. According to this AS number, it's easy to find out the PCE
identified by this AS number from its local PCE database which
contains all underling PCE infomation collected by [PCE-DISCO-OSPF],
[PCE-DISCO-ISIS], [PCE-DISCO-BGP] or some other means. There MAY be
multiple routes which could reach the destination node, so multiple
PCEs MAY be found out. After finding these helper PCEs, the original
PCE sends a PCPSReq message to these helper PCEs respectively.
When a helper PCE receives a PCPSReq message, the helper PCE checks
the PCPSReq message and extracts the address info of destination node
from END-POINTS object, according the destination address the helper
PCE continues doing the same operation as the original PCE does. That
Mach Expires April 12, 2007 [Page 7]
Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006
is looking up its local BGP rib to find out specific BGP routes which
can reach the destination node, iterating these BGP routes to find
out specific next AS numbers and according to these next AS numbers
to find out relative helper PCEs from their local PCE databases.
After that, the helper PCE will send a PCPSReq message to its helper
PCEs respectively.
If a helper PCE finds that the routes in its local BGP rib doesn't
contain any AS_PATH information, it concludes that this helper PCE
itself is the final PCE we want to track. Then the final PCE sends a
PCPSRep message with RRO object containing its PCE address to the
requesting PCE in response to a previously received PCPSReq message.
When a PCE (referred to as intermediate PCE) receives a PCPSRep
message, after adding its PCE address into the RRO object, the
intermediate PCE relays the PCPSRep to the requesting PCE in response
to a previously received PCPSReq message. All the intermediate PCEs
will do the same operation until the PCPSRep message relayed to the
original PCE. On receiving all PCPSRep messages, the original PCE can
get all underling PCE Path Sequences (PCPSes) from the RRO object in
each PCPSRep message.
If the received PCPSReq message has errors, a PCE MUST reply with
PCErr message immediately. The PCErr messages are defined in [PCEP]
section 6.7.
Here we give an example to detail the procedure of PCPS exploring. As
illustrated above in Figure 1, there are five ASes (from AS1 to AS5)
and every AS has its own PCE. Let's consider this scenario, says that
Ra wants to establish a TE LSP to Rb, Ra as Path Computation
Client(PCC) sends a path computation request to its default PCE,
namely PCE1(how to choose the default PCE is outside the scope of
this document). As usual, consider the confidentiality and
administration requirements, PCE1 MAY hasn't the fully TE information
about other ASes. So PCE1 can't compute such a TE LSP spanning
multiple ASes only by itself, it needs to cooperate with other PCEs.
When PCE1 receives the PCReq from its PCC Ra, PCE1 is the original
PCE. At first, PCE1 looks up its local BGP rib according to Rb's IP
address. Suppose that PCE1 finds out two BGP routes, one is from AS2,
the other is from AS3. According to these BGP routes' AS_PATH
attribute, PCE1 can find out two helper PCEs relative to AS2 and AS3
respectively. One is PCE2, and the other is PCE3. Then, PCE1 sends a
PCPSReq message to PCE2 and PCE3 respectively.
When PCE2 or PCE3 receives the PCPSReq message, they will check if
the request message is valid or not. If the message has errors, they
Mach Expires April 12, 2007 [Page 8]
Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006
will send a PCErr message to PCE1 immediately. If the message is
valid, they will extract Rb's IP address from the PCPSReq message and
continue to do the same operation as PCE1 does. That is PCE2 will try
to find out its helper PCEs(MAY be PCE3 and PCE5) and PCE3 will try
to find out its helper PCEs(MAY be PCE2 and PCE4) too. The PCE2 will
send a PCPSReq message to PCE3 and PCE5 respectively, and PCE3 will
send a PCPSReq message to PCE2 and PCE4 respectively. When all
PCPSReq messages reach PCE5, PCE5 will find out the final PCE is
itself. So PCE5 as the final PCE sends a PCPSRep message with RRO
object containing its IP address to every requesting PCE in response
to every previously received PCPSReq message. After adding their IP
address into RRO objects, PCE2, PCE3 and PCE4 as the intermediate PCE
will relay these PCPSReq messages till to the original PCE, namely
PCE1. Finally, there MAY be several PCPSes found, they are probably
as follows:
PCE1-PCE2 PCE5
PCE1-PCE3 PCE4 PCE5
PCE1-PCE3 PCE2-PCE5
PCE1-PCE2 PCE3-PCE4-PCE5
When PCE1 get these PCPSes info, PCE1 can choose one or multiple
PCPSes (MAY be based on the best shortest path, how to choose is
outside the scope of this document) to perform path computation for
the TE LSP from Ra to Rb. At the same time, when PCE1 sends a PCReq
message to its helper PCEs, it SHOULD carry a PCPSO object and before
these helper PCEs send or relay the PCReq message to their helper
PCEs, they SHOULD omit themselves from the PCPSO object. The PCReq
message will be sent along with the chosen PCPS to a final PCE, so we
have enough information to finish an end-to-end Inter-AS path
computation.
PCPSO object is defined in Section 4.5.
Mach Expires April 12, 2007 [Page 9]
Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006
3.3. PCE Path Sequence Explore flows
+-+-+-+ +-+-+-+ +-+-+-+
|O-PCE| |I-PCE| ...... |F-PCE|
+-+-+-+ +-+-+-+ +-+-+-+
| | |
|PCPSReq message->| |
| |1) PCPSReq received |
| | |
| |2) Not the final PCE |
| | |
| |3) Send a PCPSReq to next |
| |I-PCE based on AS-PATH |
| | |1) PCPSReq received
| |----- PCPSReq message---->|
| | |2) Is the final PCE
| | |
| | |3) Positive reply
| |<---- PCPSRep message ----|send to a requesting
| | (Positive reply) |I-PCE(with its IP
| | |address)
| |1) PCPSRep received |
| | |
| |2) Relay positive reply to|
| |a requesting O-PCE(adding |
| |its IP address into the |
| |reply message before send |
| | |
|<-PCPSRep message| |
| (Positive reply)| |
Figure 2: Successful Path Sequence Explore
Mach Expires April 12, 2007 [Page 10]
Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006
+-+-+-+ +-+-+-+ +-+-+-+
|O-PCE| |I-PCE| ...... |F-PCE|
+-+-+-+ +-+-+-+ +-+-+-+
| | |
|PCPSReq message->| |
| |1) PCPSReq received |
| | |
| |2) Some errors |
| | |
| |3) Negative reply sent to |
| |O-PCE |
|<-PCPSRep message| |1) PCPSReq received
| (Negetive reply)|----- PCPSReq message---->|
| | |2) Some errors
| | |
| | |3) Negative reply
| | |send to a requesting
| |<---- PCPSRep message ----|I-PCE
| | (Negetive reply) |
| | |
| |1) PCPSRep received |
| | |
| |2) Relay Negative reply to|
| |a requesting O-PCE |
| | |
| | |
|<-PCPSRep message| |
| (Negative reply)| |
Figure 3: Unsuccessful Path Sequence Explore
The above figures are the general description about PCE Path
exploring.
O-PCE: means original PCE.
I-PCE: means intermediate PCE.
F-PCE: means final PCE.
F-PCE and I-PCEs are helper PCEs of O-PCE as described in Section 3.2.
Positive and Negative has same means as described in Section 5.2.3 of
[PCEP].
Mach Expires April 12, 2007 [Page 11]
Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006
4. Objects format
In this document, it just defines a new object named PCPSO object.
The other objects have been defined in [PCEP] section 7, and here we
only do a little bit extension to some of them.
4.1. END-POINTS object
The contents of this object are identical in encoding to the contents
of the END-POINTS Object defined in [PCEP].
4.2. SVEC object
The contents of this object are identical in encoding to the contents
of the SVEC Object defined in [PCEP].
4.3. RP object
RP object has been defined in [PCEP] section 7, the format of the RP
object body 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |C|Q|R|N|O|B|R| Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLV(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: RP object body format
In this document, we add 3 new bits to flag field of RP object. They
are defined as follows:
C (Synchronization, 1 bit): when set, a PCE receives a PCPSReq
message, it can't reply to the requesting PCE until it received the
specific PCPSRep message from its helper PCE. But when a PCE receives
a PCPSReq message with errors, it will reply with PCErr message to
the requesting PCE immediately. Default C bit is set.
Q (PCPSReq carry RRO or not, 1 bit): when set, PCPSReq MUST carry RRO
object, the original PCE and helper PCE will add their IP address
Mach Expires April 12, 2007 [Page 12]
Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006
into the RRO object before sending a PCPSReq message to their helper
or final PCE. So when a PCPSReq message reaches to a final PCE, the
final PCE can get the PCPS from RRO object in PCPSReq message.
Therefore, the final PCE can send this info direct to original PCE
without the helping of intermediate PCEs. This is an alternative
method to get the PCPS information. Default Q bit is cleared.
R (PCPSRep carry RRO or not, 1 bit): when set, PCPSRep MUST carry RRO
object, the final PCE and intermediate PCE will add their IP address
into the RRO object before sending a PCPSRep message to a requesting
PCE. Default R bit is set.
4.4. RRO object
The RRO object is used to record PCE Path Seqeunce (PCPS).
The contents of this object are identical in encoding to the contents
of the Route Record Object defined in [RFC3209], [RFC3473] and
[RFC3477]. That is, the object is constructed from a series of sub-
objects.
4.5. PCPSO object
The PCPSO object is optional and can be used to carry PCPS info which
can be used to direct where a PCE sends a PCReq message to. The
contents of this object are identical in encoding to the contents
of the Explicit Route Object defined in [RFC3209], [RFC3473] and
[RFC3477]. That is, the object is constructed from a series of sub-
objects. Each sub-object expresses a PCE.
5. Security Considerations
This extension to PCE does not change the underlying security issues.
6. IANA Considerations
6.1. PCPS Messages
Each PCPS message has a Message-Type.
Value Meaning
8 PCE Path Sequence Explore Request.
9 PCE Path Sequence Explore Reply.
Mach Expires April 12, 2007 [Page 13]
Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006
7. References
7.1. Normative References
[BGP-4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol
4 (BGP-4)", RFC 4271, January 2006.
[PCE-ARCH] A. Farrel, J.-P. Vasseur, J. Ash, " A Path Computation
Element (PCE)-Based Architecture ", RFC 4655, August 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
7.2. Informative References
[BRPC] Vasseur,J., Zhang,R., Bitar, N., Le Roux,JL., "A Backward
Recursive PCE-based Computation (BRPC) procedure to compute
shortest inter-domain Traffic Engineering Label Switched
Paths" draft-vasseur-pce-brpc-01 ( work in progress )June
2006
[PCE-DISCO-OSPF] Le Roux,JL., Vasseur,J., Ikejiri,Y., and Zhang,R.,
"OSPF protocol extensions for Path Computation Element (PCE)
Discovery" draft-ietf-pce-disco-proto-ospf-00 (work in
progress) Sep 2006.
[PCE-DISCO-ISIS] Le Roux,JL., Vasseur,J., Ikejiri,Y., and Zhang,R.,
"ISIS protocol extensions for Path Computation Element (PCE)
Discovery" draft-ietf-pce-disco-proto-isis-00 (work in
progress) Sep 2006.
[PCE-DISCO-BGP] Vijayanand,C., and Bhattacharya,S., "BGP Protocol
extensions for PCE Discovery across Autonomous systems"
draft-vijay-somen-pce-disco-proto-bgp-00.txt June 2006.
[INTERAS-TE-REQ] Zhang and Vasseur, "MPLS Inter-AS Traffic
Engineering Requirements", RFC4216, November 2005.
Mach Expires April 12, 2007 [Page 14]
Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006
[CCAMP-INTER-DOMAIN-TE] Ayyangar, A. and J. Vasseur, "Inter domain
GMPLS Traffic Engineering - RSVP-TE extensions",draft-ietf-
ccamp-inter-domain-rsvp-te-03 (work in progress), March
2006.
[PCE-COMM-GEN-REQ] Roux,J. and J. Ash, "PCE Communication Protocol
Generic Requirements", draft-ietf-pce-comm-protocol-gen-
reqs-06 (work in progress), May 2006.
[PCE-DISCO-REQ] Roux,J., "Requirements for Path Computation Element
(PCE) Discovery", draft-ietf-pce-discovery-reqs-05 (work in
progress), June 2006.
[INTER-AS-PCE] Bitar,N., Zhang,R., Kumaki,K., "Inter-AS PCE
Requirements", draft-bitar-zhang-interas-pce-req-00.txt
(work in progress), October 2005.
Author's Addresses
Mach Chen
Huawei Technologies Co.,Ltd
KuiKe Building, No.9 Xinxi Rd.,
Shang-Di Information Industry Base,
Hai-Dian District Beijing P.R. China 100085
Email: mach@huawei.com
Intellectual Property Statement
The IETF 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
this 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. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR 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.
Mach Expires April 12, 2007 [Page 15]
Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006
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
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Mach Expires April 12, 2007 [Page 16]