Hi,
Good catch, thanks.
The figure is correct.
The text should actually say
Flags (32 bits)
as the Pri, O, B, and R flags are part of the flags field
We'll either fix this in the next revision or in the RFC Editor process.
Thanks,
Adrian
----- Original Message -----
From: "S.SenthilKumar (Huawei)" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, October 22, 2008 10:35 AM
Subject: [Pce] Length of Flag Field in RP Object
Dear All
The following Section is taken from draft-ietf-pce-pcep-16.txt
In this context, the length of the Flag field is not clear in the text.
From the figure, Flags field is 26 bits and the rest 6 bits are defined as
Pri (Priority) - 3 bits, R (Reoptimization) - 1 bit, B (Bi-directional) -
1
bit and O (strict/loose) - 1 bit.
But in the text,
a) Flags field is mentioned as 24 bit
b) Pri, R, B and O fields are part of the flags and is miss-leading
---------- Text of concern -----------------------------
Flags (24 bits)
The following flags are currently defined:
---------------------------------------------------------------
Please clarify.
Best regards
S.SenthilKumar
7.4. RP Object
The RP (Request Parameters) object MUST be carried within each PCReq
and PCRep messages and MAY be carried within PCNtf and PCErr
messages. The RP object is used to specify various characteristics
of the path computation request.
The P flag of the RP object MUST be set in PCReq and PCReq messages
and MUST be cleared in PCNtf and PCErr messages. If the RP objet is
received with the P flag set incorrectly according to the rules
states above, the receiving peer MUST send a PCErr message with
Error-type=10 and Error-value=1. The corresponding path computation
request MUST be cancelled by the PCE without further notification.
7.4.1. Object Definition
RP Object-Class is to be assigned by IANA (recommended value=2)
RP Object-Type is to be assigned by IANA (recommended value=1)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |O|B|R| Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: RP object body format
The RP object body has a variable length and may contain additional
TLVs. No TLVs are currently defined.
Flags (24 bits)
The following flags are currently defined:
o Pri (Priority - 3 bits): the Priority field may be used by the
requesting PCC to specify to the PCE the request's priority from 1
to 7. The decision of which priority should be used for a
specific request is of a local matter and MUST be set to 0 when
unused. Furthermore, the use of the path computation request
priority by the PCE's scheduler is implementation specific and out
of the scope of this document. Note that it is not required for a
PCE to support the priority field: in this case, it is RECOMMENDED
that the PCC set the priority field to 0 in the RP object. If the
PCE does not take into account the request priority, it is
RECOMMENDED to set the priority field to 0 in the RP object
carried within the corresponding PCRep message, regardless of the
priority value contained in the RP object carried within the
corresponding PCReq message. A higher numerical value of the
priority field reflects a higher priority. Note that it is the
responsibility of the network administrator to make use of the
priority values in a consistent manner across the various PCCs.
The ability of a PCE to support request prioritization MAY be
dynamically discovered by the PCCs by means of PCE capability
discovery. If not advertised by the PCE, a PCC may decide to set
the request priority and will learn the ability of the PCE to
support request prioritization by observing the Priority field of
the RP object received in the PCRep message. If the value of the
Pri field is set to 0, this means that the PCE does not support
the handling of request priorities: in other words, the path
computation request has been honoured but without taking the
request priority into account.
o R (Reoptimization - 1 bit): when set, the requesting PCC specifies
that the PCReq message relates to the reoptimization of an
existing TE LSP. For all TE LSPs except 0-bandwidth LSPs, when
the R bit is set, an RRO (see Section 7.10) MUST be included in
the PCReq message to show the path of the existing TE LSP. Also,
for all TE LSPs except 0-bandwidth LSPs, then the R bit is set,
the existing bandwidth of the TE LSP to be reoptimized MUST be
supplied in a BANDWIDTH object (see Section 7.7). This BANDWIDTH
object is in addition to the instance of that object used to
describe the desired bandwidth of the reoptimized LSP. For
0-bandwidth LSPs, the RRO and BANDWIDTH objects that report the
characteristics of the existing TE LSP are optional.
o B (Bi-directional - 1 bit): when set, the PCC specifies that the
path computation request relates to a bidirectional TE LSP that
has the same traffic engineering requirements including fate
sharing, protection and restoration, LSRs, TE Links, and resource
requirements (e.g., latency and jitter) in each direction. When
cleared, the TE LSP is unidirectional.
o O (strict/loose - 1 bit): when set, in a PCReq message, this
indicates that a loose path is acceptable. Otherwise, when
cleared, this indicates to the PCE that a path exclusively made of
strict hops is required. In a PCRep message, when the O bit is
set this indicates that the returned path is a loose path,
otherwise (the O bit is cleared), the returned path is made of
strict hops.
--------------------------------------------------------------------------------
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
