draft-ietf-pce-global-concurrent-optimization-01.txt   draft-ietf-pce-global-concurrent-optimization-02.txt 
Network Working Group Y. Lee Network Working Group Y. Lee
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track JL. Le Roux Intended status: Standards Track JL. Le Roux
Expires: May 5, 2008 France Telecom Expires: August 24, 2008 France Telecom
D. King D. King
Aria Networks Aria Networks
E. Oki E. Oki
NTT NTT
November 2, 2007 February 21, 2008
Path Computation Element Communication Protocol (PCECP) Requirements and Path Computation Element Communication Protocol (PCECP) Requirements and
Protocol Extensions In Support of Global Concurrent Optimization Protocol Extensions In Support of Global Concurrent Optimization
draft-ietf-pce-global-concurrent-optimization-01.txt draft-ietf-pce-global-concurrent-optimization-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 40 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 5, 2008. This Internet-Draft will expire on August 24, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
The Path Computation Element (PCE) is a network component, The Path Computation Element (PCE) is a network component,
application, or node that is capable of performing path computations application, or node that is capable of performing path computations
at the request of Path Computation Clients (PCCs). The PCE is at the request of Path Computation Clients (PCCs). The PCE is
applied in Multiprotocol Label Switching Traffic Engineering applied in Multiprotocol Label Switching Traffic Engineering
(MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to
determine the routes of Label Switched Paths (LSPs) through the determine the routes of Label Switched Paths (LSPs) through the
network. The Path Computation Element Communication Protocol (PCEP) network. The Path Computation Element Communication Protocol (PCEP)
skipping to change at page 3, line 21 skipping to change at page 3, line 21
3.2. Re-optimization of Existing Networks . . . . . . . . . . . 8 3.2. Re-optimization of Existing Networks . . . . . . . . . . . 8
3.2.1. Reconfiguration of the Virtual Network Topology 3.2.1. Reconfiguration of the Virtual Network Topology
(VNT) . . . . . . . . . . . . . . . . . . . . . . . . 8 (VNT) . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.2. Traffic Migration . . . . . . . . . . . . . . . . . . 8 3.2.2. Traffic Migration . . . . . . . . . . . . . . . . . . 8
3.3. Greenfield Optimization . . . . . . . . . . . . . . . . . 9 3.3. Greenfield Optimization . . . . . . . . . . . . . . . . . 9
3.3.1. Single-layer Traffic Engineering . . . . . . . . . . . 10 3.3.1. Single-layer Traffic Engineering . . . . . . . . . . . 10
3.3.2. Multi-layer Traffic Engineering . . . . . . . . . . . 10 3.3.2. Multi-layer Traffic Engineering . . . . . . . . . . . 10
4. PCECP Requirements . . . . . . . . . . . . . . . . . . . . . . 11 4. PCECP Requirements . . . . . . . . . . . . . . . . . . . . . . 11
5. Protocol extensions for support of global concurrent 5. Protocol extensions for support of global concurrent
optimization . . . . . . . . . . . . . . . . . . . . . . . . . 15 optimization . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Global Objective Function (GOF) Specification . . . . . . 16 5.1. Global Objective Function (GOF) Specification . . . . . . 15
5.2. Indication of Global Concurrent Optimization Requests . . 16 5.2. Indication of Global Concurrent Optimization Requests . . 16
5.3. Request for the order of LSP . . . . . . . . . . . . . . . 16 5.3. Request for the order of LSP . . . . . . . . . . . . . . . 16
5.4. The Order Response . . . . . . . . . . . . . . . . . . . . 17 5.4. The Order Response . . . . . . . . . . . . . . . . . . . . 17
5.5. GLOBAL CONSTRAINTS (GC) Object . . . . . . . . . . . . . . 19 5.5. GLOBAL CONSTRAINTS (GC) Object . . . . . . . . . . . . . . 19
5.6. Error Indicator . . . . . . . . . . . . . . . . . . . . . 20 5.6. Error Indicator . . . . . . . . . . . . . . . . . . . . . 20
5.7. NO-PATH Indicator . . . . . . . . . . . . . . . . . . . . 21 5.7. NO-PATH Indicator . . . . . . . . . . . . . . . . . . . . 21
6. Manageability Considerations . . . . . . . . . . . . . . . . . 23 6. Manageability Considerations . . . . . . . . . . . . . . . . . 22
6.1. Control of Function and Policy . . . . . . . . . . . . . . 23 6.1. Control of Function and Policy . . . . . . . . . . . . . . 22
6.2. Information and Data Models, e.g. MIB module . . . . . . . 23 6.2. Information and Data Models, e.g. MIB module . . . . . . . 22
6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 23 6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 22
6.4. Verifying Correct Operation . . . . . . . . . . . . . . . 23 6.4. Verifying Correct Operation . . . . . . . . . . . . . . . 22
6.5. Requirements on Other Protocols and Functional 6.5. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . . 24 Components . . . . . . . . . . . . . . . . . . . . . . . . 23
6.6. Impact on Network Operation . . . . . . . . . . . . . . . 24 6.6. Impact on Network Operation . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . . 28 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . . 28 10.2. Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 31 Intellectual Property and Copyright Statements . . . . . . . . . . 30
1. Terminology 1. Terminology
The terminology explained herein complies with [RFC4655]. The terminology explained herein complies with [RFC4655].
PCC: Path Computation Client: Any client application requesting a PCC: Path Computation Client: Any client application requesting a
path computation to be performed by a Path Computation Element. path computation to be performed by a Path Computation Element.
PCE: Path Computation Element: An entity (component, application or PCE: Path Computation Element: An entity (component, application or
network node) that is capable of computing a network path or route network node) that is capable of computing a network path or route
skipping to change at page 15, line 11 skipping to change at page 15, line 11
allow indicating LSPs for which make-before-break allow indicating LSPs for which make-before-break
reoptimization is not possible (this will be deduced from the reoptimization is not possible (this will be deduced from the
LSP setup and deletion orders). LSP setup and deletion orders).
5. Protocol extensions for support of global concurrent optimization 5. Protocol extensions for support of global concurrent optimization
This section provides protocol extensions for support of global This section provides protocol extensions for support of global
concurrent optimization. Protocol extensions discussed in this concurrent optimization. Protocol extensions discussed in this
section are built on [PCEP]. section are built on [PCEP].
The format of a PCReq message is currently as follows per [PCEP]:
<PCReq Message>::= <Common Header>
[<SVEC-list>]
<request-list>
where:
<SVEC-list>::=<SVEC> [<SVEC-list>]
<request-list>::=<request> [<request-list>]
<request>::=<RP>
[<END-POINTS>]
[<LSPA>]
[<BANDWIDTH>]
[<METRIC>]
[<RRO>]
[<IRO>]
[<LOAD-BALANCING>]
The format of a PCReq message after incorporating new requirements The format of a PCReq message after incorporating new requirements
for support of global concurrent optimization is as follows: for support of global concurrent optimization is as follows:
<PCReq Message>::=<Common Header> <PCReq Message>::=<Common Header>
[<SVEC-list>] [<SVEC-list>]
<request-list> <request-list>
The <SVEC-list> is changed as follows: The <SVEC-list> is changed as follows:
<SVEC-list>:: =<SVEC> <SVEC-list>:: =<SVEC>
[<OF>] [<OF>]
[<GC>] [<GC>]
[<XRO>] [<XRO>]
[<SVEC-list>] [<SVEC-list>]
Note that three optional objects are added, following the SVEC Note that three optional objects are added, following the SVEC
object: the OF (Objective Function) object, which is defined in object: the OF (Objective Function) object, which is defined in
[PCE-OF], the GC (Global Constraints) object, which is defined in [PCE-OF], the GC (Global Constraints) object, which is defined in
this document (section 5.5), as well as the eXclude Route Object this document (section 5.5), as well as the eXclude Route Object
(XRO) which is defined in [PCE-XRO]. Details of this change will be (XRO) which is defined in [PCE-XRO]. Details of this change will be
discussed in the following sections discussed in the following sections.
Note also that when the XRO is global to a SVEC, and F bit is set, it
should be allowed to specify multiple RRO objects in the PCReq
message.
5.1. Global Objective Function (GOF) Specification 5.1. Global Objective Function (GOF) Specification
The global objective function can be specified in the PCEP Objective The global objective function can be specified in the PCEP Objective
Function (OF) object, defined in [PCE-OF]. The OF object includes a Function (OF) object, defined in [PCE-OF]. The OF object includes a
16 bit Objective Function identifier. As per discussed in [PCE-OF], 16 bit Objective Function identifier. As per discussed in [PCE-OF],
objective function identifier code points are managed by IANA. objective function identifier code points are managed by IANA.
Two global objective functions are defined in this document and their Two global objective functions are defined in this document and their
identifier should be assigned by IANA (suggested value) identifier should be assigned by IANA (suggested value)
skipping to change at page 16, line 33 skipping to change at page 16, line 21
* Note: This can be achieved by the following objective function: * Note: This can be achieved by the following objective function:
minimize max over all links {(C(i)-A(i))/C(i)} where C(i) is the link minimize max over all links {(C(i)-A(i))/C(i)} where C(i) is the link
capacity for link i and A(i) is the total bandwidth allocated on link capacity for link i and A(i) is the total bandwidth allocated on link
i.) i.)
5.2. Indication of Global Concurrent Optimization Requests 5.2. Indication of Global Concurrent Optimization Requests
All the path requests in this application should be indicated so that All the path requests in this application should be indicated so that
the global objective function and all of the global constraints are the global objective function and all of the global constraints are
applied to each of the requested path computation. In order to applied to each of the requested path computation. This can be
support this requirement, a new flag is defined in the SVEC object: indicated implicitly by placing the GCO related objects (GOF, GC or
XRO) after the SVEC object. That is, if any of these objects follows
C flag (1 bit): This is a new flag in the SVEC object. When C flag the SVEC object in the PCReq message, all of the requested path
is set, this indicates that all of the path requests listed in the computations specified in the SVEC object are subject to GOF, GC or
body of the SVEC object should be computed applying the global XRO.
constraints and the global objective function.
When the C Flag is set in the SVEC Object, the OF and the GC objects,
if included, should directly follow the SVEC Object.
5.3. Request for the order of LSP 5.3. Request for the order of LSP
In order to minimize disruption associated with bulk path In order to minimize disruption associated with bulk path
provisioning, the PCC may indicate to the PCE that the response MUST provisioning, the PCC may indicate to the PCE that the response MUST
be ordered. That is, the PCE has to include the order in which LSPs be ordered. That is, the PCE has to include the order in which LSPs
MUST be moved so as to minimize traffic disruption. To support such MUST be moved so as to minimize traffic disruption. To support such
indication a new flag, the D flag, is defined in the RP object as indication a new flag, the D flag, is defined in the RP object as
follows: follows:
skipping to change at page 17, line 18 skipping to change at page 17, line 4
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 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 |D|M|F|O|B|R| Pri | | Reserved | Flags |D|M|F|O|B|R| Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number | | Request-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLV(s) // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: RP object body format in the PCReq Message
Figure 5: RP object body format in the PCReq Message
D bit (orDer - 1 bit): when set, in a PCReq message, the requesting D bit (orDer - 1 bit): when set, in a PCReq message, the requesting
PCC requires the PCE to specify in the PCRep message the order in PCC requires the PCE to specify in the PCRep message the order in
which this particular path request is to be provisioned relative to which this particular path request is to be provisioned relative to
other requests. other requests.
M bit (Make-before-break - 1 bit): when set, this indicates that a M bit (Make-before-break - 1 bit): when set, this indicates that a
make-before-break reoptimization is required for this request. make-before-break reoptimization is required for this request.
When M bit is not set, this implies that a break-before-make When M bit is not set, this implies that a break-before-make
skipping to change at page 18, line 17 skipping to change at page 17, line 38
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |D|M|F|O|B|R| Pri | | Reserved | Flags |D|M|F|O|B|R| Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number | | Request-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Order TLV (Optional TLV) // // Order TLV (Optional TLV) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: RP object body format in the PCRep Message Figure 5: RP object body format in the PCRep Message
The Order TLV is an optional TLV in the RP object, that indicates the The Order TLV is an optional TLV in the RP object, that indicates the
order in which the old LSP must be removed and the new LSP must be order in which the old LSP must be removed and the new LSP must be
setup during a reoptimization. It is carried in the PCRep message in setup during a reoptimization. It is carried in the PCRep message in
response to a reoptimization request. response to a reoptimization request.
The Order TLV SHOULD be included in the RP object in the PCRep The Order TLV SHOULD be included in the RP object in the PCRep
message if the D bit is set in the RP object in the PCReq message. message if the D bit is set in the RP object in the PCReq message.
The format of the Order TLV is as follows: The format of the Order TLV is as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delete Order | | Delete Order |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Order | | Setup Order |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type To be defined by IANA (suggested value = ) Type To be defined by IANA (suggested value = )
Length Variable Length Variable
Value Orders in which the old path should be removed Value Orders in which the old path should be removed
and the new path should be setup and the new path should be setup
Figure 7: The Order TLV in the RP object in the PCRep Message Figure 6: The Order TLV in the RP object in the PCRep Message
Delete Order: 32 bit integer that indicates the order in which the Delete Order: 32 bit integer that indicates the order in which the
old LSP should be removed old LSP should be removed
Setup Order: 32 bit integer that indicates the order in which the new Setup Order: 32 bit integer that indicates the order in which the new
LSP should be setup LSP should be setup
The delete order should not be equal to the setup order. If the The delete order should not be equal to the setup order. If the
delete order is higher than the setup order, this means that the delete order is higher than the setup order, this means that the
reoptimization can be done in a make-before-break manner, else it reoptimization can be done in a make-before-break manner, else it
cannot be done in a make-before-break manner. cannot be done in a make-before-break manner.
For a new LSP the delete order is not applicable. The value 0 is
designated to specify this case. When the value of the delete order
is 0, it implies that the resulting LSP is a new LSP.
To illustrate, consider a network with two established requests: R1 To illustrate, consider a network with two established requests: R1
with path P1 and R2 with path P2. During a reoptimization the PCE with path P1 and R2 with path P2. During a reoptimization the PCE
may provide the following ordered reply: may provide the following ordered reply:
R1, path P1', remove order 1, setup order 4 R1, path P1', remove order 1, setup order 4
R2, path P2', remove order 3, setup order 2 R2, path P2', remove order 3, setup order 2
This indicates that the NMS should do the following sequence of This indicates that the NMS should do the following sequence of
tasks: tasks:
skipping to change at page 19, line 38 skipping to change at page 19, line 15
make-before-break manner. make-before-break manner.
5.5. GLOBAL CONSTRAINTS (GC) Object 5.5. GLOBAL CONSTRAINTS (GC) Object
The Global Constraints (GC) Object is used in a PCReq message to The Global Constraints (GC) Object is used in a PCReq message to
specify the necessary global constraints that should be applied to specify the necessary global constraints that should be applied to
all individual path computations for a global concurrent path all individual path computations for a global concurrent path
optimization request. optimization request.
GLOBAL CONSTRAINT Object-Class is to be assigned by IANA (recommended GLOBAL CONSTRAINT Object-Class is to be assigned by IANA (recommended
value=21) value=22)
GLOBAL CONSTRAINT Object-Type is to be assigned by IANA (recommended GLOBAL CONSTRAINT Object-Type is to be assigned by IANA (recommended
value=1) value=1)
The format of the GC object body that includes the global constraints The format of the GC object body that includes the global constraints
is as follows: is as follows:
0 1 2 3 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 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 | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MH | MU | mU | OB | | MH | MU | mU | OB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLV(s) // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: GC body object format Figure 9: GC body object format
MH (Max Hop: 8 bits): 8 bit integer that indicates the maximum hop MH (Max Hop: 8 bits): 8 bit integer that indicates the maximum hop
count for all the LSPs. count for all the LSPs.
MU (Max Utilization Percentage: 8 bits) : 8 bits integer that MU (Max Utilization Percentage: 8 bits) : 8 bits integer that
indicates the upper bound utilization percentage by which all link indicates the upper bound utilization percentage by which all link
should be bound. Utilization = (Link Capacity - Allocated Bandwidth should be bound. Utilization = (Link Capacity - Allocated Bandwidth
on the Link)/ Link Capacity on the Link)/ Link Capacity
mU (minimum Utilization Percentage: 8 bits) : 8 bits integer that mU (minimum Utilization Percentage: 8 bits) : 8 bits integer that
skipping to change at page 21, line 47 skipping to change at page 21, line 21
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| Flags | Reserved | |C| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLV(s) // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: NO-PATH object format Figure 10: NO-PATH object format
Flags (16 bits). The C flag is defined in [PCEP]. Flags (16 bits). The C flag is defined in [PCEP].
Two new bit flags are defined in the NO-PATH-VECTOR TLV carried in Two new bit flags are defined in the NO-PATH-VECTOR TLV carried in
the NO-PATH Object: the NO-PATH Object:
0x08: when set, the PCE indicates that no migration path was found. 0x08: when set, the PCE indicates that no migration path was found.
0x10: when set, the PCE indicates no feasible solution was found that 0x10: when set, the PCE indicates no feasible solution was found that
meets all the constraints associated with global concurrent path meets all the constraints associated with global concurrent path
skipping to change at page 26, line 7 skipping to change at page 25, line 7
NMS, the wrong actions may be taken in the network. Therefore, it is NMS, the wrong actions may be taken in the network. Therefore, it is
very important that the operator issuing the commands has sufficient very important that the operator issuing the commands has sufficient
authority and is authenticated, and that the computation request is authority and is authenticated, and that the computation request is
subject to appropriate policy. subject to appropriate policy.
The mechanism defined in [PCEP] to secure a PCEP session can be used The mechanism defined in [PCEP] to secure a PCEP session can be used
to secure global concurrent path computation requests/responses. to secure global concurrent path computation requests/responses.
8. Acknowledgements 8. Acknowledgements
We would like to thank Jerry Ash, Adrian Farrel, J-P Vasseur, Ning So We would like to thank Jerry Ash, Adrian Farrel, J-P Vasseur, Ning
and Lucy Yong for their useful comments and suggestions. So, Lucy Yong and Fabien Verhaeghe for their useful comments and
suggestions.
9. IANA Considerations 9. IANA Considerations
A future revision of this document will present requests to IANA for A future revision of this document will present requests to IANA for
codepoint allocation. codepoint allocation.
10. References 10. References
10.1. Normative References 10.1. Normative References
skipping to change at page 31, line 7 skipping to change at page 30, line 7
Eiji Oki Eiji Oki
NTT NTT
Midori 3-9-11 Midori 3-9-11
Musashino, Tokyo 180-8585 Musashino, Tokyo 180-8585
JAPAN JAPAN
Email: oki.eiji@lab.ntt.co.jp Email: oki.eiji@lab.ntt.co.jp
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 22 change blocks. 
61 lines changed or deleted 48 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/