Hi,
As Lyndon noted in Paris, the OIF
has sent us a communication requesting some guidance on a bunch of
questions.
This is to start the business of constructing a reply.
thanks to Dimitri for supplying some of this text.
Please send comments
and improvements.
Adrian
======
To: Jim Jones, OIF
Technical Committee Chair
From: Adrian Farrel and Kireeti Kompella,
WG Co-Chairs for
IETF CCAMP
Copy: Alex Zinin and Bill Fenner, IETF Routing Area
Directors
Subject: Response to your questions about GMPLS
parameters.
Dear Jim,
Thanks for your correspondence about the
questions with respect to GMPLS parameters that arose before and during your
interoperability testing. CCAMP is pleased to receive such questions and is
glad to have the opportunity to explain the intended operation of the GMPLS
protocols.
Much of the material supplied below can be
simply extracted from the relevant RFCs.
> 1. Use of the NCC and RCC fields for STS-3c/VC-4
connections
>
> During OIF testing it was noted that some
ambiguity exists in the
> specification of encoding of NCC, RCC and NVC
for certain types of
> connections: NCC and RCC for an STS-3c/VC-4
connection can be set to 0 or
> to 1 depending on which example of RFC
3946 is followed.
>
> Clarification is requested from IETF CCAMP
as to which setting is
> considered correct, or if both settings should
be accepted (this procedure
> was used during testing at
Supercomm).
This question about RFC 3946 was raised informally on the
CCAMP mailing list at the start of March this year.
Even when the
signal Type value is the same (i.e. value 6) the NCC, RCC and NVC values
depend on the specific signal being requested.
From the examples in the
annex we have...
A VC-4 signal is formed by applying the
following
settings to a VC-4 Elementary
Signal.
RCC =
0
NCC = 0
NVC = 0
MT =
1
T = 0
An
STS-3c SPE signal is formed by applying the following
settings
to an STS-3c SPE Elementary Signal.
RCC = 1
(standard contiguous concatenation)
NCC =
1
NVC = 0
MT = 1
T = 0
Your
question probably arises from the two notes and subsequent paragraph in
section 2.1 or RFC 3946. Here it says...
Note 1: when
requesting a SONET STS-Nc SPE with N=3*X,
the
Elementary Signal to use must always be
an STS-3c_SPE signal type
and the value of
NCC must always be equal to X. This allows
also
facilitating the interworking between
SONET and SDH. In
particular, it means
that the contiguous concatenation of three
STS-1 SPEs can not be requested because according to
this
specification, this type of signal must
be coded using the STS-3c
SPE signal
type.
Note 2: when requesting a transparent STS-N/STM-N
signal
limited to a single contiguously
concatenated STS-Nc_SPE/VC-4-Nc,
the signal
type must be STS-N/STM-N, RCC with flag 1 and NCC
set
to 1.
The NCC value
must be consistent with the type of contiguous
concatenation
being requested in the RCC field. In particular, this
field is irrelevant if no contiguous concatenation is requested
(RCC
= 0), in that case it must be set to zero when sent, and
should be
ignored when received. A RCC value different
from 0 must imply a
number of contiguous components greater
than 1.
We believe that this final sentence should read "greater than
or equal to 1," and that this interpretation resolves all of your issues and
makes the text consistent with the examples.
> 2. Setting of NVC for
VCAT connections
>
> It was also noted that the setting of NVC
may be somewhat ambiguous for
> the case where diverse connections are
used within a single VCAT group.
> Each individual RSVP session controls
a single connection, but the
> connection is part of a larger VCAT group
and carries VCAT encoding of the
> H4 byte. Clarification is requested
from IETF CCAMP and ITU-T Q.14/15 as
> to the correct setting of NVC for
this case (0 or 1?). It should be noted
> that this case may occur with
a VCAT group with only a single initial
> member, and that the NVC may
provide an indication that VCAT encoding of
> the H4 byte is in use for
the connection.
A VCn-Xv group split into X components requires each of
its component to be signaled with the NVC value set to 1. This setting is
regardless of how the components are established.
> 3. Length of the
Interface Switching Capability TLV
>
> Although the Interface
Switching Capability TLV defined by CCAMP for
> SONET/SDH connections
was not used for the testing, it was noted that the
> text describing
the length of the Interface Switching Capability TLV
> defined in
draft-ietf-ccamp-ospf-gmpls-extensions-12.txt may be slightly
>
ambiguous due to the use of padding bytes.
>
> RFC 3630 states
that "The TLV is padded to four-octet alignment; padding
> is not
included in the length field (so a three octet value would have a
>
length of three, but the total size of the TLV would be eight
octets)."
Yes. Section 2.3.2 of RFC3630 gives a
definitive statement of the meaning of the length field and the use of
padding, and provides an example.
> Reading of the encoding in
draft-ietf-ccamp-ospf-gmpls-extensions-12.txt
> specifies that the
length of the TLV for TDM is 41 bytes plus 3 bytes of
> padding, and
should be given in the length field as 41 bytes rather than
> 44. OIF
requests verification of this interpretation from the experts in
> IETF
CCAMP group.
Note that the Interface Switching Capability Descriptor defined in
draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is a sub-TLV of the Link TLV.
Sub-TLVs and TLVs follow the same encoding rules.
The ISCD TLV for TDM contains the following fields...
type 2 bytes
length 2 bytes
---
switch cap 1 byte
encoding 1 byte
reserve 2 bytes
LSP b/w 0 4 bytes
LSP b/w 1 4 bytes
LSP b/w 2 4 bytes
LSP b/w 3 4 bytes
LSP b/w 4 4 bytes
LSP b/w 5 4 bytes
LSP b/w 6 4 bytes
LSP b/w 7 4
bytes
min b/w 4 bytes
indication 1
byte
==
41
bytes
We presume that your question relates to whether the 3-byte field shown
as "padding" in the TDM-specific figure on page 6 of
draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is an implicit or an explicit
field.
It is an implicit field, and should not be included in the length of the
TLV.
Nevertheless, we take this opportunity to
remind the OIF that implementations of GMPLS protocols should be conservative
in what they send and liberal in what they receive. Thus, an implementation
that receives a TDM ISCD TLV with length 44 should not reject the TLV for this
reason. It should parse the TLV according to the defined fields and skip the
final three bytes. Thus, it should not affect a receiving implementation if
the sending implementation has treated the "padding" field as implicit or
explicit. In the event that a receiving implementation rejected such a TLV on
grounds of the value contained in the length field being too large, the fault
would lie with the receiving implementation not the sending
implementation.
> 4. Use of ADMIN_STATUS in an initial PATH
message
>
> Some implementations sent an ADMIN_STATUS object with
no flags set in the
> initial PATH message, i.e., when no status change
was being requested.
> Although this did not serve any particular
function, it was believed that
> this could be accepted as RFC3473,
sect. 7.2 (page 18) states:
>
> "The absence of the object is
equivalent to receiving an object containing
> values all set to zero
(0)."
>
> It was our interpretation based on this text that a
node should accept an
> ADMIN_STATUS object with no flags set in the
same way as if the object was
> missing. Comment on this interpretation
is welcome.
The effect of the meaning is as you state, but
the intention of the meaning is reversed. That is, an implementation should
accept the absence of the ADMIN_STATUS object in the same way as if the object
was present with no flags set. That is, the default behavior is to consider
the ADMIN_STATUS object as a standard part of the processing.
We note from your first paragraph that you
assume that the ADMIN_STATUS object is used to change the status of the LSP.
This is a misinterpretation - it is used to control the status of the LSP.
Thus, if there is no change to the status of an LSP, refresh messages must
continue to carry the ADMIN_STATUS object with the same bit
setting.
In this way, it is not possible to "drop" the
ADMIN_STATUS object without having the same meaning as transmitting the object
with all bits cleared.
> 5. Handling of multiple received ResvConf
Request objects
>
> When a connection desires a confirmation that
the service (i.e.
> connection) requested is in place, a RESV_CONF_REQ
object is included in
> the RESV message. As this object is received by
the remote end of the
> reservation, it will send a RESV_CONF message
back to the requester.
>
> However, it is unclear whether it is
necessary to send a RESV_CONF message
> when the RSVP connection state
is refreshed by subsequent RESV. This
> becomes potentially burdensome,
especially when the reservation is being
> rapidly refreshed. Therefore
we ask: should the remote end send a
> RESV_CONF message for subsequent
RESV messages that still include the
> RESV_CONF_REQ object? Or is it
required that the requestor of the
> reservation remove the
RESV_CONF_REQ object to prevent the generation of
> further RESV_CONF
messages? Comment on this issue from IETF CCAMP is
>
requested.
It is fundamental to the implementation of
RSVP-TE that there is a good understanding of the distinction between a
trigger message and a refresh message. This can be achieved by reading section
1.1 of RFC2961.
Following this understanding, you will note
that a refresh message does not cause any processing to be performed at the
LSR that receives it (in this case the ingress). You will also note that
refresh processing is not end-to-end as implied in your text, but is
hop-by-hop.
Thus, an downstream LSR that wishes to trigger
a new ResvConf message must make a specific change to the content of the Resv
message that it sends in order to cause a trigger message to be propagated
through the network to the ingress LSR. Such processing is implementation
specific.
> 6. Symmetry of Refresh Reduction usage
>
> During
interop testing, we ran into a conflict caused by varying
>
interpretations of RFC2961, regarding the use of SRefresh messages and
the
> Refresh Reduction capabilities of the two ends of a given link.
One
> interpretation of RFC2961 indicates that setting the Refresh
Reduction
> Capability flag in the RSVP header indicates that that
interface shall be
> capable of receiving messages related to Refresh
Reduction - including the
> SRefresh message. This would be true even if
the other end of the link for
> that interface were NOT indicating
Refresh Reduction Capability, since the
> RFC makes no statement about
symmetry in this matter.
>
> Another interpretation is that both
ends of an interface must indicate
> Refresh Reduction Capability before
either end can use such messages, i.e,
> use of Refresh Reduction on a
link is symmetric.
>
> Comment from CCAMP WG on the correct
interpretation is requested.
We are confused by your question.
You correctly state that the use of the refresh-reduction-capable bit
indicates the ability of an LSR to support the receipt of refresh reduction
options and messages. To quote from section 2 of RFC2961...
When set,
indicates that this node is willing and capable
of
receiving
all the messages and objects described in
this
document. This includes the Bundle message described
in
Section 3,
the MESSAGE_ID objects and Ack messages
described
in
Section 4, and the MESSAGE_ID LIST objects and
Srefresh
message described in Section 5. This bit is meaningful
only
between
RSVP neighbors.
This makes no statement about whether the LSR intends to
use these options when communicating with another LSR.
However, you will note that some refresh reduction procedures require
that a message is sent and response returned. In order to make use of the
response, the receiver must be capable of receiving and processing the
response. Thus, it would be usual for an LSR that is capable of sending
refresh reduction options and messages to also set the
refresh-reduction-capable bit.
In summary:
- An LSR must not send refresh reduction options or
messages
to an LSR that is not setting the refresh-reduction-capable
bit.
- An LSR may send refresh reduction options or messages
to an LSR that is setting the refresh-reduction-capable
bit.
- An LSR that wishes to successfully use responded refresh
reduction options or messages should set the refresh-
reduction-capable bit.
Note, finally, that section 2 of RFC 2961 states that "When it is
not known if a next hop supports the extension, standard Path and Resv message
based refreshes MUST be used."
> 7. Sending of ACKs bundled with the RSVP HELLO
>
>
During interop testing, it was observed that Message Acks were
piggybacked
> onto RSVP Hello messages, when the receiving end was not
using the Hello
> protocol. In this situation, the incoming Hello's were
discarded and the
> Acks were lost.
>
> We believe that
Message Acks should only be piggybacked onto mandatory
> messages, and
not on Hello messages because of this problem. Comment on
> this
interpretation is requested.
You use of the terms "bundled" and "piggybacked" are contradictory.
"Bundled" implies the use of the Bundle message.
RFC 2961 states...
A sub-message MAY be any message type except for
another
Bundle message.
Thus, Ack messages may be bundled with other messages. (Although one
might consider this perverse since the Ack message is only introduced to
handle the case when the Ac/Nack objects have no other message on which they
can be carried.)
Further, RFC 3209 states...
A Hello message may be included
as a
sub-message within a bundle message.
Therefore, it acceptable for a Ack and Hello messages to be bundled
together.
The processing rules (RFC 29610 for Bundled messages are such that each
sub-message is processed in its own right, and the non-support/non-use of
Hello messages should not impact the processing of other messages.
On the other hand, "piggybacked" implies the use of the Ack/Nack objects
within a Hello message.
Section 4.1 of RFC2961 states that Ack/Nack objects may be included in
the "standard" RSVP messages, and shows where they are placed. However, RFC
3209 defines the Hello message as not including the Ack/Nack objects...
<Hello Message> ::= <Common Header> [
<INTEGRITY>
]
<HELLO>
Since RFC 3209 post-dates RFC 2961, this definition is definitive and the
Ack/Nack objects should not be present on the Hello message.
Give that section 5.3 of RFC 3209 states...
The Hello Message is completely OPTIONAL. All messages
may be
ignored by nodes which do not wish to participate in
Hello message
processing.
...it is not particularly important what the message format rules are. An
implementation that chooses to place an Ack/Nack object in a Hello message
knows that the object might be discarded unprocessed.
> 8. TSPEC format to be used for Ethernet connections
The CCAMP working group is currently discussing the use of GMPLS for
control of Ethernet devices. We will respond to this point in a separate
email.
Best regards,
Adrian Farrel
Kireeti Kompella