Subject: Re: LCAS and GMPLS

From: "Diego Caviglia" <[email-masked]>
Date: Tue, 14 Jun 2005 18:23:50 +0200

Hi Greg,
               some further comments in line.

Regards

Diego

Greg Bernstein <[email-masked]> on 14/06/2005 17.27.22

To:    Adrian Farrel <[email-masked]>, Diego Caviglia
       <[email-masked]>
cc:    [email-masked], [email-masked]

Subject:    Re: LCAS and GMPLS

Hi Adrian, not heavy at all. This helps me see what's
up. Let me recast as informal requirements with
justification and of course a bit of solution
pondering.

(1) I (as an individual) really want to be able to use
GMPLS to set up disjointly routed components of a VCAT
group.  Why?  (a) To more be able to full "extract
bandwidth from a mesh" via inverse multiplexing. (b)
To provide for graceful degradation in the case of
failure, e.g., one of the disjointly routed components
fails.
[dc] Agreed
--> I hear now that Call_ID isn't appropriate (thanks
Jonathan and Hi!),
[dc] This is not clear to me, so what is supposed to be the purpose of the
Call_ID? Can someone clarify this better?

but that there is an Association
object (thanks Adrian) of some sort that might be
appropriate.
[dc] hmmm I need some time to read the RFC 2746 at a first glance seems
that the RFC address different problems.

(2) LCAS can be used to add disjointly routed
components to a group in a hitless fashion after it
has been set up via GMPLS.  Initiation of the LCAS
"add" procedure requires some type of management
command.
--> I'm not sure if I have a requirement here since I
could default my end system behavior to automatically
issue the "add" LCAS commands from both ends after the
GMPLS procedure completes.  Diego or Jonathan, are
their other situations where this wouldn't be
appropriate?
[dc] Yes but how you know that you have to enable LCAS?  The LSP could be
part of a 'simple' VCAT.

(3) LCAS can be used to delete disjointly routed
components in a hitless fashion prior to removal of
the component connection via GMPLS. Initiation of the
LCAS "delete" procedure requires some type of
management command. My requirement here would be to
have a way to communicate via the end systems that I'm
going to take down the connection and to have LCAS
first do its hitless deletion.
--> Now at the end that initiating the removal of the
component alerting LCAS to "delete" shouldn't be a
problem. Its the far end we'd want to communicated
something to...  Now didn't we (way back) add
something to RSVP GMPLS extensions to kind of anounce
the release of the connection prior to tear down so
that we could turn off SONET/SDH alarms (and couldn't
we use that to trigger the "reverse LCAS delete").

So Adrian, it seems like LCAS isn't so much as a GMPLS
application but a helper application enabling the
hitless addition and deletion of VCAT components.
Also we may be very close to having all the facilities
we need to automatically enable its "co-use" with
GMPLS. Hence we could be talking about an "Application
Note" rather than extension.  I need to review some of
the ITU VCAT management models to make sure I haven't
glossed over things too much.
[dc] I agree that LCAS is an helper and we almost have all we need to use
it via GMPLS.  We need to agree on how.
My initial idea was to use Call_ID to identify the LSP that are part of the
same VCAT/LCAS set and a bit in the profile filed to inform the other and
that LCAS protcol has bo enabled.

Greg B.

--- Adrian Farrel <[email-masked]> wrote:

> Hi Greg,
>
> Let me come in a bit heavy here, please.
>
>
> > Hi all, thanks for the update Diego and Adrian.
> Where
> > we stand seems to be:
> > (1) We've got an agreed method using the Call_ID
> to
> > identify (VC-3/VC-4) component belonging to a VCAT
> > group. In particular, the Call_ID along with
> source
> > and destination addresses uniquely identifies the
> VCAT
> > group in the network?
>
> No. We do not have agreement on this.
> We have a vague statement of requirements that a
> group of LSPs need to be
> associated. Until we see the requirements fleshed
> out and written up it
> would be wrong to pick one solution. For example, we
> have an Association
> object that is part of mainstream GMPLS that could
> be used for this
> purpose.
>
> So, let's see the requirements written up, please.
>
> > (2) I can use GMPLS to setup/tear down one or more
> > VCAT group components at a time. (we've had this
> for a
> > while).
> > (3) Once we set up via GMPLS a new component
> > (VC-3/VC-4) of a VCAT group we want LCAS to
> hitlessly
> > add the new component to the group.
> > (4) To remove (hitlessly) the component from the
> VCAT
> > group we need  LCAS to remove it before we
> actually
> > tear down the component connection via GMPLS.
>
> So it seems to me that you have decided that LCAS is
> a GMPLS application.
> That is, LCAS is an end-to-end protocol that
> triggers the establishment of
> LSPs by making requests to GMPLS.
>
> This sounds reasonable, but please write it up.
>
> > Now the thing that seems a bit tricky to me about
> (3)
> > and (4) is that LCAS does things unidirectionally,
> in
> > the sense of adding/removing components, (not in
> the
> > sense of a protocol which has a handshake
> mechanism).
> > All add or remove commands come from the source
> end
> > and since we generally setup/teardown
> bi-directional
> > connections that would leave us with a bit of
> > coordination.  Is this what you are thinking
> Diego?
> > LCAS experts chime in too :-)
>
> Nothing to stop you having unidirectional LSPs if
> you need to support a
> service that controls LSPs in a unidirectional way.
>
> Cheers,
> Adrian
>
>

__________________________________
Discover Yahoo!
Get on-the-go sports scores, stock quotes, news and more. Check it out!
http://discover.yahoo.com/mobile.html

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 14 Jun 2005 19:48:18 +0100

Hi Diego, Greg,
> group.

Good. That is really clear.
This maps, I believe, into the need to be able to group together multiple
LSPs that support the same service.

>  Why?  (a) To more be able to full "extract

> Call_ID? Can someone clarify this better?

I, too, think that the Call_ID object (RFC3474) is not appropriate for
this task.

RFC3474 is informational. It documents code point assignments for the
protocol documented by the ITU-T in Recommendation G.7713.2 for use at the
UNI and E-NNI reference points.

If you wanted to use that code point for coordinating VCAT LSPs then you
could, but you would need to have this conversation in the context of the
ITU-T (probably Study Group 15) and not here. A consequence of the use of
the Call_ID object would be that you would:
a) possibly need to implement the ITU-T's UNI before you could exercise
this function
b) need to disambiguate the Call function in G.7713.2 from the new VCAT
function.

On the other hand, a distinct mechanism would allow more easy
interpretation and applicaiton in a GMPLS context.

> but that there is an Association object (thanks Adrian) of
> some sort that might be appropriate.

Whoah Diego, I don't mean the Session_Association object of RFC 2746. That
mechanism is applicable to RSVP over tunnels and is, I think, not relevant
here.

I am refering to the Association object in section 16 of
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt

In order to solve the problem at hand (which seems quite simply to be that
we wish to be able to associate two or more LSPs that have the same
ingress and egress) we need first to answer the question: why is it not
enough to rely on the fact that the LSPs all come from the same Session?

In draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt there is a
requirement to associate a subset of the LSPs that support a service by
coming from the same Session. This is so that a service may be supported
by more than one working LSP, and each working LSP may be protected by one
or more backup LSPs. The association is between a working LSP and its
backups.

But, for your requirement, it may be enough simply to use the Session to
identify all of the LSPs in the same VCAT group. if it is not enough, then
the Association object gives you the function you need.

> [dc] Yes but how you know that you have to enable LCAS?
> The LSP could be part of a 'simple' VCAT.

I'm also not sure that there is a GMPLS requirement here.
How do you know to use LCAS in management-established LSPs? Or any other
type of connection? Seems like this is a generic LCAS propblem.

So, there MIGHT [RFC2119] be a requirement to signal in GMPLS that the
egress should enable LCAS. This is relatively easy to perform if we have
to. I would suggest using draft-ietf-mpls-rsvpte-attributes-05.txt.

> we use that to trigger the "reverse LCAS delete").

Yes, indeed. We have "alarm free teardown" using the Administrative Status
object [RFC 3473]. And this could be used to trigger actions.

But as with the previous question, I wonder whether you really want to use
GMPLS signaling to carry LCAS commands, or whether you want to run LCAS
between the end points and have them trigger GMPLS. I suspect that Neil
would say that this is a layering question!

> [dc] I agree that LCAS is an helper and we almost have all we
> need to use it via GMPLS.  We need to agree on how.

Yes. We seem to be in violent agreement that we need to end up with an
Applicability Statement.

We are making good progress on drilling down to the requirements (don't
throw away these emails, you will need them for you I-D!).

Nevertheless, before completing on the solutions discussion, we still have
to sort out the issues above. I am most concerned about the "layering"
issue. That is:
a) Is the LCAS component on the egress started by management,
   by a trigger in some communication between LCAS components,
   or by a trigger in GMPLS signaling?
b) Do the LCAS components converse through GMPLS signaling
   or by other (existing?) means?

> [dc] My initial idea was to use Call_ID to identify the LSP that are
part of the
> that LCAS protcol has bo enabled.

Understood. I think we have moved on a little from that suggestion.
Presumably you will not be unhappy with any solution that is functional
and not over-complex.

I would suggest that Greg and Diego start an I-D. Call it something like
"Applicability Statement for Operating LCAS and VCAT with GMPLS LSPs".
Include:
- Simple overview of VCAT and LCAS (no more than a page, please)
- Simple statement of how LSPs fit into the picture (about half a page)
- Statement of the requirements on GMPLS signaling (about a page)
- Mechanisms and procedures (two or three pages)

It may be that we need to define a new bit somewhere in which case we will
drop "Applicability Statement for" from the name of the I-D.

I would be very happy to discuss the solutions component with you before
publication so that we avoid thrashing.

Anyone who is interested in this topic should contact Diego and Greg to
offer help.

Thanks,
Adrian

---

From: Greg Bernstein <[email-masked]>
Date: Wed, 15 Jun 2005 09:04:27 -0700 (PDT)

Okay Adrian I'll take a first stab at the I-D based on
the e-mails to date and some of my tutorial material
from short courses and papers.  

Thanks everyone for the info and particularly Maarten
for the in depth descriptions and information.  I may
send you some extra questions after I digest it.  I'm
particularly interested in places where we "enable
LCAS" or some entity tells LCAS to perform an "add" or
"delete" action. E.g., what about renumbering? 

Sounds like there are plenty of possible solutions, so
a focus on a clear understanding of the problem space
and capabilities (which are already automated, can be
automated, or need to be commanded) is important.

Greg B.

--- Adrian Farrel <[email-masked]> wrote:
--- Lots of snips
I would suggest that Greg and Diego start an I-D. Call
it something like "Applicability Statement for
Operating LCAS and VCAT with GMPLS LSPs".
Include:
- Simple overview of VCAT and LCAS (no more than a
page, please)
- Simple statement of how LSPs fit into the picture
(about half a page)
- Statement of the requirements on GMPLS signaling
(about a page)
- Mechanisms and procedures (two or three pages)

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: [email-masked]
Date: Thu, 16 Jun 2005 12:43:15 +0200

Greg, 

> E.g., what about renumbering?
The renumbering is a LCAS element (fully LCAS controlled), that NMS or 
GMPLS should not be bothered about.
Only if you want to operate VCAT with LCAS disabled, NMS/ASON/GMPLS has to 
control the sequence numbers, but changes in the group size is not hitless 
without LCAS.

Hereafter some information on the VCAT/LCAS associated parameters as 
extracted from G.806 (02/04) and G.783 (02/04).

10.1/G.806 includes a generic specification for the VCAT/LCAS functions, 
inlcuding a list of MI signals (MI: Management Information) which 
management needs to control and gets reported. G.783 and G.798 specify the 
technology specific functions, using the specifications in G.806 as basis.

Input MI signals:
=================
P-Xv/P-X-L_A_So_MI_LCASEnable:
The MI_LCASEnable input controls whether the LCAS functionality is enabled 
for the source function (MI_LCASEnable = true) or disabled (MI_LCASEnable 
= false).

P-Xv/P-X-L_A_So_MI_ProvM[1..XMT]:
The MI_ProvM[1..XMT] input controls whether a P[i]_AP at the P-Xv_AP is 
provisioned to be a member of the VCG (MI_ProvM[i] = 1) or not 
(MI_ProvM[i] = 0). 

==> With this input parameter NMS/GNPLS controls which access points (and 
thus VC-n trail termination functions) are part of the VCAT group. Note - 
LCAS determines if there will be traffic routed over it.

P-Xv/P-X-L_A_So_MI_PLCTThr:
Partial loss of capacity transmit threshold associated with cPLCT fault 
cause.

----------

P-Xv/P-X-L_A_Sk_MI_LCASEnable:
The MI_LCASEnable input controls whether the LCAS functionality is enabled 
for the sink function (MI_LCASEnable = true) or disabled (MI_LCASEnable = 
false). If LCAS is enabled, the function auto-detects which type of source 
it is interfacing to. The output MI_LCAS_So_Detected reports whether the 
present sink function detected an LCAS-enabled source function 
(MI_LCAS_So_Detected=true) or a non-LCAS-enabled source 
(MI_LCAS_So_Detected=false, see below for details). Only if both 
MI_LCASEnable and MI_LCAS_So_Detected are true is the LCAS functionality 
active in the function.

P-Xv/P-X-L_A_Sk_MI_ProvM[1..XMR]:
The MI_ProvM[1..XMR] input controls whether a particular one of the 
available physical resources at the P-Xv_AP is provisioned to be a member 
of the VCG (MI_ProvM[i] = 1) or not (MI_ProvM[i] = 0). 

==> With this input parameter NMS/GMPLS controls which access points (and 
thus VC-n trail termination functions) are part of the VCAT group. Note - 
LCAS determines if there will be traffic routed over it.

P-Xv/P-X-L_A_Sk_MI_PLCRThr:
Partial loss of capacity receive threshold associated with cPLCR fault 
cause.

P-Xv/P-X-L_A_Sk_MI_TSDEnable:
The MI_TSDEnable input controls whether the sink function uses AI_TSD[i] 
indications as contributors for signalling defective members back to the 
LCAS source function (MI_TSDEnable = true) or whether it ignores AI_TSD[i] 
indications altogether (MI_TSDEnable = false).

P-Xv/P-X-L_A_Sk_MI_HOTime:
The MI_HOTime input controls whether the Hold-Off (HO) timer is enabled or 
disabled for the sink function and, if enabled, what the value of the 
timer is. If MI_HOTime = 0, the HO timer shall be disabled, if MI_HOTime 0 
it shall be enabled. 

P-Xv/P-X-L_A_Sk_MI_WTRTime:
The MI_WTRTime input controls whether the Wait-To-Restore (WTR) timer is 
enabled or disabled for the sink function and, if enabled, what the value 
of the timer is. If MI_WTRTime = 0, the WTR timer shall be disabled, if 
MI_WTRTime 0 it shall be enabled. 
The range of values for the HO/WTR timers is as defined in ITU-T Rec. 
G.808.1.

P-X-L_TT_Sk_MI_SSF_Reported:
Controls if cSSF fault cause is reported. Typically owned by NMS.

Output MI signals:
==================
P-Xv/P-X-L_A_So_MI_XAT:
Current size of the transmitted payload. 

P-Xv/P-X-L_A_So_MI_XMT
Maximum size of the transmitted payload.

P-Xv/P-X-L_A_So_MI_TxSQ[1..XMT]
Indication of which sequence number (_SQmap[i]) is being carried over a 
particular P_AI (P_AI[i]) signal. 

P-Xv/P-X-L_A_Sk_MI_XMR
Maximum size of the received payload.

P-Xv/P-X-L_A_Sk_MI_XAR
Current size of the received payload

P-Xv/P-X-L_A_Sk_MI_DMFI[1..XMR]
The relative delay, in MFI units, between each provisioned member and the 
earliest-arriving member among those considered for the calculation

P-Xv/P-X-L_A_Sk_MI_LCAS_So_Detected
Indication if remote node supports LCAS.

P-Xv/P-X-L_A_Sk_MI_AcSQ[1..XMR]
Indication of which sequence number is being received over a particular 
P_AI (P_AI[i]) signal. 

Besides these VCAT/LCAS specific parameters, you need to control a subset 
of the individual trail termination (e.g. S4_TT) function and the client 
adaptation (e.g. S4-X/ETH_A) function parameters. E.g. for VC-4 and VC-3 
TT_Sk functions:

Input MI parameters:
====================
Sn_TT_Sk_MI_TPmode
Termination Point mode to control alarm free path set up. Refer to 
6.1/G.806 and 7.1.4/G.7710.

Sn_TT_Sk_MI_ExTI
Expected Trace Identifier value must be configured by GMPLS when GMPLS 
sets up VC-n network connection; action is to read MI_TxTI parameter in 
TT_So and carry this value to remote end to configure MI_ExTI.

Sn_TT_Sk_MI_TIMdis
Disables/Enables TIM defect detection. GMPLS should control this as part 
of VC-n connection setup.

Sn_TT_Sk_MI_TIMAISdis
Disables/enables AIS insertion on TIM defect detection. GMPLS to control 
this as part of VC-n connection setup.

Sn_TT_Sk_MI_RDI_Reported
Sn_TT_Sk_MI_SSF_Reported
Controls if cRDI and cSSF fault cause are reported. Typically owned by 
NMS.

Sn_TT_Sk_MI_DEGTHR
Sn_TT_Sk_MI_DEGM
Sn_TT_Sk_MI_EXC_X
Sn_TT_Sk_MI_DEG_X
Bit error defect detection process configuration parameters. Must be 
configured as part of connection setup; values depend on SLA.

Output MI parameters:
=====================
Sn_TT_Sk_MI_AcTI
Accepted Trace Identifier value report.

Parameters for one of the client adaptation functions (e.g. Sn/ETH_A, 
G.8021) are typically outside the control of the GMPLS VC-n Group 
connection setup; those parameters are under either NMS or client layer 
GMPLS control.

I hope the above helps to get a feeling of what you need to control during 
VC-n Group connection set up.
Note that the VCAT group can be set up as a single VC-n Group, or as 
multiple, diverse routed, (smaller) VC-n (sub)Groups. E.g. a 5 VC-4 VCAT 
group may be set up as a 5 VC-4 network connection group, as a 3 VC-4 
netowrk connection group (VCG A) and a 2 VC-4 network connection group 
(VCG B), as five individual VC-4 network connections, ... The most common 
case when used to transport data will most likely be the second case: two 
VCGs supporting one VCAT/LCAS group. I assume that NMS and GMPLS VC-n 
connection management would set up VCG A and a VCG B, with the requirement 
that both must be diverse routed.

If the VCAT group at a later stage is to be extended to 6 VC-4 members, 
then for the case of VCG A and VCG B, the VCG B could be extended from 2 
to 3 VC-4 network connections. You would then issue a connection 
modification request for VCG B and leave VCG A untouched.

Regards,
Maarten 

Greg Bernstein <[email-masked]>
Sent by: [email-masked]
15-06-2005 18:04
 
        To:     Adrian Farrel <[email-masked]>, Diego Caviglia 
<[email-masked]>
        cc:     yhwkim <[email-masked]>, ccamp <[email-masked]>
        Subject:        Re: LCAS and GMPLS

Greg B.

---

From: Greg Bernstein <[email-masked]>
Date: Thu, 16 Jun 2005 09:03:35 -0700

Hi Maarten, thanks.  Adrian and ITU folks, I went to the additional 
CCAMP web page and looked at the liasons but didn't see
G.806, G.783, G.783, G.798 nor G.7042 (LCAS itself) listed. Are these 
available to the CCAMP workgroup.  My archive of ITU-T
documents is a bit out of date.

Stephen, did Maarten's answer clear things up?  Think about VCAT as a 
physical layer (circuit based) inverse multiplexing technique, hence to
keep the hardware reasonable the spec. (G.707) doesn't allow for mix and 
matching component types in a VCAT group.  Or did you mean something
else with your recursive composition idea?

Adrian, I've started on the I-D using the relatively new XML method 
(seems easier than the MS Word or pure text method).  Anyone who wants 
to help
or review prior to submission let me know.  Note that my 
[email-masked] e-mail address is checked more frequently 
than my [email-masked] address.

Greg B.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 16 Jun 2005 20:12:05 +0100

Greg,

Sorry, no. We don't have access to the Recommendations you list.
This is particularly hard for those of us who are independent or work for
small companies that are not ITU-T members.

Note that you can get three free downloads of Recommendations by following
the links on the ITU web pages, so this may help a little.

Great news that you have started the work.

Cheers,
Adrian