[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Response to your questions about GMPLS parameters
Dear Adrian,
Thanks for the detailed reply. I am posting this on the OIF contribution
site for discussion during our 4Q Technical Committee meetings next month. I
expect we will cover the topic of Ethernet requirements as well as the
details regarding GMPLS parameters.
Again, we appreciate the efforts of the IETF CCAMP in preparing this reply
and look forward to continued cooperation.
Best Regards,
Jim
-----Original Message-----
From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: Sunday, September 18, 2005 5:51 PM
To: Jim Jones
Cc: ccamp@ops.ietf.org; 'Kireeti Kompella'; zinin@psg.com; Bill Fenner
Subject: Response to your questions about GMPLS parameters
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.
The intention of the editors of RFC 3946 was that a VC-4 elementary signal
would be represented using RCC=0 and NCC=0, while an STS-3c SPE elementary
signal would have RCC=1 and NCC=1. This follows the examples in the annex.
Your question probably arises from the two notes and subsequent paragraph in
section 2.1 or RFC 3946. The text here is compatible with the annex, but
culminates with...
"A RCC value different from 0 must imply a number of contiguous components
greater than 1."
The editors intended this to mean "greater than or equal to 1."
As a result of your question there has been some heated debate within CCAMP
driven by the fact that some people have implemented according to the word
of the RFC while others have implemented according to the intention of the
editors (using the examples in the annex to drive their work).
We plan to issue a revision to RFC 3946 which will include the following
compromise position.
a. "greater than" will be changed to "greater than or equal to"
b. A third note will be added to section 2.1 to clarify the expected
behavior as follows...
Note 3: Following these rules, when requesting a VC-4 signal, the RCC and
the NCC values are set to 0, whereas for an STS-3c SPE signal, the RCC and
the NCC values are set to 1. However, since the signals are
indistinguishable in the data plane, the requesting upstream node MAY set
the RCC and NCC values to either both 0 or both 1 without impacting the
function. The downstream node MUST accept both possible settings of RCC and
NCC and handle them interchangeably. The upstream node SHOULD be consistent
in its choice of RCC and NCC value settings for all LSPs requested on any
one interface.
This solution is still subject to agreement from the CCAMP community, but
appears to reflect a position which facilitates maximum interworking.
> 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, a 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 but might include
the toggling of the presence of the RESV_CONFIRM object on the Resv message.
Note that a ResvConf message is not necessarily reliably delivered
end-to-end. Relying on the receipt of a ResvConf message before doing
something (e.g. turning on the laser) might be a poor idea. GMPLS uses the
Administrative Status object and in particular the R-bit in order to
reliably achieve this function.
> 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 has discussed the use of GMPLS for control of
Ethernet devices, and this has led to the publication of a new
Internet-Draft entitled "Use of the Generalized Multi-Protocol Label
Switching control plane for point-to-point Ethernet Label Switching" which
you can find at
http://www.ietf.org/internet-drafts/draft-andersson-gels-bof-prep-00.txt.
The Abstract of this draft reads as follows:
This document proposes starting a work within the IETF to apply the
Generalized Multi-Protocol Label Switching (GMPLS) control plane to
Ethernet Label Switching and to make extensions to the GMPLS control
plane protocols as necessary for this application. This will be done
based on the protocols developed by the MPLS and CCAMP working groups
in the IETF. Ethernet Label Switching will use the data plane
encodings as specified by the IEEE 802 standards.
This document intends to gather the information necessary to have a
"GMPLS Ethernet Label Switching" BoF in Vancouver.
We are certain that the IETF will want to ensure that the OIF's requirements
for Ethernet are adequately covered by GMPLS and would urge the OIF to
document its requirements and to send them to the IETF for inclusion. In
this instance you may send such requirements to us and we will ensure that
they are passed on to the correct group that undertakes this work.
Best regards,
Adrian Farrel
Kireeti Kompella