Subject: [CCAMP] Local Connection Type

From: "Ong, Lyndon" <[email-masked]>
Date: Mon, 14 Dec 2009 12:26:39 -0500

Hi Folks,

Can we start up a thread on the proposal for Local Connection Type in
draft-theillaud-gmpls-ason-routing-add-fcts-01.txt?

I would also like to start up a thread on the layer-scoped attributes
proposal in that draft, but as a second step since that is a more
complex issue.

draft-theillaud-gmpls-ason-routing-add-fcts-01.txt proposes that an
additional link attribute for GMPLS routing be defined that identifies
if the far end interface of the link supports access to its switching
function (which may be specific to a particular layer).  If access is
not supported, then the link would be pruned from the topology for
computation of paths that do not terminate at the far end node (i.e.,
would transit through the far end node).

This functionality has been previously identified in ITU-T
Recommendation G.7715.1 as local connection type.

One possible method is to use the presence or absence of the ISCD to
imply whether or not switching is supported, however two cases have come
up where this may not be sufficient:

It is very possible that a switch could be constrained by policy to
support only termination of connections and not access to its switching
function.  An example might be a carrier switch located on customer
premises.  If this switch (switch X) is connected by links to two other
switches A and B as in the topology   A----X----B, then from a topology
standpoint it looks like you could switch connections through X, however
this is not allowed by policy.  If no ISCD is advertised by X for the
link, it sounds from reading of RFC 4202 section 2.4 that the absence of
the ISCD completely is interpreted as support of packet switching
capability, which would not be correct in this case.  No information
would be provided as to what types of signals could be terminated at the
far end.

 Another case is a switch that supports termination of high order VC-4
and switching of low order VC-3, but not directly switching of VC-4.
ISCD for VC-3 and VC-4 could be advertised, but this does not
distinguish the case from the case where the switch has both VC-3 and
VC-4 capability in its fabric.  ISCD for VC-3 could be advertised, but
this does not distinguish the case where the switch only supports VC-3
connection. 

Addition of a link attribute that explicitly identifies when access to
switching at a particular signal type is supported would support the
missing functionality.

Comments welcome.

Cheers,

Lyndon

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Wed, 16 Dec 2009 18:34:31 +0100

Lyndon,
 
for the case a) One sets the SC to lower SC capability value (on X ends,
using the Figure). The Max and Min LSP Bw tells the range of "signals"
that can be terminated.
 
for the case b) you stated "ISCD for VC-3 could be advertised, but this
does not distinguish the case where the switch only supports VC-3
connection." In this case, setting Min LSP Bw = VC3 and Max LSP Bw = VC4
and Min LSP Bw = VC3 and Max LSP Bw = VC3 allows that "distinction" and
you can advertized two separate ISCD's for this purpose. The structure
of the mux.tree being implicit I am not sure to see the issue. 
 
Hope this helps,
-dimitri.

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ong, Lyndon
	Sent: Monday, December 14, 2009 6:27 PM
	To: [email-masked]
	Subject: [CCAMP] Local Connection Type

	Hi Folks,

	Can we start up a thread on the proposal for Local Connection
Type in draft-theillaud-gmpls-ason-routing-add-fcts-01.txt?

	I would also like to start up a thread on the layer-scoped
attributes proposal in that draft, but as a second step since that is a
more complex issue.

	draft-theillaud-gmpls-ason-routing-add-fcts-01.txt proposes that
an additional link attribute for GMPLS routing be defined that
identifies if the far end interface of the link supports access to its
switching function (which may be specific to a particular layer).  If
access is not supported, then the link would be pruned from the topology
for computation of paths that do not terminate at the far end node
(i.e., would transit through the far end node).

	One possible method is to use the presence or absence of the
ISCD to imply whether or not switching is supported, however two cases
have come up where this may not be sufficient:

	It is very possible that a switch could be constrained by policy
to support only termination of connections and not access to its
switching function.  An example might be a carrier switch located on
customer premises.  If this switch (switch X) is connected by links to
two other switches A and B as in the topology   A----X----B, then from a
topology standpoint it looks like you could switch connections through
X, however this is not allowed by policy.  If no ISCD is advertised by X
for the link, it sounds from reading of RFC 4202 section 2.4 that the
absence of the ISCD completely is interpreted as support of packet
switching capability, which would not be correct in this case.  No
information would be provided as to what types of signals could be
terminated at the far end.

	 Another case is a switch that supports termination of high
order VC-4 and switching of low order VC-3, but not directly switching
of VC-4.  ISCD for VC-3 and VC-4 could be advertised, but this does not
distinguish the case from the case where the switch has both VC-3 and
VC-4 capability in its fabric.  ISCD for VC-3 could be advertised, but
this does not distinguish the case where the switch only supports VC-3
connection. 

	Addition of a link attribute that explicitly identifies when
access to switching at a particular signal type is supported would
support the missing functionality.

	Comments welcome.

	Cheers,

	Lyndon

---

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 16 Dec 2009 17:42:43 -0500

Hi Dimitri,

Thanks for your response, if there is already a way to do this, that
would be great.  However, I'm not sure what you mean by "lower SC
capability value" - for example, if node X can terminate VC-3 and VC-4
connections but not switch them through, what SC capability would be
advertised for its end of the links?  I presume "lower" does not mean
lower layer, such as lambda capable or fiber capable.

Thanks,

Lyndon

From: PAPADIMITRIOU Dimitri
[mailto:[email-masked]] 
Sent: Wednesday, December 16, 2009 9:35 AM
To: Ong, Lyndon; [email-masked]
Subject: RE: [CCAMP] Local Connection Type

Lyndon,

Hope this helps,

-dimitri.

	Hi Folks,

	Comments welcome.

	Cheers,

	Lyndon

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Thu, 17 Dec 2009 00:24:58 +0100

Lyndon,
 
RFC 4203 defines values associated to SC hence my reference to "lower SC
capability value" for instance L2SC (= 51), TDM (= 100) as lower SC
value than LSC (= 150).
 
Using your example if VC-3 and VC-4 are both "terminated" they refer to
a lower SC value (from X side) - for instance L2SC (if Eth over SDH) or
PSC (if IP/MPLS over SDH) and one sets the Min LSP Bw corr. to VC3 and
Max LSP Bw corr. to VC-4. So, in this example, X indicates in the ISCD
(Switching Capability field) the "upper" SC value. 
 
Thanks,
-dimitri.

	From: Ong, Lyndon [mailto:[email-masked]] 
	Sent: Wednesday, December 16, 2009 11:43 PM
	To: PAPADIMITRIOU Dimitri; [email-masked]
	Subject: RE: [CCAMP] Local Connection Type

	Hi Dimitri,

	Thanks for your response, if there is already a way to do this,
that would be great.  However, I'm not sure what you mean by "lower SC
capability value" - for example, if node X can terminate VC-3 and VC-4
connections but not switch them through, what SC capability would be
advertised for its end of the links?  I presume "lower" does not mean
lower layer, such as lambda capable or fiber capable.

	Thanks,

	Lyndon

	Lyndon,

	for the case a) One sets the SC to lower SC capability value (on
X ends, using the Figure). The Max and Min LSP Bw tells the range of
"signals" that can be terminated.

	for the case b) you stated "ISCD for VC-3 could be advertised,
but this does not distinguish the case where the switch only supports
VC-3 connection." In this case, setting Min LSP Bw = VC3 and Max LSP Bw
= VC4 and Min LSP Bw = VC3 and Max LSP Bw = VC3 allows that
"distinction" and you can advertized two separate ISCD's for this
purpose. The structure of the mux.tree being implicit I am not sure to
see the issue. 

	Hope this helps,

	-dimitri.

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Ong, Lyndon
		Sent: Monday, December 14, 2009 6:27 PM
		To: [email-masked]
		Subject: [CCAMP] Local Connection Type

		Hi Folks,

		Can we start up a thread on the proposal for Local
Connection Type in draft-theillaud-gmpls-ason-routing-add-fcts-01.txt?

		I would also like to start up a thread on the
layer-scoped attributes proposal in that draft, but as a second step
since that is a more complex issue.

		draft-theillaud-gmpls-ason-routing-add-fcts-01.txt
proposes that an additional link attribute for GMPLS routing be defined
that identifies if the far end interface of the link supports access to
its switching function (which may be specific to a particular layer).
If access is not supported, then the link would be pruned from the
topology for computation of paths that do not terminate at the far end
node (i.e., would transit through the far end node).

		This functionality has been previously identified in
ITU-T Recommendation G.7715.1 as local connection type.

		One possible method is to use the presence or absence of
the ISCD to imply whether or not switching is supported, however two
cases have come up where this may not be sufficient:

		It is very possible that a switch could be constrained
by policy to support only termination of connections and not access to
its switching function.  An example might be a carrier switch located on
customer premises.  If this switch (switch X) is connected by links to
two other switches A and B as in the topology   A----X----B, then from a
topology standpoint it looks like you could switch connections through
X, however this is not allowed by policy.  If no ISCD is advertised by X
for the link, it sounds from reading of RFC 4202 section 2.4 that the
absence of the ISCD completely is interpreted as support of packet
switching capability, which would not be correct in this case.  No
information would be provided as to what types of signals could be
terminated at the far end.

		 Another case is a switch that supports termination of
high order VC-4 and switching of low order VC-3, but not directly
switching of VC-4.  ISCD for VC-3 and VC-4 could be advertised, but this
does not distinguish the case from the case where the switch has both
VC-3 and VC-4 capability in its fabric.  ISCD for VC-3 could be
advertised, but this does not distinguish the case where the switch only
supports VC-3 connection. 

		Addition of a link attribute that explicitly identifies
when access to switching at a particular signal type is supported would
support the missing functionality.

		Comments welcome.

		Cheers,

		Lyndon

---

From: Remi Theillaud <[email-masked]>
Date: Thu, 17 Dec 2009 11:46:16 +0100

Hi Dimitri,

   When you write "Max LSP Bw", are you referring to the ISCD 
per-priority Maximum LSP Bandwidth?
   If you are, then it's not clear to me how a field whose value can be 
different per priority can be used to identify the kind of signal that 
can be switched on a link.
   Can you clarify?

   Nevertheless, can you also provide the settings of the ISCDs 
advertised by X in the two following cases:
   1. X can switch both HO VC-4 and HO VC-3.
   2. X can switch HO VC-4 and LO VC-3.

   Thanks,
   Rémi

-------- Original Message --------
Subject: Re: [CCAMP] Local Connection Type
From: PAPADIMITRIOU Dimitri <[email-masked]>
To: Ong, Lyndon <[email-masked]>, [email-masked]
Date: 16/12/2009 18:34
> Lyndon,
>  
> for the case a) One sets the SC to lower SC capability value (on X 
> ends, using the Figure). The Max and Min LSP Bw tells the range of 
> for the case b) you stated "ISCD for VC-3 could be advertised, but 
> connection." In this case, setting Min LSP Bw = VC3 and Max LSP Bw = 
> VC4 and Min LSP Bw = VC3 and Max LSP Bw = VC3 allows that 
>     ------------------------------------------------------------------------
>     *From:* [email-masked] [mailto:[email-masked]] *On
>     Behalf Of *Ong, Lyndon
>     *Sent:* Monday, December 14, 2009 6:27 PM
>     *To:* [email-masked]
>     *Subject:* [CCAMP] Local Connection Type
>
>     Hi Folks,
>
>      
>
>     Can we start up a thread on the proposal for Local Connection Type
>     in draft-theillaud-gmpls-ason-routing-add-fcts-01.txt?
>
>      
>
>     attributes proposal in that draft, but as a second step since that
>     is a more complex issue.
>
>      
>
>     identifies if the far end interface of the link supports access to
>     its switching function (which may be specific to a particular
>     layer).  If access is not supported, then the link would be pruned
>     from the topology for computation of paths that do not terminate
>     at the far end node (i.e., would transit through the far end node).
>
>      
>
>     One possible method is to use the presence or absence of the ISCD
>     to imply whether or not switching is supported, however two cases
>     switching function.  An example might be a carrier switch located
>     on customer premises.  If this switch (switch X) is connected by
>     links to two other switches A and B as in the topology  
>     A----X----B, then from a topology standpoint it looks like you
>     could switch connections through X, however this is not allowed by
>     policy.  If no ISCD is advertised by X for the link, it sounds
>     from reading of RFC 4202 section 2.4 that the absence of the ISCD
>     completely is interpreted as support of packet switching
>     capability, which would not be correct in this case.  No
>      Another case is a switch that supports termination of high order
>     VC-4 and switching of low order VC-3, but not directly switching
>     of VC-4.  ISCD for VC-3 and VC-4 could be advertised, but this
>     does not distinguish the case from the case where the switch has
>     both VC-3 and VC-4 capability in its fabric.  ISCD for VC-3 could
>     be advertised, but this does not distinguish the case where the
>     switch only supports VC-3 connection.
>
>      
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Thu, 17 Dec 2009 12:30:37 +0100

Remi:

	From: Remi Theillaud [mailto:[email-masked]] 
	Sent: Thursday, December 17, 2009 11:46 AM
	To: PAPADIMITRIOU Dimitri
	Cc: Ong, Lyndon; [email-masked]
	Subject: Re: [CCAMP] Local Connection Type

	   Hi Dimitri,
	
	   When you write "Max LSP Bw", are you referring to the ISCD per-priority Maximum LSP Bandwidth? 

[dp] Yes.

	   If you are, then it's not clear to me how a field whose value can be different per priority can be used to identify the kind of signal that can be switched on a link.
	   Can you clarify?

[dp] This value field is not associated to a "capacity amount" attribute but a "capability" attribute: the "max. granularity" that an LSP can take for that interface. This capability has been defined per priority p, thus set a given value in the IGP-TE domain to have a priority "agnostic" processing of the value.

	   Nevertheless, can you also provide the settings of the ISCDs advertised by X in the two following cases:
	   1. X can switch both HO VC-4 and HO VC-3.
	   2. X can switch HO VC-4 and LO VC-3.

[dp] You would typically use the following setting

for 1) ISCD: SC Capability <- TDM; Min LSP Bw <- VC3 and Max LSP Bw <- VC4	

for 2) ISCD_1: SC Capability <- TDM; Min LSP Bw <- VC4 and Max LSP Bw <- VC4
       ISCD_2: SC Capability <- TDM; Min LSP Bw <- VC3 and Max LSP Bw <- VC3

Hope this helps,
-dimitri.

	   Thanks,
	   Rémi
	
	-------- Original Message --------
	Subject: Re: [CCAMP] Local Connection Type
	From: PAPADIMITRIOU Dimitri <[email-masked]> <mailto:[email-masked]> 
	To: Ong, Lyndon <[email-masked]> <mailto:[email-masked]> , [email-masked]
	Date: 16/12/2009 18:34

		Lyndon,
		 
		for the case a) One sets the SC to lower SC capability value (on X ends, using the Figure). The Max and Min LSP Bw tells the range of "signals" that can be terminated.
		 
		for the case b) you stated "ISCD for VC-3 could be advertised, but this does not distinguish the case where the switch only supports VC-3 connection." In this case, setting Min LSP Bw = VC3 and Max LSP Bw = VC4 and Min LSP Bw = VC3 and Max LSP Bw = VC3 allows that "distinction" and you can advertized two separate ISCD's for this purpose. The structure of the mux.tree being implicit I am not sure to see the issue. 
		 
		Hope this helps,
		-dimitri.

			From: [email-masked] [mailto:[email-masked]] On Behalf Of Ong, Lyndon
			Sent: Monday, December 14, 2009 6:27 PM
			To: [email-masked]
			Subject: [CCAMP] Local Connection Type

			Hi Folks,

						Can we start up a thread on the proposal for Local Connection Type in draft-theillaud-gmpls-ason-routing-add-fcts-01.txt?

						I would also like to start up a thread on the layer-scoped attributes proposal in that draft, but as a second step since that is a more complex issue.

						draft-theillaud-gmpls-ason-routing-add-fcts-01.txt proposes that an additional link attribute for GMPLS routing be defined that identifies if the far end interface of the link supports access to its switching function (which may be specific to a particular layer).  If access is not supported, then the link would be pruned from the topology for computation of paths that do not terminate at the far end node (i.e., would transit through the far end node).

						This functionality has been previously identified in ITU-T Recommendation G.7715.1 as local connection type.

						One possible method is to use the presence or absence of the ISCD to imply whether or not switching is supported, however two cases have come up where this may not be sufficient:

						It is very possible that a switch could be constrained by policy to support only termination of connections and not access to its switching function.  An example might be a carrier switch located on customer premises.  If this switch (switch X) is connected by links to two other switches A and B as in the topology   A----X----B, then from a topology standpoint it looks like you could switch connections through X, however this is not allowed by policy.  If no ISCD is advertised by X for the link, it sounds from reading of RFC 4202 section 2.4 that the absence of the ISCD completely is interpreted as support of packet switching capability, which would not be correct in this case.  No information would be provided as to what types of signals could be terminated at the far end.

						 Another case is a switch that supports termination of high order VC-4 and switching of low order VC-3, but not directly switching of VC-4.  ISCD for VC-3 and VC-4 could be advertised, but this does not distinguish the case from the case where the switch has both VC-3 and VC-4 capability in its fabric.  ISCD for VC-3 could be advertised, but this does not distinguish the case where the switch only supports VC-3 connection. 

						Addition of a link attribute that explicitly identifies when access to switching at a particular signal type is supported would support the missing functionality.

						Comments welcome.

						Cheers,

						Lyndon

---

From: "Ong, Lyndon" <[email-masked]>
Date: Thu, 17 Dec 2009 08:01:25 -0500

Hi Dimitri,

Thanks for the added information, it's clear what you mean by "lower"
now.  However, can this be done in a case where the link endpoint is
used to terminate a TDM bandwidth on demand type of service?  In that
case the end node (X) may not in fact be part of a different layer
network, Ethernet or IP/MPLS, and advertising L2SC or PSC would be
implying some functionality that is not there.

Thanks,

Lyndon

Sent: Wednesday, December 16, 2009 3:25 PM

Lyndon,

Thanks,

-dimitri.

	Hi Dimitri,

	Thanks,

	Lyndon

	Lyndon,

	Hope this helps,

	-dimitri.

		Hi Folks,

		Comments welcome.

		Cheers,

		Lyndon

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Thu, 17 Dec 2009 14:27:35 +0100

Lyndon:
 
You state:
"and advertising L2SC or PSC would be implying some functionality that
is not there."
 
well it indicates "terminate" but instead of a bit indication you have
an indication on which SC it "terminates". Meaning this information can
be processed into two ways i) "different" from TDM and then one simply
assumes "terminates" or ii) "different" from TDM with value e.g. PSC
(processed per RFC 4202/4203) in context of unified traffic engineering.
 
-> So the answer is NO (it does not mean that it "may not in fact be
part of a different layer network") as the demarcation is on the [TDM (A
side); PSC (X side)] link connecting A to X.
 
In brief, "qui peut le plus peut le moins" (meaning if one can do more
one can certainly do less).
 
Thanks,
-dimitri.

	From: Ong, Lyndon [mailto:[email-masked]] 
	Sent: Thursday, December 17, 2009 2:01 PM
	To: PAPADIMITRIOU Dimitri; [email-masked]
	Subject: RE: [CCAMP] Local Connection Type

	Hi Dimitri,

	Thanks for the added information, it's clear what you mean by
"lower" now.  However, can this be done in a case where the link
endpoint is used to terminate a TDM bandwidth on demand type of service?
In that case the end node (X) may not in fact be part of a different
layer network, Ethernet or IP/MPLS, and advertising L2SC or PSC would be
implying some functionality that is not there.

	Thanks,

	Lyndon

	Lyndon,

	RFC 4203 defines values associated to SC hence my reference to
"lower SC capability value" for instance L2SC (= 51), TDM (= 100) as
lower SC value than LSC (= 150).

	Using your example if VC-3 and VC-4 are both "terminated" they
refer to a lower SC value (from X side) - for instance L2SC (if Eth over
SDH) or PSC (if IP/MPLS over SDH) and one sets the Min LSP Bw corr. to
VC3 and Max LSP Bw corr. to VC-4. So, in this example, X indicates in
the ISCD (Switching Capability field) the "upper" SC value. 

	Thanks,

	-dimitri.

		Hi Dimitri,

		Thanks for your response, if there is already a way to
do this, that would be great.  However, I'm not sure what you mean by
"lower SC capability value" - for example, if node X can terminate VC-3
and VC-4 connections but not switch them through, what SC capability
would be advertised for its end of the links?  I presume "lower" does
not mean lower layer, such as lambda capable or fiber capable.

		Thanks,

		Lyndon

		Lyndon,

		for the case a) One sets the SC to lower SC capability
value (on X ends, using the Figure). The Max and Min LSP Bw tells the
range of "signals" that can be terminated.

		for the case b) you stated "ISCD for VC-3 could be
advertised, but this does not distinguish the case where the switch only
supports VC-3 connection." In this case, setting Min LSP Bw = VC3 and
Max LSP Bw = VC4 and Min LSP Bw = VC3 and Max LSP Bw = VC3 allows that
"distinction" and you can advertized two separate ISCD's for this
purpose. The structure of the mux.tree being implicit I am not sure to
see the issue. 

		Hope this helps,

		-dimitri.

			Hi Folks,

			Can we start up a thread on the proposal for
Local Connection Type in
draft-theillaud-gmpls-ason-routing-add-fcts-01.txt?

	

			This functionality has been previously
identified in ITU-T Recommendation G.7715.1 as local connection type.

			One possible method is to use the presence or
absence of the ISCD to imply whether or not switching is supported,
however two cases have come up where this may not be sufficient:

			It is very possible that a switch could be
constrained by policy to support only termination of connections and not
access to its switching function.  An example might be a carrier switch
located on customer premises.  If this switch (switch X) is connected by
links to two other switches A and B as in the topology   A----X----B,
then from a topology standpoint it looks like you could switch
connections through X, however this is not allowed by policy.  If no
ISCD is advertised by X for the link, it sounds from reading of RFC 4202
section 2.4 that the absence of the ISCD completely is interpreted as
support of packet switching capability, which would not be correct in
this case.  No information would be provided as to what types of signals
could be terminated at the far end.

			 Another case is a switch that supports
termination of high order VC-4 and switching of low order VC-3, but not
directly switching of VC-4.  ISCD for VC-3 and VC-4 could be advertised,
but this does not distinguish the case from the case where the switch
has both VC-3 and VC-4 capability in its fabric.  ISCD for VC-3 could be
advertised, but this does not distinguish the case where the switch only
supports VC-3 connection. 

			Addition of a link attribute that explicitly
identifies when access to switching at a particular signal type is
supported would support the missing functionality.

			Comments welcome.

			Cheers,

			Lyndon