Subject: RE: Responding to the OIF

From: "Evelyne Roch" <[email-masked]>
Date: Thu, 18 Aug 2005 16:06:13 -0400

Hi,
 
Regarding the following points:
 
1. From the examples below, STS3c and VC4 have different RCC/NCC values.
Clarifications on which values should be used for SONET/SDH interworking
would be useful.

5. Is a change in the presence/absence of ResvConf considered a trigger
message?  My interpretation of the text below is that a refresh resv
message containing a RESV_CONF object would not result in the generation
of a RESV_CONF message, RESV_CONF messages only being sent on trigger
resv message. Is that correct?

Regards,
Evelyne Roch 
Control Plane Software 
Nortel Networks 
PO Box 3511 STN C Ottawa ON K1Y 4H7 
* Phone: (613) 763-6492 (esn 393) 
* e-mail [mailto:[email-masked]] 

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Adrian Farrel
	Sent: Thursday, August 11, 2005 8:43 AM
	To: [email-masked]
	Subject: Responding to the OIF

	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

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 18 Aug 2005 22:43:18 +0100

Hi Evelyne,

> 1. From the examples below, STS3c and VC4 have different
>  RCC/NCC values. Clarifications on which values should be
> used for SONET/SDH interworking would be useful.

I have a couple of folks looking at this for me because I can't tell the
difference between a timeslice and a cakeslice.

Hopefully they will generate a response soon.

> 5. Is a change in the presence/absence of ResvConf considered a
> trigger message?

Yes, it would be a trigger message (that is, it would not be treated as a
simple refresh). But a "trigger message" does not necessarily cause any
action.

> My interpretation of the text below is that a refresh resv
> message containing a RESV_CONF object would not
> result in the generation of a RESV_CONF message,
> RESV_CONF messages only being sent on trigger

Seems reasonable to me.
That way the ResvConf confirms the receipt of the changed Resv.

I guess I should have added a note that a ResvConf message is not
necessarily reliably delivered. 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.

Adrian

---

From: dimitri papadimitriou <[email-masked]>
Date: Fri, 19 Aug 2005 00:40:50 +0200

> Hopefully they will generate a response soon.

this may help -

    "A dedicated signal type is assigned to a SONET STS-3c SPE instead of
    coding it as a contiguous concatenation of three STS-1 SPEs. This is
    done in order to provide easy interworking between SONET and SDH
    signaling."

also the RFC explains how the negotiation occurs (RCC/NCC selection is a 
local decision process depending on the supported capabilities) - not a 
big deal here, there are 4 cases possible:

- symmetric fixed case either SDH or SONET on both sides, there is no 
interworking issue possible

- symmetric configurable case (assumption taken by OIF) where selection 
is not impacting establishment, there is no interworking issue possible

- asymmetric fixed-configurable case: the upstream node drives the 
selection by indicating the selected values, there is no interworking 
issue possible

- asymmetric configurable-fixed case: an error is generated if the 
config supported by the fixed side is not selected by the upstream node 
but signaling just follows result of the selection - however, GMPLS 
signaling can not correct this in any case -

> .