Subject: GMPLS testing
From: "Morgan, Peter (Engineering)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Sun, 30 Dec 2001 02:34:03 -0000

Hello,

I am presenting a seminar at the All-Optical Networks & GMPLS conference in
London in January. My topic is "Examining the key market drivers for the
deployment of GMPLS as a control plane in All-Optical Networks". I have
written an outline but information available on the Net is limited re case
studies, lab trials etc. Any information anyone could provide on these would
be appreciated.

Thanks,
Peter. 

Delivery-date: Wed, 26 Dec 2001 07:25:31 -0800
Date: Wed, 26 Dec 2001 20:55:49 +0530
From: Rajaraman B <[email-masked]>
To: [email-masked]
Subject: Questions Regarding UNI

Hi,
    I have the following doubts in UNI Implementation Aggrement.

1)    whether there should be two UNI session for source UNI(UNI-C and
UNI-N) and destination UNI(UNI-N and UNI-C) respectively while sending
Path message, since we need to specify in SESSION object destination
Node ID as adjacent UNI-N's node ID in the case source UNI and as
adjacent UNI-C's Node ID in the case of destination UNI(when message is
sent across NNI to destination UNI-N to destination UNI-C).

2) if there is two session across source and destination UNI, whether
SenderTSpec(flowspec in Reservation message) is to be interpreted at
UNI-N through some admission control module as in base RSVP(rfc-2205 -
using Link Layer Dependent Adaptation Layer in ISI-RSVP implementation
source code).

3) what is the purpose of using SenderTSpec and FlowSpec in UNI-RSVP?
Whether it is used to specify label range. if that specifies label
range, then whether it should be interpreted at UNI-N to check the
incoming label(whether it lies in that label range as in the IP-MPLS
network)

Please clarify.

Thanks,
Rajaraman. B

Delivery-date: Wed, 26 Dec 2001 03:19:43 -0800
From: LE ROUX Jean-Louis FTRD/DAC/LAN <[email-masked]>
To: "[email-masked] '" <[email-masked]>
Subject: SRLG in  generalized ISIS
Date: Wed, 26 Dec 2001 12:12:38 +0100

Folks,

I have a question regarding the  TLV SRLG (138) in
"draft-ietf-isis-gmpls-extensions-05.txt"
Why is this information included in a separated TLV ?
SRLG is a new TE parameter, it is link related, so  shouldn't it be encoded
in a new sub-TLV, inside  TLV 22 ?

Thanks in advance

JL

Delivery-date: Fri, 21 Dec 2001 12:57:19 -0800
Date: Fri, 21 Dec 2001 15:49:24 -0500
To: "Gopal Kailad" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: Transport networks and draft-ietf-mpls-generalized-rsvp-te [ was Re: GMPLS signaling documents updated per last calls]
Cc: "Berger, Lou" <[email-masked]>,<[email-masked]>, <[email-masked]>,<[email-masked]>,<[email-masked]>,<[email-masked]>, <[email-masked]>,<[email-masked]>,<[email-masked]>, <[email-masked]>,<[email-masked]>, <[email-masked]>,<[email-masked]>, <[email-masked]>,<[email-masked]>, <[email-masked]>,<[email-masked]>

At 09:38 AM 12/20/2001, Gopal Kailad wrote:
>The Restart Time field in the Restart_Cap object supports a
>maximum value of about 49 days.  In case of transport networks,
>this would mean that in case of a controller failure due to say,
>a natural disaster, if the node is not accessible, established
>connections will fail after 49 days even if data plane is not
>affected, which is unacceptable.

You're right.  This looks like a blown edit.  The 0xffffffff value applies 
to Restart not recovery time.  I'll move the text.  I'll also elaborate for 
a bit more clarity.

Thanks,
Lou

Delivery-date: Fri, 21 Dec 2001 11:57:45 -0800
Date: Fri, 21 Dec 2001 14:56:09 -0500
From: George Newsome <[email-masked]>
Organization: Lucent Technologies, Bell Labs
To: Dimitri Papadimitriou <[email-masked]>
CC: "Mannie, Eric" <[email-masked]>, "'Maarten Vissers'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: GMPLS signaling documents updated per last calls

Dimitri Papadimitriou wrote:
> 
> Maarten,
> 

........
> 
> The agreement "we have a satisfactory solution but not the one proposed
> by Maarten/Stephen/etc." so this discussion for me is closed ... but i
> think that some people would like to see THEIR OWN solution into the
> document the reason is clear for me introduce their own view on the
> protocol architecture for distributed control plane restricting us to
> use the complexities they have introduced in their own model... sorry
> but this was not the aim of the last IETF meeting discussion.
> 

This is almost funny. The whole debate is about getting rid of unnessary
and restrictive complexity in your current solution.

.........
> >
> > It is not only a matter of the signal type field in the draft, it is also a
> > matter of how the network is monitored/operated. A SONET signal is not
> > always 100% compatible with an SDH signal. It depends on the profile used in
> > SDH and SONET. For sure there are different profiles for SONET and SDH (e.g.
> > differences in overhead: SS bit, J0, S1, J1, B3, G1, etc). We understood
> > that there is a join effort between T1 and ITU to reduce these differences,
> > but you cannot assume that everybody will adapt to/implement the latest
> > (draft) version of the transport plane standards.
> 
> I would like also to remember here that our target is to achieve an
> efficient and interoperable running code, we don't target state of

Given your current solution, I can only wish you well

> the art transmission system modelling "theory" since in practice state
> of the art models are rarely applicable in the real world.

Good models are taken from the real world - the one that some of us have
worked with for many years. Its hard to see how such models don't apply.
(Remember the new economy - the old models didn't apply)

> 
> ... these remarks translates the problem of people working only from
> the "theoretical" viewpoint without any pragmatic view on the reality.
> 

Well Dimitri, if you can't deal with Maarten's arguments, at least you
can try and call him names.

........
> 
> For all, if you take a look at the complexity introduced by this model,
> call/discovery then connection i more than 100% sure that we are on the
> right track here BY KEEPING THINGS SIMPLE.
> 

Again, the best I can do is wish you well with your "simple" model

Have a Merry Xmas

Regards

	George

Delivery-date: Fri, 21 Dec 2001 11:40:11 -0800
To: Dimitri Papadimitriou <[email-masked]>
cc: "Mannie, Eric" <[email-masked]>, "'Maarten Vissers'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: GMPLS signaling documents updated per last calls 
Date: Fri, 21 Dec 2001 11:37:23 -0800
From: Yakov Rekhter <[email-masked]>

Dimitri,

> Maarten,
> 
> I will add some hints here to the one already pointed out by Eric.
> See in-line...

[clipped...]
 
> I would like also to remember here that our target is to achieve an
> efficient and interoperable running code, we don't target state of
> the art transmission system modelling "theory" since in practice state
> of the art models are rarely applicable in the real world.
> 
> ... these remarks translates the problem of people working only from 
> the "theoretical" viewpoint without any pragmatic view on the reality.

I certainly agree with the above. And since this is not the first
time we are getting into the theory vs practice arguments,
to set up the expectations straight and avoid any 
misunderstanding/confusion I would suggest to put the following
disclaimer into the GMPLS document:

  It is an explicit non-goal of the solution described in this
  document to address all possible (as well as impossible)
  requirements. Therefore, the solution described in this document
  is clearly not a perfect solution, and as such doesn't quality
  for being a LTSFGTC (Long Term Solution For Generations To Come).
  Work on the perfect solution (aka LTSFGTC) is in progress, and is
  expected to be published in RFC100000.

Yakov.

Delivery-date: Fri, 21 Dec 2001 11:13:54 -0800
Date: Fri, 21 Dec 2001 20:08:14 +0100
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: "Mannie, Eric" <[email-masked]>, "'Maarten Vissers'" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: GMPLS signaling documents updated per last calls

This is a multi-part message in MIME format.
--------------04787838FBA9204781476572
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Maarten,

I will add some hints here to the one already pointed out by Eric.
See in-line...

"Mannie, Eric" wrote:
> 
> Hello Maarten,
> 
> > It is not the intention to leave the choice of LSP encoding type and SU
> label
> structure to the vendor. This would give immediate interworking problems.
> 
> Sorry but this comment doesn't make sense. Of course if one implements an
> IP-LSR it could not speak SDH ! The vendor has the choice of the type of box
> he wants to implement (IP, ethernet, ATM, SDH, SONET, photonic,...). Of
> course we leave the choice of the supported LSP encoding types to the
> vendors !

The main question is not the control but the transmission plane. And i
would like to strengthen that if (even today) or in future convergence
is achieved the current proposal doesn't preclude it at all. In the 
meantime your Maarten (or ITU since you maintain another confusion here
for me) doesn't provide backward comptability.
 
> The label structure is defined in the draft.
> 
> > VC-11/VT1.5, VC-12/VT-2, VC-2/VT-6, VC-3/STS-1, VC-4/STS-3c,
> VC-4-4c/STS-12c,
> VC-4-16c/STS-48c, VC-4-64c/STS-192c and VC-4-256c/STS-768c must all have LSP
> encoding type "SDH". Also STS-1/STM-0 upto STM-256/STS-768 must have the LSP
> encoding type "SDH".
> 
> No, not necessarily. Why do you want to reject all SONET implementations ?

Again your restricted interpretation.
 
> > VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, VC-4-16c/STS-48c,
> VC-4-64c/STS-192c
> and VC-4-256c/STS-768c must all have the same SDH-based "SU" structure.
> 
> No, not necessarily. Why do you want to reject all SONET implementations ?

Probably this one of the key question here.
 
> > Looking at the label text in section 3 of the sonet-sdh document, I find
> it very
> confusing to read that SONET doesn't use the "U" field.
> 
> This didn't change since 1 or 2 years.
> 
> By the way, I thought that we reached an agreement ?

The agreement "we have a satisfactory solution but not the one proposed
by Maarten/Stephen/etc." so this discussion for me is closed ... but i 
think that some people would like to see THEIR OWN solution into the 
document the reason is clear for me introduce their own view on the 
protocol architecture for distributed control plane restricting us to 
use the complexities they have introduced in their own model... sorry 
but this was not the aim of the last IETF meeting discussion.
 
> > As we indicated before there is no STS type signal that isn't having an
> SDH equivalent; i.e. there are no specific higher order SONET signals left.
> It is therefore much better to take out the SONET text for the SU label part
> altogether.
> 
> It is not only a matter of the signal type field in the draft, it is also a
> matter of how the network is monitored/operated. A SONET signal is not
> always 100% compatible with an SDH signal. It depends on the profile used in
> SDH and SONET. For sure there are different profiles for SONET and SDH (e.g.
> differences in overhead: SS bit, J0, S1, J1, B3, G1, etc). We understood
> that there is a join effort between T1 and ITU to reduce these differences,
> but you cannot assume that everybody will adapt to/implement the latest
> (draft) version of the transport plane standards.

I would like also to remember here that our target is to achieve an
efficient and interoperable running code, we don't target state of
the art transmission system modelling "theory" since in practice state
of the art models are rarely applicable in the real world.

... these remarks translates the problem of people working only from 
the "theoretical" viewpoint without any pragmatic view on the reality.
 
> Indeed, I think that we should have much more than just than two LSP
> encoding types (SDH and SONET),  but that we should in addition indentify
> profiles. Having SDH and SONET is a strict minimum. Making mandatory the use
> of one single LSP encoding type for both SONET and SDH is lying to the
> people. It will make GMPLS impossible to use in practice.
> 
> Anyway, as you said there are different profiles in SDH, and different
> profiles in SONET. The difference between SDH and SONET comes from the fact
> that they use different profiles (they can also use the same). In the LSP
> encoding type, when we use SONET, we mean a different profile than SDH. We
> wanted to have more profiles (e.g. SDH1996, etc) identified but you didn't
> want.

Eric the above remark is clear from the study made on the difference b/w
the OH at the Section/RS, Line/MS and Path. I think that we were
probably
on the right track when having used the versioning of the SDH/Sonet
rec's
but we took the decision at that time to introduce this profiling into
the
routing ("the discovery of the interface capabilities").
 
> If I understood, your idea is to have a second signaling protocol doing a
> second pass to setup the profile. Having a control plane with several
> signaling round trips and different signaling protocols to setup one single
> circuit is a complete mistake from my point of view and from my control
> plane design experience. Of course since you want to impose this second
> signaling pass, you need to impose a single unique LSP encoding type for
> both SDH and SONET so that we will be obliged to use another pass to make
> the distinction. I think that now everybody can understand what you have in
> mind but don't want to explain.

For all, if you take a look at the complexity introduced by this model,
call/discovery then connection i more than 100% sure that we are on the 
right track here BY KEEPING THINGS SIMPLE.
 
> >Otherwise we will get a lot of confusion in the marketplace.
> 
> I think that you are creating the confusion by claiming that there is no
> difference at all between SDH and SONET.

Strange to see such a remark coming from your side... see below.
 
> > Also the examples with STS-1 (examples 3 to 5 in secton 3) must use the
> label
> with U in the range 2 to 4; the STS-1 is equivalent to the VC-3 in SDH and
> must
> thus use the "SDH" SU format.
> 
> We are back at the beginning of the discussion... for the Xth time ! As
> usual.

... and after Maarten you friendly tell us that we introduce
confusion...
is it not the case when you rediscuss many times the same issue for
which
a decision has been taken and endorsed one or two weeks before ?
 
> Rgds,
> 
> Eric
> 
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Wednesday, December 19, 2001 9:05 AM
> To: Mannie, Eric
> Cc: [email-masked]'; 'Stephen Trowbridge'; Kireeti
> Kompella; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: GMPLS signaling documents updated per last calls
> 
> Eric,
> 
> It is not the intention to leave the choice of LSP encoding type and SU
> label
> structure to the vendor. This would give immediate interworking problems.
> 
> VC-11/VT1.5, VC-12/VT-2, VC-2/VT-6, VC-3/STS-1, VC-4/STS-3c,
> VC-4-4c/STS-12c,
> VC-4-16c/STS-48c, VC-4-64c/STS-192c and VC-4-256c/STS-768c must all have LSP
> encoding type "SDH". Also STS-1/STM-0 upto STM-256/STS-768 must have the LSP
> encoding type "SDH".
> 
> VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, VC-4-16c/STS-48c,
> VC-4-64c/STS-192c
> and VC-4-256c/STS-768c must all have the same SDH-based "SU" structure.
> 
> Looking at the label text in section 3 of the sonet-sdh document, I find it
> very
> confusing to read that SONET doesn't use the "U" field. As we indicated
> before
> there is no STS type signal that isn't having an SDH equivalent; i.e. there
> are
> no specific higher order SONET signals left. It is therefore much better to
> take
> out the SONET text for the SU label part altogether. Otherwise we will get a
> lot
> of confusion in the marketplace.
> 
> Also the examples with STS-1 (examples 3 to 5 in secton 3) must use the
> label
> with U in the range 2 to 4; the STS-1 is equivalent to the VC-3 in SDH and
> must
> thus use the "SDH" SU format.
> 
> -------
> 
> All,
> 
> With the clarification on VT-3 given by Deborah, I would request to consider
> a
> further simplification of the GMPLS standard: delete the LSP encoding type
> "SONET" and rename the LSP encoding type "SDH" into "SDH/SONET". Then there
> would be no ambiguity left at all.
> 
> Regards,
> 
> Maarten
> 
> "Mannie, Eric" wrote:
> >
> > Hi Jonathan,
> >
> > > Why SHOULD and not MUST?  This ambiguity is likely to create
> > interoperability problems in the future...
> >
> > To leave to the manufacturer and to the user the right to decide if he/she
> > wants to signal an LSP as either SDH or SONET. There is no
> interoperability
> > problem at all since you use EITHER SDH OR SONET. If you decide to request
> > an SDH signal with what do you want to have interoperability issue at this
> > stage ? The sentence means indeed "one should better use SDH than SONET" !
> > Once you decided, there is no issue.
> >
> > > I'm curious what sort of backward compatability is necessary, as a
> > "standard" doesn't exist currently that this needs to be backward
> > compatible with...
> >
> > Backward compatibility with the OIF UNI 1.0 Implementation Agreement, with
> > the implementations that could not care of SDH, with implementations that
> > still do a distinction between SONET and SDH for some reasons, with the
> > implementations that could still use the VT3 (DS1C) (I don't have
> > confirmation that nobody is using it today, and this is not the goal of
> this
> > draft to state what is obsolete or not in SONET), etc.
> >
> > Anyway, there is no issue, the SONET label format is not used until SONET
> is
> > explicitly requested as such. This is not a primary feature of the draft,
> > but a *secondary feature*, for SONET lovers. Otherwise, SDH is used for
> > everything, consequently you don't care of the SONET label, you skip it in
> > the draft, you ignore it, you don't implement it and you just use a full
> SDH
> > implementation.
> >
> > I think that the solution is quite simple: if the SONET signal is indeed
> an
> > SDH signal, why do you bother with SONET ? Just ask for an SDH signal,
> > that's all.
> >
> > By the way, since according to some folks SONET is just a subset of SDH,
> why
> > do we care about SONET in these documents ? Why don't we simply remove all
> > references to SONET ?
> >
> > Is there somebody on this mailing list that cares about SONET ? If yes,
> why
> > ? Who is still manufacturing SONET boxes ? Why is that not called SDH ?
> >
> > Kind regards,
> >
> > Eric
> >
> > -----Original Message-----
> > From: Jonathan Sadler [mailto:[email-masked]]
> > Sent: Tuesday, December 18, 2001 9:57 PM
> > To: Mannie, Eric
> > Cc: 'Stephen Trowbridge'; Kireeti Kompella; [email-masked];
> > [email-masked]; [email-masked]
> > Subject: Re: GMPLS signaling documents updated per last calls
> >
> > Eric -
> >
> > Comments inline...
> >
> > Jonathan Sadler
> >
> > "Mannie, Eric" wrote:
> > > "A SONET signal which has an identical SDH signal SHOULD be requested
> > using
> > > the same traffic parameters as for the equivalent SDH signal, and will
> > > consequently use the SDH label."
> >
> > Why SHOULD and not MUST?  This ambiguity is likely to create
> > interoperability problems in the future...
> >
> > > We spend with Maarten a lot of time to write that sentence (not easy to
> > > write).
> > >
> > > Maybe that it should be better written:
> > >
> > > "A SONET signal which has an identical SDH signal SHOULD be requested as
> > an
> > > SDH signal using the same traffic parameters as for the equivalent SDH
> > > signal, and will consequently use the SDH label."
> >
> > Again, "SHOULD" needs to be replaced with "MUST"...
> >
> > > This doesn't mean that the SONET signal format disappear (simply not
> used
> > in
> > > that case), for backward compatibility we need to keep it.
> >
> > I'm curious what sort of backward compatability is necessary, as a
> > "standard" doesn't exist currently that this needs to be backward
> > compatible with...
> >
> > > Kind regards,
> > >
> > > Eric
> > >
> > > -----Original Message-----
> > > From: Stephen Trowbridge [mailto:[email-masked]]
> > > Sent: Tuesday, December 18, 2001 7:46 PM
> > > To: Kireeti Kompella
> > > Cc: [email-masked]; [email-masked]; [email-masked];
> > > [email-masked]; [email-masked]
> > > Subject: Re: GMPLS signaling documents updated per last calls
> > >
> > > Kireeti,
> > > The one outlyer is VT3 (3 Megabits). VC-3 is an extremely popular
> > > rate in both SONET and SDH. I exchanged an email with Deborah Brungard
> > > (T1X1.5 chair) on this one and I take the liberty of sharing her
> response:
> > >
> > > Deborah Brungard wrote:
> > > > The VT3 (3M) structure was defined - but no services (mappings) were
> > ever
> > > defined for it. So there are no services/equip
> > > > with it. My take was if in the future it was ever defined (doubtful),
> we
> > > would be adding it to g707 also. So then it
> > > > would just be part of g707 too.
> > >
> > > So basically, there are no mappings or equipment functions for this
> rate,
> > > and as far as we know no network equipment or networks supporting it.
> > > Deborah suggests that if we were ever to define such mappings, that this
> > > would be proposed for addition to G.707 and hence be part of SDH.
> > >
> > > I think our agreement had been to use the SDH label for all signals that
> > > had the same multiplex structure in SONET and SDH. In Salt Lake City, we
> > > thought
> > > that this was everything except VT3. Given that VT3 seems not to be a
> > "real"
> > > signal at this point and will likely be added to SDH if it ever becomes
> > > real, does our agreement then become that we use SDH labels for
> > everything?
> > >
> > > Regards,
> > > Steve
> > >
> > > Kireeti Kompella wrote:
> > > >
> > > > Hi Deborah,
> > > >
> > > > > I previously made the
> > > > > comments to merge the (1) SDH and SONET values as one value
> > > >
> > > > There was a meeting among Steve Trowbridge, Maarten Vissers,
> > > > Eric Mannie, Dimitri Papadimitriou, the CCAMP ADs and chairs on
> > > > several issues, among them this one.  The upshot was that whenever
> > > > possible, the SDH label should be used, with the encoding type
> > > > set to SDH (i.e., G.707); however, there are signals that have
> > > > no SDH equivalent (if I remember right, VC-3 -- someone correct
> > > > me!), so we will keep SONET labels and encoding types around
> > > > for that case and for legacy equipment.
> > > >
> > > > The revised SONET/SDH document will contain the exact wording.
> > > > I will also be sending a reply to the ITU communication stating
> > > > the agreement we came to.
> > > >
> > > > Kireeti.
--------------04787838FBA9204781476572
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------04787838FBA9204781476572--

Delivery-date: Fri, 21 Dec 2001 09:24:39 -0800
From: "Mannie, Eric" <[email-masked]>
To: 'Heiles Juergen' <[email-masked]>, ''John Drake' ' <[email-masked]>, 'Maarten Vissers ' <[email-masked]>,  'manoj juneja ' <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>
Subject: RE: Lambda LSP establishment
Date: Fri, 21 Dec 2001 18:21:01 +0100

Hello Juergen,

We already discussed it so many times....

FAs and links are two different objects. No routing adjacency over an FA
LSP. FAs are optional. You can route a VC-12 without having any FA. You can
have mini dummy VC-4 "circuits" just between two adjacent LSRs (VC-4 POH
terminated in two adjacent SDH/SONET nodes). These mini dummy VC-4 circuits
will not be seen as customer circuits. They don't need to be seen as FAs.

Kind regards,

Eric

-----Original Message-----
From: Heiles Juergen [mailto:[email-masked]]
Sent: Thursday, December 20, 2001 11:04 AM
To: Mannie, Eric; Heiles Juergen; ''John Drake' '; 'Maarten Vissers ';
'manoj juneja '
Cc: [email-masked] '
Subject: RE: Lambda LSP establishment

Hi Eric,

thanks for the explanation below. I have some further questions for
clarification and I also think an informational I-D would be helpful.

You said that from the routing point of view a link and an FA are two
different things. There is a routing adjacency "over" a link but not over a
FA.
I don't see the difference between a "physical link" and a FA as routing can
use both to establish a connection.
Furthermore for the SDH case if a VC-12 connection is setup via an existing
VC-4 connection the VC-4 connection is an FA according to my understanding.
However if a VC-4 connection is setup over a STM-16, the STM-16 is not a FA,
it is a link. Is this correct? From the VC-12 or VC-4 routing view point I
don't see a difference between the FA or link. Furthermore the STM-16
connection itself could be transported via an OCh or ODUk in a WDM system.
So it is not the physical interface of the equipment. Is it still a link and
no FA as from the physical topology only WDM (OTM-n) interfaces are seen.

Now concerning the setup of a VC-12 over a STM-16. In this case you use the
full SUKLM number. owever in order to make this connection a VC-4 or HO VC-3
connection has to be established prior to the VC-12 connection. Is this
implicitly assumed? After the setup of the VC-12 this V-4 or HO VC-3 exists.
Is it now seen as a FA?
Lets have a look on two examples:

(1) HO/LO(4/1)-DXC <---STM-16---> HO/LO(4/1)-DXC

(2) HO/LO(4/1)-DXC <---STM-16---> HO(4/4)-DXC <--- STM-16---> HO/LO(4/1)-DXC

In example 1 two 4/1 SDH cross-connects that support VC-12 and VC-4
switching are directly interconnected via a STM-16. In this case the VC-12
label could be defined in relation to the STM-16 interface with the full
SUKLM set. In the second example the two 4/1 cross-connects are
interconnected via a 4/4 cross-connect that supports only VC-4 switching. Do
we need a VC-4 FA in this case between the two 4/1 cross-connects to setup
the VC-12 connection?

Regards

Juergen

> -----Original Message-----
> From: Mannie, Eric [mailto:[email-masked]]
> Sent: Thursday, December 13, 2001 6:57 PM
> To: 'Heiles Juergen '; ''John Drake' '; 'Maarten Vissers '; 'manoj
> juneja '
> Cc: [email-masked] '
> Subject: RE: Lambda LSP establishment
> 
> 
> Hi All,
> 
> A few comments,
> 
> >In MPLS the FA establishes "virtual" layer networks. In 
> GMPLS the layer
> networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, 
> OCh, OMS, OTS). A
> FA basically corresponds to a real trail in a circuit 
> switched network.
> 
> Eric: ...and this trail is setup dynamically using GMPLS. That's the
> interest. One can think of SDH/SONET FAs as shortcuts or 
> express-routes.
> 
> >One special thing about the SDH label is, that it includes a 
> hierarchy as
> it identifies the lower order VC in a higher order VC in a 
> STM-N signal.
> Note that this is somehow in contradiction with a statement 
> in the GMPLS
> signaling document which says 
> 
> >"A Generalized Label only carries a single level of label, 
> i.e., it is 
>    non-hierarchical.  When multiple levels of label (LSPs 
> within LSPs) 
>    are required, each LSP must be established separately, see [MPLS- 
>    HIERARCHY]." 
> 
> No, hierarchy of labels is not hierarchy of layers. And even 
> one should have
> a common definition of what means a "layer". This text says 
> that we cannot
> have multiple embedded labels, e.g. one label containting a 
> label stack.
> This is a signaling stuff that doesn't imply anything on the transport
> plane.
> 
> Now, a label identifies ONE LSP at an interface. This LSP can 
> be HO or LO in
> SDH. The label can be fully specified or partially specified, 
> depending on
> the context where the LSP is established.
> 
> E.g. when an LSP is established over a FA, the highest part 
> of the LSP label
> is not relevant. When the FA LSP is established the lowest 
> part of the FA
> LSP label is not relevant.
> 
> If a low order LSP is established without any higher order 
> FA, the label is
> fully specified. As you said the link is indeed the "ultimate 
> FA" in that
> case. Except that from the routing point of view a link and 
> an FA are two
> different things. There is a routing adjacency "over" a link 
> but not over a
> FA.
> 
> The SDH/SONET label just includes what you need to include in 
> each scenario.
> 
> Moreover, the label MUST be interpreted according to the type 
> of interface
> for which it is used. It is possible to code two labels 
> having the same
> value but a complete different meaning. Labels are context 
> sensitive of
> course.
> 
> For instance, an LSP over an STM-0 interface or over a FA 
> will have the
> highest part set to zero, and could possibly have the same 
> lowest part. You
> cannot understand what means the label without knowning the 
> detail of the
> interface. In that case, the interface is either an STM-0 
> interface or a
> VC-3 FA. And of course that FA and STM-0 interface are two 
> different things,
> but from the LSP point of view, in both cases what it wants 
> is a VC-3 in
> which it can be multiplexed.
> 
> Hope this helps.
> 
> I start to wonder if we should have an informational draft describing
> different scenarios of SDH/SONET LSP establishment. That 
> could complement
> the SDH/SONET signaling drafts and the GMPLS architecture. 
> That could solve
> many terminology and modeling issues.
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Heiles Juergen
> To: 'John Drake'; Maarten Vissers; manoj juneja
> Cc: [email-masked]
> Sent: 12/13/01 11:15 AM
> Subject: RE: Lambda LSP establishment
> 
> Let me express my understanding of FAs in MPLS/GMPLS, please 
> correct me
> if I am wrong. I have also some questions related to the label
> generation and interactions between layer networks.
> 
> The label in MPLS is local to the link between two adjacent MPLS
> switches, it indicates a LSP in this link. This link is therefore the
> ultimate FA. An already established LSP between two MPLS 
> switches, which
> don't have to be adjacent, can be used to transport/tunnel other LSPs
> between this two nodes. This already established LSP 
> generates a virtual
> adjacency between the two nodes, the FA. As several LSPs can 
> use this FA
> it is also a kind of virtual multiplexing.
> If you compare it with a circuit switched network the FA is a server
> layer trail that provides transport (a link connection) for 
> one or more
> client layer signals.
> In MPLS the FA establishes "virtual" layer networks. In GMPLS 
> the layer
> networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, OCh, OMS,
> OTS). A FA basically corresponds to a real trail in a circuit switched
> network.
> In GMPLS the label is also local to the link between the two devices
> that perform the switching. For example for SDH the VC-N is identified
> by the STM-N link/port and the SUKLM number according to
> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt. The STM-N port is 
> identified by
> the interface ID (I am not sure on this) and SUKLM is the SDH 
> label that
> locates the VC within the STM-N.
> From just the SDH viewpoint the STM-N connection is the 
> ultimate server
> trail/FA. However the STM-N signal could be transported over a Optical
> Channel or G.709 ODU. The OCh or ODU can already start in the 
> equipment
> that performs the VC-N switching. So the STM-N signal is not the port,
> but the WDM signal is the port and the STM-N signal makes use of a OCh
> or ODU server layer trail. This server layer trail can be established
> via management or using GMPLS. 
> Can someone explain how a label for a VC-4 is generated in this case
> (pre-established OCh or ODU trail via management or setup 
> using GMPLS).
> This interaction between the different technologies/labels need in my
> view some further explanation.
> 
> One special thing about the SDH label is, that it includes a hierarchy
> as it identifies the lower order VC in a higher order VC in a STM-N
> signal. Note that this is somehow in contradiction with a statement in
> the GMPLS signaling document which says 
> "A Generalized Label only carries a single level of label, i.e., it is
>    non-hierarchical.  When multiple levels of label (LSPs within LSPs)
>    are required, each LSP must be established separately, see [MPLS-
>    HIERARCHY]."
> Following this statement each layer should have its own label
> independent of server layers.
> The combination of hierarchies in labels is based on technology (e.g.
> SDH, Sonet, G.709 ODU) but has in my view no real technical 
> reason. The
> SDH label for example fits to standard STM-N signals, but not 
> to sub-STM
> signals.
> For the SDH the full SUKLM number is used if a e.g. VC-12 is 
> located in
> relation to a STM-N interface. If it is located in relation to a VC-4
> (the VC-4 is in this case a FA) SUK are set to 0. For me it 
> is not clear
> in which case I use the first and in which case I use the 
> second case as
> a VC-4 trail is always needed for a VC-12 connection. This 
> VC-4 could be
> established using management or GMPLS. However it should have no
> influence on the label. 
> Some more information is needed in my view in this area.
> 
> 
> Juergen
>  
> 
> > -----Original Message-----
> > From: John Drake [mailto:[email-masked]]
> > Sent: Wednesday, December 12, 2001 6:54 AM
> > To: Maarten Vissers; manoj juneja
> > Cc: [email-masked]
> > Subject: RE: Lambda LSP establishment
> > 
> > 
> > fortunately, this is just your opinion
> > 
> > -----Original Message-----
> > From: Maarten Vissers [mailto:[email-masked]]
> > Sent: Tuesday, December 11, 2001 9:31 PM
> > To: manoj juneja
> > Cc: [email-masked]
> > Subject: Re: Lambda LSP establishment
> > 
> > 
> > Manoj,
> > 
> > Forget the FA stuff, it is not appropriate in circuit 
> > networks. It only
> > applies
> > to MPLS. We should remove it when it is used in relation with PDH,
> > SDH/SONET,
> > OTN and pre-OTN. The text in sdh-sonet draft should state 
> > that if there is a
> > LOVC link (IETF: link bundle/TE link) then the LOVC signals 
> > use a label with
> > "00KLM".
> > 
> > Regards,
> > 
> > Maarten
> > 
> > manoj juneja wrote:
> > > 
> > > Hi Marteen,
> > >             The concept of FA is mentioned for SDH/SONET in 
> > gmpls-sdh
> > > -sonet draft. It says that if u have a HOVC trail as a FA 
> > (advertized
> > > as a link) then u can allocate the lower level signals in 
> > it by making
> > > the higher bits of label as 0s (i.e. S and U}. This is fine 
> > for the same
> > > technology. What about the case where the TDM LSP has to 
> be tunneled
> > through
> > > the Lambda LSP ? What will be the form of label (i.e. 
> > {SUKLM} or lambda
> > > etc.) ?
> > > 
> > > Regards,
> > > manoj.
> > > 
> > > >From: Maarten Vissers <[email-masked]>
> > > >To: manoj juneja <[email-masked]>
> > > >CC: [email-masked]
> > > >Subject: Re: Lambda LSP establishment
> > > >Date: Tue, 11 Dec 2001 15:56:41 +0100
> > > >
> > > >Manoj,
> > > >
> > > >You refer to one wavelength to be available between A-E without
> > wavelength
> > > >conversion capability. This suggests that you operate at 
> > the OCh layer
> > > >network.
> > > >Then you specify the capacity of the 4 OCh link 
> > connections (A-B, B-C,
> > C-D,
> > > >D-E)
> > > >to be "C". Say that C is about 10 Gbit/s. You then assume 
> > that there is a
> > > >request for an OCh signal with capacity C/4 (e.g. 2.5 
> > Gbit/s) between C
> > and
> > > >E.
> > > >The result is that the OCh link connections C-D and D-E 
> > are transporting
> > > >the OCh
> > > >signal (of e.g. 2.5G). These OCh link connections are now 
> > in service and
> > > >not
> > > >longer available to an other OCh connection request. I.e. 
> > a request for
> > an
> > > >OCh
> > > >connection between A and E will be rejected.
> > > >
> > > >FAs are not applicable in the circuit layers. IF there is 
> > a trail in
> > server
> > > >layer X, then there is a link in its client layer Y. X and 
> > Y are thus
> > > >different
> > > >layer networks and signals.
> > > >
> > > >If C-E is a "FA", then in an OTN the C-E connection would 
> > be an OCh trail
> > > >supporting an ODUk (k=1 if OCh is 2G5) link with a single link
> > connection.
> > > >
> > > >Note a FA in MPLS creates essentially a MPLS sublayer 
> > network. Such is
> > not
> > > >possible in the SDH/SONET, OTN, PDH or ATM technologies.
> > > >
> > > >Regards,
> > > >
> > > >Maarten
> > > >
> > > >OCh link connections
> > > >
> > > >manoj juneja wrote:
> > > > >
> > > > > Hi All,
> > > > >         If I have 5 nodes A, B, C, D and E connected as 
> > shown. Assume
> > > > > that only one wavelength is available on the path A to E (no
> > wavelength
> > > > > conversion capability is there on the complete path). 
> > Let the capacity
> > > > > of the wavelength be C. Further assume a request arrives for
> > connection
> > > > > from node C to E for a line capacity of C/4. This 
> > request will be
> > > > > successful as we have available wavelength. Now If 
> > another request
> > > > > comes at node A to establish another connection from 
> > node A to node E
> > > > > via nodes {A,B,C,D,E} for a line capacity of C/4. 
> > Should this request
> > > > > be successful as we have already allocated the wavelength ?
> > > > >
> > > > > If the previous connection from C to E of capacity 
> C/4 had been
> > > > > advertised as a FA, in that case will the IInd 
> request succeed ?
> > > > >
> > > > > If the previous connection from C to E of capacity C/4 
> > had not been
> > > > > advertised as FA then what will be the fate of IInd 
> connection ?
> > > > >
> > > > >        A <--> B <---> C <----> D <---> <----> E
> > > > >
> > > > > Regards,
> > > > > manoj.
> > > > >
> > > > > 
> > _________________________________________________________________
> > > > > Get your FREE download of MSN Explorer at
> > > >http://explorer.msn.com/intl.asp
> > > ><< mvissers.vcf >>
> > > 
> > > _________________________________________________________________
> > > Send and receive Hotmail on your mobile device: 
> http://mobile.msn.com
> 

Delivery-date: Fri, 21 Dec 2001 08:38:16 -0800
From: "Mannie, Eric" <[email-masked]>
To: 'Maarten Vissers' <[email-masked]>
Cc: [email-masked]
Subject: RE: protection and restoration [was: Re: Moving right along ...   generalized-signaling-06]
Date: Fri, 21 Dec 2001 17:34:01 +0100

Maarten,

This is too big this time, usually you are more subtle :-)

Last attempt to convince everybody that GMPLS is for pre-OTN only and G.ASON
for OTN ?

So that GMPLS becomes a secondary and temporary control plane until we have
a G.ASON based ITU-T control plane that will be used for everything (and
that we will have in several years) :-)))

I liked your speech during the IESG plenary when you said that the "GMPLS
work just started in CCAMP" and when you presented G.ASON as almost
finished. From an honest perspective, it is exactly the opposite.

Since one cannot stop GMPLS, let's try to reduce the scope :-)))

You complained so many times that nobody is actively proposing GMPLS at the
ITU-T. If you could have spent the same energy that you are spending here
against GMPLS, rather proposing GMPLS at the ITU-T... The entire community
could have saved a lot of time and energy (or at least people on this
mailing list :-)))

Rgds,

Eric

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Wednesday, December 19, 2001 2:25 PM
To: Mannie, Eric
Cc: [email-masked]
Subject: protection and restoration [was: Re: Moving right along ...
generalized-signaling-06]

Eric,

One of the requirements we have to meet is that traffic of user A is not
delivered to user B. Also during recovery from a failed connection (either
by
means of protection swithcing, or restoration) we have to guarantee that
user A
traffic is not delivered to user B. This adds additional requirements to the
operation of the 1:1/ET (with extra traffic), 1:n, 1:n/ET, etc
architectures;
these have a potential to temporarily connect A to B.

In protection switching this is guaranteed by means of the combination of
protection architecture and protection switching protocol type (1-phase,
2-phase, 3-phase protocols). 
The tail end normal output #i of the protected domain will never select from
the
protection connection until it is guaranteed that normal input #i at the
head
end is bridged onto this protection connection. And vice versa, the tail end
will deselect the protection connection before the head end will put a
different
signal onto that protection connection.

I assume that for the case of restoration and fast restoration, the same
requirement is applicable. Has this requirement been considered in the work
on
fast restoration?

It looks like "fast restoration" is a control plane based protection
switching.
Is my understanding correct?

If so, with transport plane based protection switching build into SDH/SONET
and
OTN, is fast restoration being a pre-OTN feature? I assume there is no need
to
replace SDH/SONET/OTN transport plane based protection switching by control
plane based protection switching.
As pre-OTN (STM/OC-N or GE over WDM) doesn't have any protection switching
defined in the transport plane, pre-OTN has no alternative to control plane
based protection.

Regards,

Maarten

"Mannie, Eric" wrote:
> 
> Hello Stephen,
> 
> John refers to fast restoration schemes that are being studied at the
IETF.
> Such schemes are widely implemented in the new classes of optical/TDM
> equipments.
> 
> The wording of the text just need to use the terms "working" LSP and
> "protecting" LSP, instead of primary and secondary. That's just an editing
> modification.
> 
> The bit itself is useful to qualify the LSP being established.
> 
> The mechanisms to be applied to this qualification will be detailed in
other
> documents.
> 
> In the mean time, I guess that this bit can be used by implementations for
a
> simple restoration scheme (e.g. first establish working and protecting
LSPs,
> resources of protecting LSP may be "soft reserved", i.e. for
extra-traffic,
> when a fault occur send an RSVP-TE rapid failure notification to the
source,
> send Path with bit set to "working" on protecting LSP, this kills all LSPs
> using these resources, when acked switch to this LSP).
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Tuesday, December 18, 2001 7:38 PM
> To: John Drake
> Cc: Maarten Vissers; [email-masked]
> Subject: Re: Moving right along ... generalized-signaling-06
> 
> John,
> The problem here is that this is not compatible with transport plane
> protection.
> Assume you do 1:n MSP protection according to ITU Rec. G.841. The
operation
> of
> the protection group is controlled by exchange of the K1, K2 bytes in the
> MSOH of the PROTECTION MS. If the control plane reuses the protection MS
at
> for a different LSP at a time when the state of the protection group is
> "No Request" (assuming no extra traffic carried on the protection section
in
> the
> transport plane), this disables the protection since the endpoints of the
> protection group are no longer able to exchange K1, K2 over the protection
> channel. Even though the payload is unused and irrelevant to the transport
> plane at this point, the exchange of overhead is essential to proper
> operation
> of the protection group.
> Regards,
> Steve
> 
> John Drake wrote:
> >
> > Steven,
> >
> > The basic idea is that if a connection is of type 'secondary', then
other
> > LSPs of type 'primary' between the same or different source/destination
> > pairs MAY use its resources in intermediate nodes, until that LSP is
> > converted into a 'primary' with a subsequent Path/Resv flow.  At this
> point,
> > other LSPs that were using its resources may get pre-empted.  Think of
the
> > primary/secondary mechanism as a way to ensure temporal priority while
> > allowing network resources to be re-used; i.e., an LSP of type
'secondary'
> > is carrying no data.
> >
> > So in the 1:1 case the protect LSP could be established either as a
> primary
> > or secondary LSP, while in the 1:N case the protect LSP would be
> established
> > as a secondary.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:[email-masked]]
> > Sent: Thursday, December 13, 2001 12:15 PM
> > To: John Drake
> > Cc: Maarten Vissers; [email-masked]
> > Subject: Re: Moving right along ... generalized-signaling-06
> >
> > John,
> > It would seem from this standpoint, ANY transport plane protection
> > must use "primary" for all trails. You have already made this argument
> > for the 1+1 case to carry the permanently bridged copy of the payload.
> >
> > In 1:1 or 1:n, when protection is not being used to carry one/any of
> > the normal traffic signals, it may either carry a null signal (no
bridge)
> > or transport plane extra traffic. Even if the transport plane has only
> > a null signal on protection, the control plane cannot itself place extra
> > traffic on any portion of the end-to-end protection channel as this is
> > where the APS protocol is carried to coordinate the 1:1 or 1:n
protection.
> > The protection channel overhead is chosen to carry the APS since it is
> > necessary to exchange APS bytes to complete a switch when working
channels
> > are failed. If the protection channel has failed and APS cannot be
> > exchanged,
> > normal traffic signals will not be selected from protection.
> > Regards,
> > Steve
> >
> > John Drake wrote:
> > >
> > > Maarten,
> > >
> > > That's fine, however it's beside the point.  The semantics of
> > > Primary/Secondary refer to the control plane and whether the node
> > > establishing a given LSP is planning to use it at the time it's
> > established
> > > or at a later time.  As I indicated in an earlier note, 1+1 transport
> > plane
> > > protection would be accomplished in the control plane by establishing
> two
> > > LSPs of type Primary.  The control plane really doesn't care which LSP
> the
> > > transport plane is using as Working and which as Protect, although
that
> > > information is available to the control plane at the LSP endpoints.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Maarten Vissers [mailto:[email-masked]]
> > > Sent: Thursday, December 13, 2001 12:15 AM
> > > To: [email-masked]
> > > Subject: Re: Moving right along ... generalized-signaling-06
> > >
> > > There exist well defined protection terminology in ITU-T for the
> transport
> > > plane. "Working" and "Protection" are being used and not
> > primary/secondary.
> > > E.g.
> > > a 1+1 architecture has one working connection, one protection
connection
> > and
> > > a
> > > permanent bridge.
> > >
> > > Besides working/protection indication for the transport entity, there
is
> > > - "active" and "standby" to indicate if the signal is selected from
the
> > > working
> > > or protection transport entity; i.e. if selector selects from working,
> the
> > > working is active and protection is standby, if the selector selects
> from
> > > protection the working is standby and the protection is active.
> > > - "normal" and "extra traffic" signal. The normal signal is protected.
> > >
> > > Regards,
> > >
> > > Maarten
> > >
> > > [email-masked] wrote:
> > > >
> > > > Jonathan....review the text below....I think the problem is 1:1.
> > > >
> > > > neil
> > > >
> > > > > -----Original Message-----
> > > > > From: Jonathan Lang [mailto:[email-masked]]
> > > > > Sent: 12 December 2001 17:46
> > > > > To: 'Ben Mack-Crane'; John Drake
> > > > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > > > Subject: RE: Moving right along ... generalized-signaling-06
> > > > >
> > > > >
> > > > > Ben,
> > > > >   Please see inline.
> > > > >
> > > > > Thanks,
> > > > > Jonathan
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > > > Sent: Wednesday, December 12, 2001 8:56 AM
> > > > > > To: John Drake
> > > > > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > > > >
> > > > > >
> > > > > > See comment below.
> > > > > >
> > > > > > Regards,
> > > > > > Ben
> > > > > >
> > > > > > John Drake wrote:
> > > > > > >
> > > > > > > Snipped
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > > > > Sent: Tuesday, December 11, 2001 6:38 AM
> > > > > > > To: Lou Berger
> > > > > > > Cc: Kireeti Kompella; [email-masked]
> > > > > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >7) In Protection Information it states "The resources
> > > > > > allocated for a
> > > > > > > > >    secondary LSP MAY be used by other LSPs until the
> > > > > > primary LSP fails
> > > > > > > > >    over to the secondary LSP."  This may not always be
> > > > > > the case.  An
> > > > > > > > >    explicit flag indicating whether or not extra
> > > > > > traffic may use the
> > > > > > > > >    secondary path resources is needed.
> > > > > > > >
> > > > > > > > ??? This is the purpose of this bit.
> > > > > > >
> > > > > > > This is not clear from the definition.  The bit is defined
> > > > > > as indicating
> > > > > > > the LSP is a secondary (or protecting) LSP and in 1+1
> > > > > protection the
> > > > > > > secondary LSP may not be used for extra traffic.
> > > > > > >
> > > > > > > Perhaps the problem here is that protection features are
> > > > > > being defined
> > > > > > > before the protection framework and requirements are
> > > > > done.  Is this
> > > > > > > presupposing some particular outcome of the recovery work in
> CAMP?
> > > > > > >
> > > > > > > JD:  I think the definition of the bit is fine.  For both
> > > > > > 1+1 and 1:1
> > > > > > > protection, there would be a pair of Primary LSPs between
> > > > > the source
> > > > > > > and destination, rather than a Primary and a Secondary.
> > > > > >
> > > > > > This is an unusual use of terms.  I have never encountered a
case
> > > > > > where both the working and recovery paths are call "primary."
> > > > > >
> > > > > > This is not consistent with either draft-mpls-recovery-framework
> > > > > > or with draft-lang-ccamp-recovery.  I think this is a sign that
> the
> > > > > > protection work is immature and not ready for progressing to
RFC.
> > > > > >
> > > > > For 1+1 path protection, both working/recovery paths are
> > > > > carrying user data
> > > > > traffic and it is an endpoint decision as to which path is
> > > > > actually the
> > > > > working/recovery path.  At a transit node, both paths need to
> > > > > be treated as
> > > > > primary, as the resources are currently being used and
> > > > > obviously can't be
> > > > > used for Extra Traffic.
> > > > >

Delivery-date: Fri, 21 Dec 2001 08:04:01 -0800
From: "Mannie, Eric" <[email-masked]>
To: 'Maarten Vissers' <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>,  'Stephen Trowbridge' <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked], [email-masked],  [email-masked]
Subject: RE: GMPLS signaling documents updated per last calls
Date: Fri, 21 Dec 2001 17:02:34 +0100

Hello Maarten,

> It is not the intention to leave the choice of LSP encoding type and SU
label
structure to the vendor. This would give immediate interworking problems.

Sorry but this comment doesn't make sense. Of course if one implements an
IP-LSR it could not speak SDH ! The vendor has the choice of the type of box
he wants to implement (IP, ethernet, ATM, SDH, SONET, photonic,...). Of
course we leave the choice of the supported LSP encoding types to the
vendors !

The label structure is defined in the draft.

> VC-11/VT1.5, VC-12/VT-2, VC-2/VT-6, VC-3/STS-1, VC-4/STS-3c,
VC-4-4c/STS-12c,
VC-4-16c/STS-48c, VC-4-64c/STS-192c and VC-4-256c/STS-768c must all have LSP
encoding type "SDH". Also STS-1/STM-0 upto STM-256/STS-768 must have the LSP
encoding type "SDH".

No, not necessarily. Why do you want to reject all SONET implementations ?

> VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, VC-4-16c/STS-48c,
VC-4-64c/STS-192c
and VC-4-256c/STS-768c must all have the same SDH-based "SU" structure. 

No, not necessarily. Why do you want to reject all SONET implementations ?

> Looking at the label text in section 3 of the sonet-sdh document, I find
it very
confusing to read that SONET doesn't use the "U" field. 

This didn't change since 1 or 2 years.

By the way, I thought that we reached an agreement ?

> As we indicated before there is no STS type signal that isn't having an
SDH equivalent; i.e. there are no specific higher order SONET signals left.
It is therefore much better to take out the SONET text for the SU label part
altogether.

It is not only a matter of the signal type field in the draft, it is also a
matter of how the network is monitored/operated. A SONET signal is not
always 100% compatible with an SDH signal. It depends on the profile used in
SDH and SONET. For sure there are different profiles for SONET and SDH (e.g.
differences in overhead: SS bit, J0, S1, J1, B3, G1, etc). We understood
that there is a join effort between T1 and ITU to reduce these differences,
but you cannot assume that everybody will adapt to/implement the latest
(draft) version of the transport plane standards.

Indeed, I think that we should have much more than just than two LSP
encoding types (SDH and SONET),  but that we should in addition indentify
profiles. Having SDH and SONET is a strict minimum. Making mandatory the use
of one single LSP encoding type for both SONET and SDH is lying to the
people. It will make GMPLS impossible to use in practice.

Anyway, as you said there are different profiles in SDH, and different
profiles in SONET. The difference between SDH and SONET comes from the fact
that they use different profiles (they can also use the same). In the LSP
encoding type, when we use SONET, we mean a different profile than SDH. We
wanted to have more profiles (e.g. SDH1996, etc) identified but you didn't
want.

If I understood, your idea is to have a second signaling protocol doing a
second pass to setup the profile. Having a control plane with several
signaling round trips and different signaling protocols to setup one single
circuit is a complete mistake from my point of view and from my control
plane design experience. Of course since you want to impose this second
signaling pass, you need to impose a single unique LSP encoding type for
both SDH and SONET so that we will be obliged to use another pass to make
the distinction. I think that now everybody can understand what you have in
mind but don't want to explain.

>Otherwise we will get a lot of confusion in the marketplace.

I think that you are creating the confusion by claiming that there is no
difference at all between SDH and SONET.

> Also the examples with STS-1 (examples 3 to 5 in secton 3) must use the
label
with U in the range 2 to 4; the STS-1 is equivalent to the VC-3 in SDH and
must
thus use the "SDH" SU format.

We are back at the beginning of the discussion... for the Xth time ! As
usual.

Rgds,

Eric

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Wednesday, December 19, 2001 9:05 AM
To: Mannie, Eric
Cc: [email-masked]'; 'Stephen Trowbridge'; Kireeti
Kompella; [email-masked]; [email-masked]; [email-masked]
Subject: Re: GMPLS signaling documents updated per last calls

Eric,

It is not the intention to leave the choice of LSP encoding type and SU
label
structure to the vendor. This would give immediate interworking problems.

VC-11/VT1.5, VC-12/VT-2, VC-2/VT-6, VC-3/STS-1, VC-4/STS-3c,
VC-4-4c/STS-12c,
VC-4-16c/STS-48c, VC-4-64c/STS-192c and VC-4-256c/STS-768c must all have LSP
encoding type "SDH". Also STS-1/STM-0 upto STM-256/STS-768 must have the LSP
encoding type "SDH".

VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, VC-4-16c/STS-48c,
VC-4-64c/STS-192c
and VC-4-256c/STS-768c must all have the same SDH-based "SU" structure. 

Looking at the label text in section 3 of the sonet-sdh document, I find it
very
confusing to read that SONET doesn't use the "U" field. As we indicated
before
there is no STS type signal that isn't having an SDH equivalent; i.e. there
are
no specific higher order SONET signals left. It is therefore much better to
take
out the SONET text for the SU label part altogether. Otherwise we will get a
lot
of confusion in the marketplace.

Also the examples with STS-1 (examples 3 to 5 in secton 3) must use the
label
with U in the range 2 to 4; the STS-1 is equivalent to the VC-3 in SDH and
must
thus use the "SDH" SU format.

-------

All,

With the clarification on VT-3 given by Deborah, I would request to consider
a
further simplification of the GMPLS standard: delete the LSP encoding type
"SONET" and rename the LSP encoding type "SDH" into "SDH/SONET". Then there
would be no ambiguity left at all.

Regards,

Maarten

"Mannie, Eric" wrote:
> 
> Hi Jonathan,
> 
> > Why SHOULD and not MUST?  This ambiguity is likely to create
> interoperability problems in the future...
> 
> To leave to the manufacturer and to the user the right to decide if he/she
> wants to signal an LSP as either SDH or SONET. There is no
interoperability
> problem at all since you use EITHER SDH OR SONET. If you decide to request
> an SDH signal with what do you want to have interoperability issue at this
> stage ? The sentence means indeed "one should better use SDH than SONET" !
> Once you decided, there is no issue.
> 
> > I'm curious what sort of backward compatability is necessary, as a
> "standard" doesn't exist currently that this needs to be backward
> compatible with...
> 
> Backward compatibility with the OIF UNI 1.0 Implementation Agreement, with
> the implementations that could not care of SDH, with implementations that
> still do a distinction between SONET and SDH for some reasons, with the
> implementations that could still use the VT3 (DS1C) (I don't have
> confirmation that nobody is using it today, and this is not the goal of
this
> draft to state what is obsolete or not in SONET), etc.
> 
> Anyway, there is no issue, the SONET label format is not used until SONET
is
> explicitly requested as such. This is not a primary feature of the draft,
> but a *secondary feature*, for SONET lovers. Otherwise, SDH is used for
> everything, consequently you don't care of the SONET label, you skip it in
> the draft, you ignore it, you don't implement it and you just use a full
SDH
> implementation.
> 
> I think that the solution is quite simple: if the SONET signal is indeed
an
> SDH signal, why do you bother with SONET ? Just ask for an SDH signal,
> that's all.
> 
> By the way, since according to some folks SONET is just a subset of SDH,
why
> do we care about SONET in these documents ? Why don't we simply remove all
> references to SONET ?
> 
> Is there somebody on this mailing list that cares about SONET ? If yes,
why
> ? Who is still manufacturing SONET boxes ? Why is that not called SDH ?
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Jonathan Sadler [mailto:[email-masked]]
> Sent: Tuesday, December 18, 2001 9:57 PM
> To: Mannie, Eric
> Cc: 'Stephen Trowbridge'; Kireeti Kompella; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: GMPLS signaling documents updated per last calls
> 
> Eric -
> 
> Comments inline...
> 
> Jonathan Sadler
> 
> "Mannie, Eric" wrote:
> > "A SONET signal which has an identical SDH signal SHOULD be requested
> using
> > the same traffic parameters as for the equivalent SDH signal, and will
> > consequently use the SDH label."
> 
> Why SHOULD and not MUST?  This ambiguity is likely to create
> interoperability problems in the future...
> 
> > We spend with Maarten a lot of time to write that sentence (not easy to
> > write).
> >
> > Maybe that it should be better written:
> >
> > "A SONET signal which has an identical SDH signal SHOULD be requested as
> an
> > SDH signal using the same traffic parameters as for the equivalent SDH
> > signal, and will consequently use the SDH label."
> 
> Again, "SHOULD" needs to be replaced with "MUST"...
> 
> > This doesn't mean that the SONET signal format disappear (simply not
used
> in
> > that case), for backward compatibility we need to keep it.
> 
> I'm curious what sort of backward compatability is necessary, as a
> "standard" doesn't exist currently that this needs to be backward
> compatible with...
> 
> > Kind regards,
> >
> > Eric
> >
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:[email-masked]]
> > Sent: Tuesday, December 18, 2001 7:46 PM
> > To: Kireeti Kompella
> > Cc: [email-masked]; [email-masked]; [email-masked];
> > [email-masked]; [email-masked]
> > Subject: Re: GMPLS signaling documents updated per last calls
> >
> > Kireeti,
> > The one outlyer is VT3 (3 Megabits). VC-3 is an extremely popular
> > rate in both SONET and SDH. I exchanged an email with Deborah Brungard
> > (T1X1.5 chair) on this one and I take the liberty of sharing her
response:
> >
> > Deborah Brungard wrote:
> > > The VT3 (3M) structure was defined - but no services (mappings) were
> ever
> > defined for it. So there are no services/equip
> > > with it. My take was if in the future it was ever defined (doubtful),
we
> > would be adding it to g707 also. So then it
> > > would just be part of g707 too.
> >
> > So basically, there are no mappings or equipment functions for this
rate,
> > and as far as we know no network equipment or networks supporting it.
> > Deborah suggests that if we were ever to define such mappings, that this
> > would be proposed for addition to G.707 and hence be part of SDH.
> >
> > I think our agreement had been to use the SDH label for all signals that
> > had the same multiplex structure in SONET and SDH. In Salt Lake City, we
> > thought
> > that this was everything except VT3. Given that VT3 seems not to be a
> "real"
> > signal at this point and will likely be added to SDH if it ever becomes
> > real, does our agreement then become that we use SDH labels for
> everything?
> >
> > Regards,
> > Steve
> >
> > Kireeti Kompella wrote:
> > >
> > > Hi Deborah,
> > >
> > > > I previously made the
> > > > comments to merge the (1) SDH and SONET values as one value
> > >
> > > There was a meeting among Steve Trowbridge, Maarten Vissers,
> > > Eric Mannie, Dimitri Papadimitriou, the CCAMP ADs and chairs on
> > > several issues, among them this one.  The upshot was that whenever
> > > possible, the SDH label should be used, with the encoding type
> > > set to SDH (i.e., G.707); however, there are signals that have
> > > no SDH equivalent (if I remember right, VC-3 -- someone correct
> > > me!), so we will keep SONET labels and encoding types around
> > > for that case and for legacy equipment.
> > >
> > > The revised SONET/SDH document will contain the exact wording.
> > > I will also be sending a reply to the ITU communication stating
> > > the agreement we came to.
> > >
> > > Kireeti.

Delivery-date: Fri, 21 Dec 2001 07:12:57 -0800
From: "Mannie, Eric" <[email-masked]>
To: 'Heiles Juergen' <[email-masked]>,  "[email-masked] '" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>
Subject: RE: Revised GMPLS SONET/SDH drafts
Date: Fri, 21 Dec 2001 16:09:11 +0100

Hello Juergen,

>a took me a while to detect the agreements related to the label in the
updated text as the label section still defines SDH and SONET labels in full
details without mentioning the SDH labels should be used also for SONET
signals. This new sentence in the introduction is very likely to be
forgotten/not noticed and in the end we might get even more
confusion/interop problems.

I will repeat the agreed sentence once more at the beginning of the section
defining the label.

>AS you mentioned in one of the other e-mails that the SONET label is kept
for interoperability issues with existing implementations (e.g. OIF UNI1.0)

No, that's not what I said. By the way, OIF UNI 1.0 is not an implementation
but an Implementation Agreement (i.e. a standard from the point of view of a
large part of the community). There were also several reasons mentioned in
my e-mail.

>it would be better to explicitly mention this and have the whole SONET
definitions separate.

Now you want to have two separate labels ! The SONET and SDH labels are
jointly defined since they are very similar up to one given point. I am
little bit confused now, you requested many times to have a common
definition, and now you don't want it anymore.

I will repeat the agreed sentence once more at the beginning of the section
defining the label. I hope that we don't have to repeat each sentence twice
in a standard, otherwise all RFCs will be twice longer :-)

>At the end of the label section a new paragraph is added concerning
transparent concatenated  STM-N signals.

Yes, it was requested during the last last call for clarification (by Manoj
or you, I don't remember).

>I assume this is a signal with signal type STM-N/STS-3*N, transparency flag
set and NCC>1.

No, NCC = 1 as defined in the NCC section (note 2).

>This leads to two questions:
>What is the SUKLM label for a transparent STM-N without concatenation
explicitly requested (Do we need a SUKLM label at all)?

In that example the label is exactly the same with or without concatenation,
with or without transparency. We added this paragraph because we were told
(by you ?) that the other cases were obvious but that this one (i.e. STM-N,
transparency and concatenation) was not... Anyway, I will add "with or
without" to further further clarify.

As far as I know one always need a label with GMPLS, simply because the
protocol and the code assume that a label will be returned in all cases.
Simple.

>Why is the case of transparency + contiguous concatenation (actually a
contradiction in it self) special from the general transparency case and has
to be mentioned.

We already discussed this and I already answered several times. I don't have
something more to say than the last time (and you didn't ask more :-).

Kind regards,

Eric

-----Original Message-----
From: Heiles Juergen [mailto:[email-masked]]
Sent: Thursday, December 20, 2001 1:08 PM
To: Mannie, Eric; [email-masked] '
Cc: [email-masked] '
Subject: RE: Revised GMPLS SONET/SDH drafts

Hi Eric,

a took me a while to detect the agreements related to the label in the
updated text as the label section still defines SDH and SONET labels in full
details without mentioning the SDH labels should be used also for SONET
signals. This new sentence in the introduction is very likely to be
forgotten/not noticed and in the end we might get even more
confusion/interop problems.
AS you mentioned in one of the other e-mails that the SONET label is kept
for interoperability issues with existing implementations (e.g. OIF UNI1.0)
it would be better to explicitly mention this and have the whole SONET
definitions separate.

At the end of the label section a new paragraph is added concerning
transparent concatenated  STM-N signals. I assume this is a signal with
signal type STM-N/STS-3*N, transparency flag set and NCC>1. This leads to
two questions:
What is the SUKLM label for a transparent STM-N without concatenation
explicitly requested (Do we need a SUKLM label at all)?
Why is the case of transparency + contiguous concatenation (actually a
contradiction in it self) special from the general transparency case and has
to be mentioned.

The STM-0 SUKLM definition (S=0) is different from the STS-1 definition
(S=1), also both are the same signal. As the STM-0 definition was just
introduced it could have been made the same as the existing STS-1
definition. 

Regards

Juergen

> -----Original Message-----
> From: Mannie, Eric [mailto:[email-masked]]
> Sent: Friday, December 14, 2001 1:00 AM
> To: [email-masked] '
> Cc: [email-masked] '
> Subject: Revised GMPLS SONET/SDH drafts
> 
> 
> 
> Dear All,
> 
> Please find attached the two GMPLS SDH/SONET drafts revised 
> according to the
> comments received during the last period of comments, and 
> during the Salt
> Lake City meeting:
> 
> - draft-ietf-ccamp-gmpls-sonet-sdh-03.txt
> - draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt
> 
> Please, send your comments to the mailing list AND to us.
> 
> Kind regards,
> 
> Eric and Dimitri
> 
> 

Delivery-date: Thu, 20 Dec 2001 17:18:19 -0800
From: "Raju Venkatraman" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Reception of RSVP packets at intermediate node
Date: Fri, 21 Dec 2001 01:16:40 +0000

Hi,

Can someone point me to these SunOS patches that were required to fix the 
problem of RSVP packets interception and reception at intermedite nodes. Are 
they publically available at some site?????

How does the other protable implementations take care of it when they run 
over SunOS/Solaris??? Which socket option they use?

Any help shall be greatly appreciated.
Regards.
Raju

>From: Ping Pan <[email-masked]>
>To: David Charlap <[email-masked]>
>CC: [email-masked]
>Subject: Re: Reception of RSVP packets at intermediate node
>Date: Thu, 13 Dec 2001 15:45:34 -0800
>
>Hi,
>
>There are several ways to receive RSVP Path messages (the Resv messages
>can be sent hop-by-hop):
>
>1. Both FreeBSD and Linux have modified the IP forwarding in the kernel
>to send/receive IP Router Alert packets via a raw socket.
>
>2. You can also use ipfw to define some filters to intercept the messages.
>
>3. In my past life, I had written a kernel extension for FreeBSD that
>can intercept all sort of IP option packets via a new socket family.
>Check http://www.cs.columbia.edu/~pingpan/software_list.htm
>
>4. I recall Don Hoffman and Mike Speer had done SunOS patches. Check
>http://www.isi.edu/div7/rsvp/release.html
>
>Take care!
>
>- Ping
>
>
>
>David Charlap wrote:
>
>>Raju Venkatraman wrote:
>>
>>>I'd appreciate any help to my question.
>>>
>>>Is there a socket option to intercept and receive RSVP protocol
>>>messages at intermediate node on Sun Solaris [reception of packets
>>>not destined to this intermediate node]?
>>>
>>
>>Sounds like this question would be better asked on a forum for Solaris
>>programming.  Perhaps comp.unix.programmer, comp.unix.solaris, or one of
>>the comp.sys.sun groups.
>>
>>I am, unfortunately not familiar with Solaris, but I seem to remember
>>that a kernel patch was required to make router alert work on SunOS
>>version 4.x.  A similar patch may be required for Solaris.
>>
>>-- David
>>
>>
>
>

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

Delivery-date: Thu, 20 Dec 2001 14:51:38 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Fwd: Issue in Label Set Object structure
Date: Thu, 20 Dec 2001 15:50:28 -0700

Re-sending it ....

Hi All,

        There seems to be some issue with the label set format. Can I
include the virtually concatenated SDH/SONET signal in the label set ?

If I want to have multiple subchannel elements in the label set
(basically a set of labels in the label set instead of range) then
how to determine that how many # of 4 byte octets comprise one virtual
concatenated signal ?
Or Is it that the subchannel element within the label set will also
include the object header for generalized label ?

Please let me know if I am missing something.
Regards,
manoj.

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

Delivery-date: Thu, 20 Dec 2001 12:28:54 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: Re: Fwd: Comments on GMPLS signalling drafts
Date: Wed, 19 Dec 2001 22:45:24 -0700

Hi Sudheer,
            I fully support your idea. My only concern was to atleast list 
down the features in the specifications/drafts that are 100 % complete and 
IETF community is in full or rough consensus and also the list of features 
(i.e. bandwidth modification and waveband) which are under study/discussion 
(for which agreement yet to be made).
Furthermore, the bandwidth modification of all the technologies should
be mentioned (not only TDM). If IETF is currently considering the
bandwidth modification of TDM LSPs and want to start on the bandwidth
modification of other technologies later on then this should be
mentioned too.

Regards,
manoj.

>From: Sudheer Dharanikota <[email-masked]>
>To: manoj juneja <[email-masked]>
>CC: [email-masked], [email-masked], 
>[email-masked],        [email-masked]
>Subject: Re: Fwd: Comments on GMPLS signalling drafts
>Date: Wed, 19 Dec 2001 17:59:49 -0800
>
>Hi Manoj:
>
>You are asking for improvising GMPLS documents on bandwidth modification,
>which is still in infacy stage at ITU. We should draw line some where,
>as to which features will go into first version of the GMPLS standard.
>
>- sudheer
>
>
>manoj juneja wrote:
>
> > Hi Dimitri,
> >                My main concern was that if some topic is still being
> > discussed (like waveband and bandwidth modification for TDM LSPs), it
> > should be mentioned in the drafts that these sections are still not
> > complete and are under discussions/further study. To a reader of the
> > GMPLS drafts it should be clear that what all features are fully
> > specified by the IETF and there is no further conflict in the industry.
> > I still feel that there should be some reference for the bandwidth
> > modification for all the technologies (SDH/SONET, LSC and FSC) in the
> > drafrs.
> >
> > After reading the drafts one can question that :
> >
> > a) Can I increase the bandwidth of a TDM/FSC/LSC LSP ? If yes then
> > how ? Even one can question that is it under the scope of GMPLS ?
> >
> > These comments are just for completeness of the drafts before proceeding 
>to
> > the RFC status.
> >
> > Regards,
> > manoj.
> >
> > >From: Dimitri Papadimitriou <[email-masked]>
> > >To: manoj juneja <[email-masked]>
> > >CC: [email-masked], [email-masked], [email-masked]
> > >Subject: Re: Fwd: Comments on GMPLS signalling drafts
> > >Date: Wed, 19 Dec 2001 18:35:55 +0100
> > >
> > >Manoj,
> > >
> > >On the following "bandwidth modification" and "waveband switching":
> > >
> > >The first one is an ongoing topic discussed for instance in
> > 
> >http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
> > >that will be reviewed and updated for the next upcoming meetings
> > >
> > >On "waveband switching" the question is do we consider something
> > >further than what's already included in the version -07.txt. We
> > >have provided for this purpose some ideas in:
> > 
> >http://www.ietf.org/internet-drafts/draft-douville-ccamp-gmpls-waveband-extensions-00.txt
> > >
> > >CCAMP (and IETF) community should tell us if it is worth going on
> > >with the latter topic. If there is any interest, etc. But anyhow
> > >this is for further discussion (i.e. not within the scope of the
> > >current last call). It is now greatly time to move on (as said by
> > >Lou)...
> > >
> > >Regards,
> > >- dimitri.
> > >
> > >manoj juneja wrote:
> > > >
> > > > Hi Lou/Eric/Dimitri,
> > > >
> > > >   Please see the following para from gmpls-architecture draft :
> > > >
> > > >    "LSP modification consists in changing some LSP parameters, but
> > > >    normally without changing the route. It is supported using the
> > > >    same mechanism as re-routing. However, the semantic of LSP
> > > >    modification will differ from one technology to the other. For
> > > >    instance, further studies are required to understand the impact
> > > >    of dynamically changing some SDH/SONET circuit characteristics 
>such
> > > >    as the bandwidth, the protection type, the transparency, the
> > > >    concatenation etc."
> > > >
> > > > If u say that SE style of reservation is supported then how are u 
>going
> > >to
> > > > share the bandwidth of SDH/SONET, Lambda or Fiber LSPs ? How can one
> > >assign
> > > > diferent labels (labels are the physical resources on the link) to
> > >different
> > > > senders that belong to the same RSVP session. Is it  that the SE 
>style
> > >of
> > > > reservation only supported to modify the bandwidth of LSP ? Can I 
>modify
> > >the
> > > > bandwidth of LSC/FSC LSP ? If yes then how ?
> > > >
> > > > Do u people think that waveband section is compelte in the drafts ?
> > > >
> > > > Please see other comments inline.
> > > >
> > > > Regards,
> > > > manoj.
> > > >
> > > > >From: Lou Berger <[email-masked]>
> > > > >To: "manoj juneja" <[email-masked]>
> > > > >CC: <[email-masked]>,<[email-masked]>,
> > > > ><[email-masked]>
> > > > >Subject: Re: Fwd: Comments on GMPLS signalling drafts
> > > > >Date: Fri, 14 Dec 2001 15:18:34 -0500
> > > > >
> > > > >see comments inline.
> > > > >
> > > > >At 09:10 PM 12/13/2001, manoj juneja wrote:
> > > > >
> > > > >
> > > > >
> > > > >> >From: "manoj juneja" <[email-masked]>
> > > > >> >To: [email-masked]
> > > > >> >Subject: Comments on GMPLS signalling drafts
> > > > >> >Date: Tue, 11 Dec 2001 16:15:10 -0700
> > > > >> >
> > > > >> >Hi All,
> > > > >> >
> > > > >> >1. SE-style supported by GMPLS or not ?
> > > > >> >
> > > > >
> > > > >GMPLS doesn't modify this.  See the appropriate base protocol docs.
> > > > >
> > > > >>As labels are the resources on the link, one can't allocate 
>different
> > > > >> >label to different senders in the same RSVP session.
> > > > >> >
> > > > >
> > > > >I don't think you fully understand SE.  I suggest you read the base
> > > > >documents. (2205 and RSVP-TE)
> > > > >
> > > > >>
> > > > >> >2. Bandwidth modification for TDM, LSC and FSC LSPs. There is a
> > > > >> >separate draft for TDM LSP bandwidth modification but what about 
>the
> > > > >> >bandwidth modification for other types of LSPs ? There is no 
>mention
> > >of
> > > > >> >these in any of the GMPLS drafts.
> > > > >> >
> > > > >
> > > > >GMPLS doesn't modify this.  See the appropriate base protocol docs.
> > > > >
> > > > >>
> > > > >> >3. It should be mentioned clearly that waveband section is still 
>not
> > > > >> >complete in the drafts.
> > > > >> >
> > > >
> > > > >> >4. For IF_ID_RSVP_HOP object, there are couple of TLVs defined. 
>What
> > > > >> >about the Component_If_Id_Downstream/Upstream TLV ? The revised
> > > > >> >bundling draft has removed these 2 TLVs. What about the GMPLS
> > >signalling
> > > > >> >drafts ?
> > > > >> >
> > > > >
> > > > >It's still in, see the drafts for explanations.
> > > > >
> > > > [Manoj]: What I want to say is that Component_If_Id_Downstream and
> > >Upstream
> > > > TLVs of IF_ID_RSVP_HOP object have been removed from the bundling 
>draft.
> > >Do
> > > > u still want to keep these TLVs in GMPLS drafts ? If yes then is 
>there
> > >any
> > > > reason for keeping these ?
> > > >
> > > > >> >5. STM-0 label representation using {SUKLM} should be mentioned 
>in
> > >the
> > > > >> >drafts (because it is a special case).
> > > > >> >
> > > > >
> > > > >the sonet draft is the right place for this.  I defer to Eric on 
>this.
> > > > >
> > > > [Manoj]: Thanks for putting this info in the new version of the 
>draft.
> > > > >>
> > > > >> >6. It should be mentioned that bandwidth encoding parameter is
> > >useful
> > > > >> >for what all type of LSPs i.e. TDM, LSC, FSC, PSC etc.
> > > > >> >
> > > > [Manoj]: I think u should include what all technologies will make 
>use of
> > > > this parameter.
> > > >
> > > > >> >7. There is an example scenario for contention resolution in 
>case of
> > >bi-
> > > > >> >directional LSPs. It should be mentioned that  :
> > > > >> >
> > > > >> >"contention resolution is an optimization, not a correctness 
>issue
> > >...
> > > > >> >and no procedure can provide optimal resolution in all cases. An
> > > > >> >implementor
> > > > >> >may do differently to provide better resolution."
> > > > >> >
> > > > >> >The above quotes are extracted from one of the mails from Fong 
>Liaw.
> > > > >> >
> > > > >> >If this is the case then this should be mentioned in the drafts.
> > > > >> >
> > > > >
> > > > >Read the Acknowledgments section of the draft.  (I'm sure Fong will 
>be
> > > > >happy to see you protecting her interests!)
> > > > >
> > > > >>
> > > > >> >8. The LSP hierarchy concept is still not clear. Some days back 
>I
> > >posted
> > > > >> >one
> > > > >> >doubt related to tunneling of TDM LSP over Lambda LSP using the
> > >concept
> > > > >>of
> > > > >> >forwarding adjacency and different people replied with different
> > > > >>thoughts.
> > > > >> >Does this mean this concept is not standardized in GMPLS ?
> > > > >> >My question was :
> > > > >> >
> > > > >> >"If there are 4 nodes say A, B, C and D. There is a Lambda FA
> > > > >> >established from A to D and if a new TDM LSP request comes to 
>node A
> > > > >> >which is to be tunneled through the already established lambda
> > >FA-LSP
> > > > >> >then the node A sends the Path/label request message directly to
> > >node
> > > > >> >D. What label the node D will send back to node A in the 
>RESV/label
> > > > >> >mapping message since the FA-LSP is just one label (lambda) ? 
>Does
> > >it
> > > > >> >mean that all the LSPs which are tunneled through the lambda 
>FA-LSP
> > > > >> >will be allocated the same label by node D to node A ? If this 
>type
> > >of
> > > > >> >scenario can't exist in GMPLS then please let me know that too."
> > > > >
> > > > >I believe this topic is being covered in other threads.
> > > > >
> > > > >> >
> > > > >> >
> > > > >> >Regards,
> > > > >> >manoj.
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> 
> >_________________________________________________________________
> > > > >> >Join the world s largest e-mail service with MSN Hotmail.
> > > > >> ><http://www.hotmail.com>http://www.hotmail.com
> > > > >> >
> > > > >> >
> > > > >>
> > > > >>_________________________________________________________________
> > > > >>Get your FREE download of MSN Explorer at
> > > > 
> >><http://explorer.msn.com/intl.asp>http://explorer.msn.com/intl.asp.
> > > > >
> > > > >
> > > >
> > > > _________________________________________________________________
> > > > Join the world’s largest e-mail service with MSN Hotmail.
> > > > http://www.hotmail.com
> > ><< dimitri.papadimitriou.vcf >>
> >
> > _________________________________________________________________
> > Send and receive Hotmail on your mobile device: http://mobile.msn.com
><< sudheer.vcf >>

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

Delivery-date: Thu, 20 Dec 2001 10:44:27 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: Re: Fwd: Comments on GMPLS signalling drafts
Date: Thu, 20 Dec 2001 11:37:28 -0700

Hi Sudheer,
            I fully agree with you. My concern was to list down the
GMPLS  features which are completely/fully specified by IETF and are
agreed upon by the IETF community and there is no further conflict for these 
in the industry.
Furthermore, these drafts should also list down the features (in GMPLS
functional Specification draft) which are under discussion/study and
the consensus is yet to be reached. The inclusion of these is very
important and going to help the implementors of GMPLS before moving
forward for RFC status.

Regards,
manoj.

>From: Sudheer Dharanikota <[email-masked]>
>To: manoj juneja <[email-masked]>
>CC: [email-masked], [email-masked], 
>[email-masked],        [email-masked]
>Subject: Re: Fwd: Comments on GMPLS signalling drafts
>Date: Wed, 19 Dec 2001 17:59:49 -0800
>
>Hi Manoj:
>
>You are asking for improvising GMPLS documents on bandwidth modification,
>which is still in infacy stage at ITU. We should draw line some where,
>as to which features will go into first version of the GMPLS standard.
>
>- sudheer
>
>
>manoj juneja wrote:
>
> > Hi Dimitri,
> >                My main concern was that if some topic is still being
> > discussed (like waveband and bandwidth modification for TDM LSPs), it
> > should be mentioned in the drafts that these sections are still not
> > complete and are under discussions/further study. To a reader of the
> > GMPLS drafts it should be clear that what all features are fully
> > specified by the IETF and there is no further conflict in the industry.
> > I still feel that there should be some reference for the bandwidth
> > modification for all the technologies (SDH/SONET, LSC and FSC) in the
> > drafrs.
> >
> > After reading the drafts one can question that :
> >
> > a) Can I increase the bandwidth of a TDM/FSC/LSC LSP ? If yes then
> > how ? Even one can question that is it under the scope of GMPLS ?
> >
> > These comments are just for completeness of the drafts before proceeding 
>to
> > the RFC status.
> >
> > Regards,
> > manoj.
> >
> > >From: Dimitri Papadimitriou <[email-masked]>
> > >To: manoj juneja <[email-masked]>
> > >CC: [email-masked], [email-masked], [email-masked]
> > >Subject: Re: Fwd: Comments on GMPLS signalling drafts
> > >Date: Wed, 19 Dec 2001 18:35:55 +0100
> > >
> > >Manoj,
> > >
> > >On the following "bandwidth modification" and "waveband switching":
> > >
> > >The first one is an ongoing topic discussed for instance in
> > 
> >http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
> > >that will be reviewed and updated for the next upcoming meetings
> > >
> > >On "waveband switching" the question is do we consider something
> > >further than what's already included in the version -07.txt. We
> > >have provided for this purpose some ideas in:
> > 
> >http://www.ietf.org/internet-drafts/draft-douville-ccamp-gmpls-waveband-extensions-00.txt
> > >
> > >CCAMP (and IETF) community should tell us if it is worth going on
> > >with the latter topic. If there is any interest, etc. But anyhow
> > >this is for further discussion (i.e. not within the scope of the
> > >current last call). It is now greatly time to move on (as said by
> > >Lou)...
> > >
> > >Regards,
> > >- dimitri.
> > >
> > >manoj juneja wrote:
> > > >
> > > > Hi Lou/Eric/Dimitri,
> > > >
> > > >   Please see the following para from gmpls-architecture draft :
> > > >
> > > >    "LSP modification consists in changing some LSP parameters, but
> > > >    normally without changing the route. It is supported using the
> > > >    same mechanism as re-routing. However, the semantic of LSP
> > > >    modification will differ from one technology to the other. For
> > > >    instance, further studies are required to understand the impact
> > > >    of dynamically changing some SDH/SONET circuit characteristics 
>such
> > > >    as the bandwidth, the protection type, the transparency, the
> > > >    concatenation etc."
> > > >
> > > > If u say that SE style of reservation is supported then how are u 
>going
> > >to
> > > > share the bandwidth of SDH/SONET, Lambda or Fiber LSPs ? How can one
> > >assign
> > > > diferent labels (labels are the physical resources on the link) to
> > >different
> > > > senders that belong to the same RSVP session. Is it  that the SE 
>style
> > >of
> > > > reservation only supported to modify the bandwidth of LSP ? Can I 
>modify
> > >the
> > > > bandwidth of LSC/FSC LSP ? If yes then how ?
> > > >
> > > > Do u people think that waveband section is compelte in the drafts ?
> > > >
> > > > Please see other comments inline.
> > > >
> > > > Regards,
> > > > manoj.
> > > >
> > > > >From: Lou Berger <[email-masked]>
> > > > >To: "manoj juneja" <[email-masked]>
> > > > >CC: <[email-masked]>,<[email-masked]>,
> > > > ><[email-masked]>
> > > > >Subject: Re: Fwd: Comments on GMPLS signalling drafts
> > > > >Date: Fri, 14 Dec 2001 15:18:34 -0500
> > > > >
> > > > >see comments inline.
> > > > >
> > > > >At 09:10 PM 12/13/2001, manoj juneja wrote:
> > > > >
> > > > >
> > > > >
> > > > >> >From: "manoj juneja" <[email-masked]>
> > > > >> >To: [email-masked]
> > > > >> >Subject: Comments on GMPLS signalling drafts
> > > > >> >Date: Tue, 11 Dec 2001 16:15:10 -0700
> > > > >> >
> > > > >> >Hi All,
> > > > >> >
> > > > >> >1. SE-style supported by GMPLS or not ?
> > > > >> >
> > > > >
> > > > >GMPLS doesn't modify this.  See the appropriate base protocol docs.
> > > > >
> > > > >>As labels are the resources on the link, one can't allocate 
>different
> > > > >> >label to different senders in the same RSVP session.
> > > > >> >
> > > > >
> > > > >I don't think you fully understand SE.  I suggest you read the base
> > > > >documents. (2205 and RSVP-TE)
> > > > >
> > > > >>
> > > > >> >2. Bandwidth modification for TDM, LSC and FSC LSPs. There is a
> > > > >> >separate draft for TDM LSP bandwidth modification but what about 
>the
> > > > >> >bandwidth modification for other types of LSPs ? There is no 
>mention
> > >of
> > > > >> >these in any of the GMPLS drafts.
> > > > >> >
> > > > >
> > > > >GMPLS doesn't modify this.  See the appropriate base protocol docs.
> > > > >
> > > > >>
> > > > >> >3. It should be mentioned clearly that waveband section is still 
>not
> > > > >> >complete in the drafts.
> > > > >> >
> > > >
> > > > >> >4. For IF_ID_RSVP_HOP object, there are couple of TLVs defined. 
>What
> > > > >> >about the Component_If_Id_Downstream/Upstream TLV ? The revised
> > > > >> >bundling draft has removed these 2 TLVs. What about the GMPLS
> > >signalling
> > > > >> >drafts ?
> > > > >> >
> > > > >
> > > > >It's still in, see the drafts for explanations.
> > > > >
> > > > [Manoj]: What I want to say is that Component_If_Id_Downstream and
> > >Upstream
> > > > TLVs of IF_ID_RSVP_HOP object have been removed from the bundling 
>draft.
> > >Do
> > > > u still want to keep these TLVs in GMPLS drafts ? If yes then is 
>there
> > >any
> > > > reason for keeping these ?
> > > >
> > > > >> >5. STM-0 label representation using {SUKLM} should be mentioned 
>in
> > >the
> > > > >> >drafts (because it is a special case).
> > > > >> >
> > > > >
> > > > >the sonet draft is the right place for this.  I defer to Eric on 
>this.
> > > > >
> > > > [Manoj]: Thanks for putting this info in the new version of the 
>draft.
> > > > >>
> > > > >> >6. It should be mentioned that bandwidth encoding parameter is
> > >useful
> > > > >> >for what all type of LSPs i.e. TDM, LSC, FSC, PSC etc.
> > > > >> >
> > > > [Manoj]: I think u should include what all technologies will make 
>use of
> > > > this parameter.
> > > >
> > > > >> >7. There is an example scenario for contention resolution in 
>case of
> > >bi-
> > > > >> >directional LSPs. It should be mentioned that  :
> > > > >> >
> > > > >> >"contention resolution is an optimization, not a correctness 
>issue
> > >...
> > > > >> >and no procedure can provide optimal resolution in all cases. An
> > > > >> >implementor
> > > > >> >may do differently to provide better resolution."
> > > > >> >
> > > > >> >The above quotes are extracted from one of the mails from Fong 
>Liaw.
> > > > >> >
> > > > >> >If this is the case then this should be mentioned in the drafts.
> > > > >> >
> > > > >
> > > > >Read the Acknowledgments section of the draft.  (I'm sure Fong will 
>be
> > > > >happy to see you protecting her interests!)
> > > > >
> > > > >>
> > > > >> >8. The LSP hierarchy concept is still not clear. Some days back 
>I
> > >posted
> > > > >> >one
> > > > >> >doubt related to tunneling of TDM LSP over Lambda LSP using the
> > >concept
> > > > >>of
> > > > >> >forwarding adjacency and different people replied with different
> > > > >>thoughts.
> > > > >> >Does this mean this concept is not standardized in GMPLS ?
> > > > >> >My question was :
> > > > >> >
> > > > >> >"If there are 4 nodes say A, B, C and D. There is a Lambda FA
> > > > >> >established from A to D and if a new TDM LSP request comes to 
>node A
> > > > >> >which is to be tunneled through the already established lambda
> > >FA-LSP
> > > > >> >then the node A sends the Path/label request message directly to
> > >node
> > > > >> >D. What label the node D will send back to node A in the 
>RESV/label
> > > > >> >mapping message since the FA-LSP is just one label (lambda) ? 
>Does
> > >it
> > > > >> >mean that all the LSPs which are tunneled through the lambda 
>FA-LSP
> > > > >> >will be allocated the same label by node D to node A ? If this 
>type
> > >of
> > > > >> >scenario can't exist in GMPLS then please let me know that too."
> > > > >
> > > > >I believe this topic is being covered in other threads.
> > > > >
> > > > >> >
> > > > >> >
> > > > >> >Regards,
> > > > >> >manoj.
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> 
> >_________________________________________________________________
> > > > >> >Join the world s largest e-mail service with MSN Hotmail.
> > > > >> ><http://www.hotmail.com>http://www.hotmail.com
> > > > >> >
> > > > >> >
> > > > >>
> > > > >>_________________________________________________________________
> > > > >>Get your FREE download of MSN Explorer at
> > > > 
> >><http://explorer.msn.com/intl.asp>http://explorer.msn.com/intl.asp.
> > > > >
> > > > >
> > > >
> > > > _________________________________________________________________
> > > > Join the world’s largest e-mail service with MSN Hotmail.
> > > > http://www.hotmail.com
> > ><< dimitri.papadimitriou.vcf >>
> >
> > _________________________________________________________________
> > Send and receive Hotmail on your mobile device: http://mobile.msn.com
><< sudheer.vcf >>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

Delivery-date: Thu, 20 Dec 2001 09:09:17 -0800
Subject: RE: GMPLS signaling documents updated per last calls
Date: Thu, 20 Dec 2001 12:00:48 -0500
content-class: urn:content-classes:message
From: "Brungard, Deborah A, ALCTA" <[email-masked]>
To: "Dimitri Papadimitriou" <[email-masked]>, "Maarten Vissers" <[email-masked]>
Cc: "Mannie, Eric" <[email-masked]>, <[email-masked]>, "Stephen Trowbridge" <[email-masked]>, "Kireeti Kompella" <[email-masked]>, <[email-masked]>, <[email-masked]>

I will be brief...

It was my understanding (from AT&T participants), there was agreement =
for ITU and IETF to work together. As this discussion is clearly on =
ITU/T1X1 standards and it is questioning individuals' interpretations of =
those standards, the discussion should go (liaison) to ITU. And as =
T1X1.5's chair, if questions on our standards, please liaison.

Quick response on items addressed to my comments:

- I have commented since last summer that sonet was a subset of sdh =
(ITU-T G.707). And several months ago, when the VT3 was cited as =
preventing the merging of the labels, I commented over the exploder, =
that the VT3 had never been defined. Yes, Juergen, it can be deleted =
from T1.105 - T1X1.5 is contribution based - it never was viewed as any =
priority for clean-up;-)

- 10 years ago, there was interest in having local standards. For the =
last several years, this environment has changed among participants in =
T1X1/ETSI/ITU. ANSI T1.105 was updated to reflect ITU-T terminology. It =
maintains the SONET terminology for legacy equipment/people. In T1X1, =
for the Optical Networking standards, we have chosen to use ITU-T =
terminology. Important note - for T1/ITU - it is terminology - the =
functionality is the same. Whereas, the use of differing GMPLS labels, =
will impact implementations (and require gateways). IF the majority of =
IETF/OIF want to maintain local implementations, than as in any =
democratic forum, the majority's view holds (on the OIF documents, AT&T =
made the same comment: use ITU-T terminology).

- yes, we do have ANSI, ETSI, and ITU standards. It is based on =
governments - not technical. As I said above, all efforts are to align =
(no differences for LCAS). As for GR253, I do not know what is defined. =
It is maintained by a private company. It is not an official standards =
body. If your company funds the work/buys the product, your company can =
reference it. If your comment is saying to reference the GR in the IETF =
standard, you may want to check on copyrights. I view it similar to =
buying a reference book on SONET. And I do not accept everything in a =
book unconditionally;-)

I do not see this discussion as useful for resolving the label =
disagreements. If the IETF editors have final interpretation - than =
that's the decision. Otherwise liaison the appropriate groups.

Deborah

> -----Original Message-----
> From:	Dimitri Papadimitriou [SMTP:[email-masked]]
> Sent:	Wednesday, December 19, 2001 12:37 PM
> To:	Maarten Vissers
> Cc:	Mannie, Eric; [email-masked]'; 'Stephen Trowbridge'; =
Kireeti Kompella; [email-masked]; Brungard, Deborah A, ALCTA; =
[email-masked]
> Subject:	Re: GMPLS signaling documents updated per last calls
>=20
> This discussion is going into limbos because once a solution =20
> is provided and agreed by all parties, afterwards the elements=20
> having enabled to come up to this decision disappear... for
> instance, VT3 SPE now are not used anymore... were they used=20
> one week before and just stop now ?=20
>=20
> Mor generally, since it is not the job of the CCAMP community to=20
> verify if the content of ITU/T1X1 specifications are implemented=20
> in current networks it is for me irrelevant to state as done by=20
> Stephen that they are not used. How can i verify such assertion ?
>=20
> At the end of the day i have got the following impression ITU
> T1 people blind the differences they maintain in their own
> documents... Deborah/Stephen sorry but GR.253 specification has=20
> just been extended to LCAS capabilities so T1X1 and ITU maintains
> their own version (G.707 is also being extended)... in this=20
> context sorry but we are at a point where people maintains=20
> artificial discussions for reasons which are very difficult=20
> to understand ?=20
>=20
> Very interesting the following e-mail from Maarten, why do i=20
> have to keep two terms in order to translate the same entity>=20
> if Sonet is a subset of SDH ?=20
>=20
> Cheers,
> - dimitri.
>=20
> Maarten Vissers wrote:
> >=20
> > Eric,
> >=20
> > It is not the intention to leave the choice of LSP encoding type and =
SU label
> > structure to the vendor. This would give immediate interworking =
problems.
> >=20
> > VC-11/VT1.5, VC-12/VT-2, VC-2/VT-6, VC-3/STS-1, VC-4/STS-3c, =
VC-4-4c/STS-12c,
> > VC-4-16c/STS-48c, VC-4-64c/STS-192c and VC-4-256c/STS-768c must all =
have LSP
> > encoding type "SDH". Also STS-1/STM-0 upto STM-256/STS-768 must have =
the LSP
> > encoding type "SDH".
> >=20
> > VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, VC-4-16c/STS-48c, =
VC-4-64c/STS-192c
> > and VC-4-256c/STS-768c must all have the same SDH-based "SU" =
structure.
> >=20
> > Looking at the label text in section 3 of the sonet-sdh document, I =
find it very
> > confusing to read that SONET doesn't use the "U" field. As we =
indicated before
> > there is no STS type signal that isn't having an SDH equivalent; =
i.e. there are
> > no specific higher order SONET signals left. It is therefore much =
better to take
> > out the SONET text for the SU label part altogether. Otherwise we =
will get a lot
> > of confusion in the marketplace.
> >=20
> > Also the examples with STS-1 (examples 3 to 5 in secton 3) must use =
the label
> > with U in the range 2 to 4; the STS-1 is equivalent to the VC-3 in =
SDH and must
> > thus use the "SDH" SU format.
> >=20
> > -------
> >=20
> > All,
> >=20
> > With the clarification on VT-3 given by Deborah, I would request to =
consider a
> > further simplification of the GMPLS standard: delete the LSP =
encoding type
> > "SONET" and rename the LSP encoding type "SDH" into "SDH/SONET". =
Then there
> > would be no ambiguity left at all.
> >=20
> > Regards,
> >=20
> > Maarten
> >=20
> > "Mannie, Eric" wrote:
> > >
> > > Hi Jonathan,
> > >
> > > > Why SHOULD and not MUST?  This ambiguity is likely to create
> > > interoperability problems in the future...
> > >
> > > To leave to the manufacturer and to the user the right to decide =
if he/she
> > > wants to signal an LSP as either SDH or SONET. There is no =
interoperability
> > > problem at all since you use EITHER SDH OR SONET. If you decide to =
request
> > > an SDH signal with what do you want to have interoperability issue =
at this
> > > stage ? The sentence means indeed "one should better use SDH than =
SONET" !
> > > Once you decided, there is no issue.
> > >
> > > > I'm curious what sort of backward compatability is necessary, as =
a
> > > "standard" doesn't exist currently that this needs to be backward
> > > compatible with...
> > >
> > > Backward compatibility with the OIF UNI 1.0 Implementation =
Agreement, with
> > > the implementations that could not care of SDH, with =
implementations that
> > > still do a distinction between SONET and SDH for some reasons, =
with the
> > > implementations that could still use the VT3 (DS1C) (I don't have
> > > confirmation that nobody is using it today, and this is not the =
goal of this
> > > draft to state what is obsolete or not in SONET), etc.
> > >
> > > Anyway, there is no issue, the SONET label format is not used =
until SONET is
> > > explicitly requested as such. This is not a primary feature of the =
draft,
> > > but a *secondary feature*, for SONET lovers. Otherwise, SDH is =
used for
> > > everything, consequently you don't care of the SONET label, you =
skip it in
> > > the draft, you ignore it, you don't implement it and you just use =
a full SDH
> > > implementation.
> > >
> > > I think that the solution is quite simple: if the SONET signal is =
indeed an
> > > SDH signal, why do you bother with SONET ? Just ask for an SDH =
signal,
> > > that's all.
> > >
> > > By the way, since according to some folks SONET is just a subset =
of SDH, why
> > > do we care about SONET in these documents ? Why don't we simply =
remove all
> > > references to SONET ?
> > >
> > > Is there somebody on this mailing list that cares about SONET ? If =
yes, why
> > > ? Who is still manufacturing SONET boxes ? Why is that not called =
SDH ?>=20
> > >
> > > Kind regards,
> > >
> > > Eric
> > >
> > > -----Original Message-----
> > > From: Jonathan Sadler [mailto:[email-masked]]
> > > Sent: Tuesday, December 18, 2001 9:57 PM
> > > To: Mannie, Eric
> > > Cc: 'Stephen Trowbridge'; Kireeti Kompella; [email-masked];
> > > [email-masked]; [email-masked]
> > > Subject: Re: GMPLS signaling documents updated per last calls
> > >
> > > Eric -
> > >
> > > Comments inline...
> > >
> > > Jonathan Sadler
> > >
> > > "Mannie, Eric" wrote:
> > > > "A SONET signal which has an identical SDH signal SHOULD be =
requested
> > > using
> > > > the same traffic parameters as for the equivalent SDH signal, =
and will
> > > > consequently use the SDH label."
> > >
> > > Why SHOULD and not MUST?  This ambiguity is likely to create
> > > interoperability problems in the future...
> > >
> > > > We spend with Maarten a lot of time to write that sentence (not =
easy to
> > > > write).
> > > >
> > > > Maybe that it should be better written:
> > > >
> > > > "A SONET signal which has an identical SDH signal SHOULD be =
requested as
> > > an
> > > > SDH signal using the same traffic parameters as for the =
equivalent SDH
> > > > signal, and will consequently use the SDH label."
> > >
> > > Again, "SHOULD" needs to be replaced with "MUST"...
> > >
> > > > This doesn't mean that the SONET signal format disappear (simply =
not used
> > > in
> > > > that case), for backward compatibility we need to keep it.
> > >
> > > I'm curious what sort of backward compatability is necessary, as a
> > > "standard" doesn't exist currently that this needs to be backward
> > > compatible with...
> > >
> > > > Kind regards,
> > > >
> > > > Eric
> > > >
> > > > -----Original Message-----
> > > > From: Stephen Trowbridge [mailto:[email-masked]]
> > > > Sent: Tuesday, December 18, 2001 7:46 PM
> > > > To: Kireeti Kompella
> > > > Cc: [email-masked]; [email-masked]; [email-masked];
> > > > [email-masked]; [email-masked]
> > > > Subject: Re: GMPLS signaling documents updated per last calls
> > > >
> > > > Kireeti,
> > > > The one outlyer is VT3 (3 Megabits). VC-3 is an extremely =
popular
> > > > rate in both SONET and SDH. I exchanged an email with Deborah =
Brungard
> > > > (T1X1.5 chair) on this one and I take the liberty of sharing her =
response:
> > > >
> > > > Deborah Brungard wrote:
> > > > > The VT3 (3M) structure was defined - but no services =
(mappings) were
> > > ever
> > > > defined for it. So there are no services/equip
> > > > > with it. My take was if in the future it was ever defined =
(doubtful), we
> > > > would be adding it to g707 also. So then it
> > > > > would just be part of g707 too.
> > > >
> > > > So basically, there are no mappings or equipment functions for =
this rate,
> > > > and as far as we know no network equipment or networks =
supporting it.
> > > > Deborah suggests that if we were ever to define such mappings, =
that this
> > > > would be proposed for addition to G.707 and hence be part of =
SDH.
> > > >
> > > > I think our agreement had been to use the SDH label for all =
signals that
> > > > had the same multiplex structure in SONET and SDH. In Salt Lake =
City, we
> > > > thought
> > > > that this was everything except VT3. Given that VT3 seems not to =
be a
> > > "real"
> > > > signal at this point and will likely be added to SDH if it ever =
becomes
> > > > real, does our agreement then become that we use SDH labels for
> > > everything?
> > > >
> > > > Regards,
> > > > Steve
> > > >
> > > > Kireeti Kompella wrote:
> > > > >
> > > > > Hi Deborah,
> > > > >
> > > > > > I previously made the
> > > > > > comments to merge the (1) SDH and SONET values as one value
> > > > >
> > > > > There was a meeting among Steve Trowbridge, Maarten Vissers,
> > > > > Eric Mannie, Dimitri Papadimitriou, the CCAMP ADs and chairs =
on
> > > > > several issues, among them this one.  The upshot was that =
whenever
> > > > > possible, the SDH label should be used, with the encoding =
type>=20
> > > > > set to SDH (i.e., G.707); however, there are signals that have
> > > > > no SDH equivalent (if I remember right, VC-3 -- someone =
correct
> > > > > me!), so we will keep SONET labels and encoding types around
> > > > > for that case and for legacy equipment.
> > > > >
> > > > > The revised SONET/SDH document will contain the exact wording.
> > > > > I will also be sending a reply to the ITU communication =
stating
> > > > > the agreement we came to.
> > > > >
> > > > > Kireeti. << File: Card for Dimitri Papadimitriou >>=20

Delivery-date: Thu, 20 Dec 2001 06:49:22 -0800
Date: Thu, 20 Dec 2001 09:38:45 -0500
From: Gopal Kailad <[email-masked]>
To: Lou Berger <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Transport networks and draft-ietf-mpls-generalized-rsvp-te [ was Re: GMPLS signaling documents updated per last calls]

Lou Berger wrote:

> All,
>     As was discussed in this morning's SUB-IP session, the GMPLS 
> signaling documents have been updated to reflect comments received 
> during the extended last call.  If you believe an issue that you have 
> previously raised has not been addressed in the drafts, please send a 
> message to the list.  (We'll respond with either how the issue was 
> addressed or if it was missed.)
>
> Here's a summary of changes:
>
> draft-ietf-mpls-generalized-signaling-07.txt
> see http://www.labn.net/docs/diff-sig-06-07.txt for change bar version.
> o changes were primarily in the area of GPID values.
>     (Juergen has a couple of additions that we'll incorporate in next 
> rev.)
>
> draft-ietf-mpls-generalized-rsvp-te-06.txt
> see http://www.labn.net/docs/diff-rsvp-05-06.txt
> o Minor editorial changes and clarifications based on comments from list
>
> draft-ietf-mpls-generalized-cr-ldp-05.txt
> http://www.labn.net/docs/diff-ldp-04-05.txt
> o Brings cr-ldp functionally in line with rsvp-te
> o Revised Admin Status Usage (per comments and also removed potential 
> race condition)
> o Clarified text related to interface bundling (To be consistent with 
> updated bundling draft.)
> o Added IANA Considerations
> o Minor editorial changes and clarifications
>
> Lou
>
>
>
>
I had raised some questions on support for control plane
resiliency and sent the following message to the ccamp list
on 11/2.  I believe these issues are still valid and are
not addressed in the latest version of the RSVP signaling
draft. If they have been addressed, I am interested in how
they are addressed. Since I am referring to draft-ietf-
ipo-carrier-requirements, I have copied the authors of
that draft too.

Thanks,

Gopal

-------- Original Message --------

Message-ID: <[email-masked]>
Date: Fri, 02 Nov 2001 14:23:13 -0500
From: Gopal Kailad <[email-masked]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) 
Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Transport networks and draft-ietf-mpls-generalized-rsvp-te-05
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

One characteristic of traditional transport networks is that
control plane failures do not affect established lightpaths or
TDM channels.  This is reflected by requirement 144 in
draft-ietf-ipo-carrier-requirements-00: "Control plane failures
shall not cause failure of established data plane connections."
Note that there is no time limit imposed on how long a control
plane failure can last without affecting established data plane
connections.

The Restart Time field in the Restart_Cap object supports a
maximum value of about 49 days.  In case of transport networks,
this would mean that in case of a controller failure due to say,
a natural disaster, if the node is not accessible, established
connections will fail after 49 days even if data plane is not
affected, which is unacceptable.

Even if this is fixed so that a node can advertise that the
restart time is infinite, there is another issue.  In existing
transport networks, established data plane connections do not
fail even if multiple controllers fail.  Accordingly, the
requirement from draft-ietf-ipo-carrier-requirements-00 quoted
above requires that there be no failure in the data plane in case
of "control plane failures."  This would effectively mean that
the recovery time could also be indeterminate. Consider the
following example with four nodes:

                      A ---- B ---- C ---- D

If B and C fail, and C restarts, it can not complete
synchronization with D until B restarts and exchanges state with
C.

I believe this level of resiliency is not possible with the
procedure specified.  Just advertising 0xffffffff for recovery
time will not be enough, as this could cause state to be held
indefinitely when it should be deleted.

So I suggest one of the following:

  - remove the restart section from the draft and consider it
    as a separate draft, so that the rest can move forward.

  - add a constraint in the beginning of section 9.5, after the
    first sentence:

    "The recovery mechanism specified in this section addresses
    restart issues only in case of PSC devices, and does not
    fulfil the requirements for transport networks.  Recovery
    procedures for transport networks is for further study."

  - postpone the last call, and look at adding a solution that
    would also satisfy the requirements of transport networks.

 From a transport network perspective, this could be a starting
point for discussion:

  - A new object called PERSISTENT_SESSION is introduced to
    indicate that a session is long lasting.  This will be sent
    in the Path message associated with transport network
    sessions.  This will be reflected back in the Resv message.
    The fact that a session is persistent is preserved along with
    forwarding plane information.

  - A new message (LRefresh) is introduced to synchronize the
    forwarding plane information for persistent sessions between
    peers, and it is transmitted periodically.

  - A new object called flags is added and this will be carried
    in Hello messages. This object has one field called flags,
    and a node supporting persistent sessions will set bit 0 of
    the Flags field.  Support for persistent sessions implies
    support for the PERSISTENT_SESSION object as well as
    LRefresh.

  - For sessions that are marked persistent, state will be
    cleared only under these conditions:

    - State will never be cleared based on timeout. Exceptions
      listed below.

    - State will be cleared based on timeout only after sending
      the Resv with the D bit set in the Admin_Status object
      upstream, and only if graceful deletion was initiated by
      the headend. This information will be preserved along with
      forwarding plane information.

    - Reception of PathTear.

    - If a node learns that it has some state in the forwarding
      plane that is not in sync with that of the peer, the
      forwarding plane state as well as associated control plane
      state will be cleared on a timer basis.  This timer will be
      more coarse-grained than the refresh timers for the control
      plane.

    - If a peer does not support persistent sessions, state that
      has to be refreshed by that peer will be timed out in the
      usual manner.  Restart procedure as specified for PSC
      devices may be used if the two nodes support it.

  - Specify clearly what help is needed from outside RSVP. To
    support recovery of hierarchical LSPs, RSVP needs the
    following information upon restart:

    - Mapping between interface id. assigned by the peer and the
      interface id. assigned locally.  (Related qn.: There was a
      suggestion on the list (from Yakov) that a node can learn
      this from the recovered link state database. But if the
      restart time is going to be indeterminate, isn't it
      possible that the TE-LSAs have expired when the node
      restarts?  If so, a node might instead preserve this
      information across restart.  But in any case, RSVP needs
      this information upon restart.)

    - Peers (LSR ids) with which Hello adjacencies were
      established dynamically as a result of FA-LSPs.

Comments?

Cheers,

Gopal

Delivery-date: Thu, 20 Dec 2001 04:57:29 -0800
From: Heiles Juergen <[email-masked]>
To: "'Dimitri Papadimitriou'" <[email-masked]>, Maarten Vissers <[email-masked]>
Cc: "Mannie, Eric" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: RE: GMPLS signaling documents updated per last calls
Date: Thu, 20 Dec 2001 13:42:13 +0100

Hi,

it didn't attend the come together at the IETF meeting, put it seems to me that the agreements where reached with different assumptions in the two parties minds.
I hear that the SONET labels was only left to support VT-3 and I hear that they are left for interworking with existing implementations (OIF UNI1.0). 

VT-3 is not a reason for me as
- VT-3 is not used in SONET (Deborah may be think about removing it from T1.105!)
- only a definition for the VT-3 label is needed, not for all other SONET signals. Furthermore it can be defined based on the SDH label.

Providing interworking with implementations that are based on draft documents is a little bit strange in my view. The implementers know that these documents are drafts and may change and so they have to change their implementation. Otherwise giving drafts a higher status contradicts all decision and voting processes for the final version as one can always reject changes based on existing implementations. However it seems that is the way the IETF works.
Ok, but in this case it should be clearly mentioned in the document. Furthermore the SONET definitions should be completely separated from the SDH definitions and but into a interworking part. Otherwise with the mixture of SONET and SDH within the text it is only confusing.

Concerning SDH/ITU and SONET/T1 I think it is more a political issue to have still the T1 recommendations with the full description. ETSI makes a reference to G.707 and only mentions which parts of G.707 apply or don't apply (ETS300147).

Regards

Juergen
> -----Original Message-----
> From: Dimitri Papadimitriou [mailto:[email-masked]]
> Sent: Wednesday, December 19, 2001 6:37 PM
> To: Maarten Vissers
> Cc: Mannie, Eric; [email-masked]'; 'Stephen Trowbridge';
> Kireeti Kompella; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: GMPLS signaling documents updated per last calls
> 
> 
> This discussion is going into limbos because once a solution  
> is provided and agreed by all parties, afterwards the elements 
> having enabled to come up to this decision disappear... for
> instance, VT3 SPE now are not used anymore... were they used 
> one week before and just stop now ? 
> 
> Mor generally, since it is not the job of the CCAMP community to 
> verify if the content of ITU/T1X1 specifications are implemented 
> in current networks it is for me irrelevant to state as done by 
> Stephen that they are not used. How can i verify such assertion ?
> 
> At the end of the day i have got the following impression ITU
> T1 people blind the differences they maintain in their own
> documents... Deborah/Stephen sorry but GR.253 specification has 
> just been extended to LCAS capabilities so T1X1 and ITU maintains
> their own version (G.707 is also being extended)... in this 
> context sorry but we are at a point where people maintains 
> artificial discussions for reasons which are very difficult 
> to understand ? 
> 
> Very interesting the following e-mail from Maarten, why do i 
> have to keep two terms in order to translate the same entity
> if Sonet is a subset of SDH ? 
> 
> Cheers,
> - dimitri.
> 
> Maarten Vissers wrote:
> > 
> > Eric,
> > 
> > It is not the intention to leave the choice of LSP encoding 
> type and SU label
> > structure to the vendor. This would give immediate 
> interworking problems.
> > 
> > VC-11/VT1.5, VC-12/VT-2, VC-2/VT-6, VC-3/STS-1, 
> VC-4/STS-3c, VC-4-4c/STS-12c,
> > VC-4-16c/STS-48c, VC-4-64c/STS-192c and VC-4-256c/STS-768c 
> must all have LSP
> > encoding type "SDH". Also STS-1/STM-0 upto STM-256/STS-768 
> must have the LSP
> > encoding type "SDH".
> > 
> > VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, VC-4-16c/STS-48c, 
> VC-4-64c/STS-192c
> > and VC-4-256c/STS-768c must all have the same SDH-based 
> "SU" structure.
> > 
> > Looking at the label text in section 3 of the sonet-sdh 
> document, I find it very
> > confusing to read that SONET doesn't use the "U" field. As 
> we indicated before
> > there is no STS type signal that isn't having an SDH 
> equivalent; i.e. there are
> > no specific higher order SONET signals left. It is 
> therefore much better to take
> > out the SONET text for the SU label part altogether. 
> Otherwise we will get a lot
> > of confusion in the marketplace.
> > 
> > Also the examples with STS-1 (examples 3 to 5 in secton 3) 
> must use the label
> > with U in the range 2 to 4; the STS-1 is equivalent to the 
> VC-3 in SDH and must
> > thus use the "SDH" SU format.
> > 
> > -------
> > 
> > All,
> > 
> > With the clarification on VT-3 given by Deborah, I would 
> request to consider a
> > further simplification of the GMPLS standard: delete the 
> LSP encoding type
> > "SONET" and rename the LSP encoding type "SDH" into 
> "SDH/SONET". Then there
> > would be no ambiguity left at all.
> > 
> > Regards,
> > 
> > Maarten
> > 
> > "Mannie, Eric" wrote:
> > >
> > > Hi Jonathan,
> > >
> > > > Why SHOULD and not MUST?  This ambiguity is likely to create
> > > interoperability problems in the future...
> > >
> > > To leave to the manufacturer and to the user the right to 
> decide if he/she
> > > wants to signal an LSP as either SDH or SONET. There is 
> no interoperability
> > > problem at all since you use EITHER SDH OR SONET. If you 
> decide to request
> > > an SDH signal with what do you want to have 
> interoperability issue at this
> > > stage ? The sentence means indeed "one should better use 
> SDH than SONET" !
> > > Once you decided, there is no issue.
> > >
> > > > I'm curious what sort of backward compatability is 
> necessary, as a
> > > "standard" doesn't exist currently that this needs to be backward
> > > compatible with...
> > >
> > > Backward compatibility with the OIF UNI 1.0 
> Implementation Agreement, with
> > > the implementations that could not care of SDH, with 
> implementations that
> > > still do a distinction between SONET and SDH for some 
> reasons, with the
> > > implementations that could still use the VT3 (DS1C) (I don't have
> > > confirmation that nobody is using it today, and this is 
> not the goal of this
> > > draft to state what is obsolete or not in SONET), etc.
> > >
> > > Anyway, there is no issue, the SONET label format is not 
> used until SONET is
> > > explicitly requested as such. This is not a primary 
> feature of the draft,
> > > but a *secondary feature*, for SONET lovers. Otherwise, 
> SDH is used for
> > > everything, consequently you don't care of the SONET 
> label, you skip it in
> > > the draft, you ignore it, you don't implement it and you 
> just use a full SDH
> > > implementation.
> > >
> > > I think that the solution is quite simple: if the SONET 
> signal is indeed an
> > > SDH signal, why do you bother with SONET ? Just ask for 
> an SDH signal,
> > > that's all.
> > >
> > > By the way, since according to some folks SONET is just a 
> subset of SDH, why
> > > do we care about SONET in these documents ? Why don't we 
> simply remove all
> > > references to SONET ?
> > >
> > > Is there somebody on this mailing list that cares about 
> SONET ? If yes, why
> > > ? Who is still manufacturing SONET boxes ? Why is that 
> not called SDH ?
> > >
> > > Kind regards,
> > >
> > > Eric
> > >
> > > -----Original Message-----
> > > From: Jonathan Sadler [mailto:[email-masked]]
> > > Sent: Tuesday, December 18, 2001 9:57 PM
> > > To: Mannie, Eric
> > > Cc: 'Stephen Trowbridge'; Kireeti Kompella; [email-masked];
> > > [email-masked]; [email-masked]
> > > Subject: Re: GMPLS signaling documents updated per last calls
> > >
> > > Eric -
> > >
> > > Comments inline...
> > >
> > > Jonathan Sadler
> > >
> > > "Mannie, Eric" wrote:
> > > > "A SONET signal which has an identical SDH signal 
> SHOULD be requested
> > > using
> > > > the same traffic parameters as for the equivalent SDH 
> signal, and will
> > > > consequently use the SDH label."
> > >
> > > Why SHOULD and not MUST?  This ambiguity is likely to create
> > > interoperability problems in the future...
> > >
> > > > We spend with Maarten a lot of time to write that 
> sentence (not easy to
> > > > write).
> > > >
> > > > Maybe that it should be better written:
> > > >
> > > > "A SONET signal which has an identical SDH signal 
> SHOULD be requested as
> > > an
> > > > SDH signal using the same traffic parameters as for the 
> equivalent SDH
> > > > signal, and will consequently use the SDH label."
> > >
> > > Again, "SHOULD" needs to be replaced with "MUST"...
> > >
> > > > This doesn't mean that the SONET signal format 
> disappear (simply not used
> > > in
> > > > that case), for backward compatibility we need to keep it.
> > >
> > > I'm curious what sort of backward compatability is necessary, as a
> > > "standard" doesn't exist currently that this needs to be backward
> > > compatible with...
> > >
> > > > Kind regards,
> > > >
> > > > Eric
> > > >
> > > > -----Original Message-----
> > > > From: Stephen Trowbridge [mailto:[email-masked]]
> > > > Sent: Tuesday, December 18, 2001 7:46 PM
> > > > To: Kireeti Kompella
> > > > Cc: [email-masked]; [email-masked]; [email-masked];
> > > > [email-masked]; [email-masked]
> > > > Subject: Re: GMPLS signaling documents updated per last calls
> > > >
> > > > Kireeti,
> > > > The one outlyer is VT3 (3 Megabits). VC-3 is an 
> extremely popular
> > > > rate in both SONET and SDH. I exchanged an email with 
> Deborah Brungard
> > > > (T1X1.5 chair) on this one and I take the liberty of 
> sharing her response:
> > > >
> > > > Deborah Brungard wrote:
> > > > > The VT3 (3M) structure was defined - but no services 
> (mappings) were
> > > ever
> > > > defined for it. So there are no services/equip
> > > > > with it. My take was if in the future it was ever 
> defined (doubtful), we
> > > > would be adding it to g707 also. So then it
> > > > > would just be part of g707 too.
> > > >
> > > > So basically, there are no mappings or equipment 
> functions for this rate,
> > > > and as far as we know no network equipment or networks 
> supporting it.
> > > > Deborah suggests that if we were ever to define such 
> mappings, that this
> > > > would be proposed for addition to G.707 and hence be 
> part of SDH.
> > > >
> > > > I think our agreement had been to use the SDH label for 
> all signals that
> > > > had the same multiplex structure in SONET and SDH. In 
> Salt Lake City, we
> > > > thought
> > > > that this was everything except VT3. Given that VT3 
> seems not to be a
> > > "real"
> > > > signal at this point and will likely be added to SDH if 
> it ever becomes
> > > > real, does our agreement then become that we use SDH labels for
> > > everything?
> > > >
> > > > Regards,
> > > > Steve
> > > >
> > > > Kireeti Kompella wrote:
> > > > >
> > > > > Hi Deborah,
> > > > >
> > > > > > I previously made the
> > > > > > comments to merge the (1) SDH and SONET values as one value
> > > > >
> > > > > There was a meeting among Steve Trowbridge, Maarten Vissers,
> > > > > Eric Mannie, Dimitri Papadimitriou, the CCAMP ADs and 
> chairs on
> > > > > several issues, among them this one.  The upshot was 
> that whenever
> > > > > possible, the SDH label should be used, with the encoding type
> > > > > set to SDH (i.e., G.707); however, there are signals that have
> > > > > no SDH equivalent (if I remember right, VC-3 -- 
> someone correct
> > > > > me!), so we will keep SONET labels and encoding types around
> > > > > for that case and for legacy equipment.
> > > > >
> > > > > The revised SONET/SDH document will contain the exact wording.
> > > > > I will also be sending a reply to the ITU 
> communication stating
> > > > > the agreement we came to.
> > > > >
> > > > > Kireeti.
> 

Delivery-date: Thu, 20 Dec 2001 04:21:49 -0800
From: Heiles Juergen <[email-masked]>
To: "'Mannie, Eric'" <[email-masked]>, "[email-masked] '" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>
Subject: RE: Revised GMPLS SONET/SDH drafts
Date: Thu, 20 Dec 2001 13:08:02 +0100

Hi Eric,

a took me a while to detect the agreements related to the label in the updated text as the label section still defines SDH and SONET labels in full details without mentioning the SDH labels should be used also for SONET signals. This new sentence in the introduction is very likely to be forgotten/not noticed and in the end we might get even more confusion/interop problems.
AS you mentioned in one of the other e-mails that the SONET label is kept for interoperability issues with existing implementations (e.g. OIF UNI1.0) it would be better to explicitly mention this and have the whole SONET definitions separate.

At the end of the label section a new paragraph is added concerning transparent concatenated  STM-N signals. I assume this is a signal with signal type STM-N/STS-3*N, transparency flag set and NCC>1. This leads to two questions:
What is the SUKLM label for a transparent STM-N without concatenation explicitly requested (Do we need a SUKLM label at all)?
Why is the case of transparency + contiguous concatenation (actually a contradiction in it self) special from the general transparency case and has to be mentioned.

The STM-0 SUKLM definition (S=0) is different from the STS-1 definition (S=1), also both are the same signal. As the STM-0 definition was just introduced it could have been made the same as the existing STS-1 definition. 

Regards

Juergen

> -----Original Message-----
> From: Mannie, Eric [mailto:[email-masked]]
> Sent: Friday, December 14, 2001 1:00 AM
> To: [email-masked] '
> Cc: [email-masked] '
> Subject: Revised GMPLS SONET/SDH drafts
> 
> 
> 
> Dear All,
> 
> Please find attached the two GMPLS SDH/SONET drafts revised 
> according to the
> comments received during the last period of comments, and 
> during the Salt
> Lake City meeting:
> 
> - draft-ietf-ccamp-gmpls-sonet-sdh-03.txt
> - draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt
> 
> Please, send your comments to the mailing list AND to us.
> 
> Kind regards,
> 
> Eric and Dimitri
> 
> 

Delivery-date: Thu, 20 Dec 2001 02:19:43 -0800
From: Heiles Juergen <[email-masked]>
To: "'Mannie, Eric'" <[email-masked]>, Heiles Juergen <[email-masked]>, "''John Drake' '" <[email-masked]>, "'Maarten Vissers '" <[email-masked]>, "'manoj juneja '" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>
Subject: RE: Lambda LSP establishment
Date: Thu, 20 Dec 2001 11:03:36 +0100

Hi Eric,

thanks for the explanation below. I have some further questions for clarification and I also think an informational I-D would be helpful.

You said that from the routing point of view a link and an FA are two different things. There is a routing adjacency "over" a link but not over a FA.
I don't see the difference between a "physical link" and a FA as routing can use both to establish a connection.
Furthermore for the SDH case if a VC-12 connection is setup via an existing VC-4 connection the VC-4 connection is an FA according to my understanding. However if a VC-4 connection is setup over a STM-16, the STM-16 is not a FA, it is a link. Is this correct? From the VC-12 or VC-4 routing view point I don't see a difference between the FA or link. Furthermore the STM-16 connection itself could be transported via an OCh or ODUk in a WDM system. So it is not the physical interface of the equipment. Is it still a link and no FA as from the physical topology only WDM (OTM-n) interfaces are seen.

Now concerning the setup of a VC-12 over a STM-16. In this case you use the full SUKLM number. owever in order to make this connection a VC-4 or HO VC-3 connection has to be established prior to the VC-12 connection. Is this implicitly assumed? After the setup of the VC-12 this V-4 or HO VC-3 exists. Is it now seen as a FA?
Lets have a look on two examples:

(1) HO/LO(4/1)-DXC <---STM-16---> HO/LO(4/1)-DXC

(2) HO/LO(4/1)-DXC <---STM-16---> HO(4/4)-DXC <--- STM-16---> HO/LO(4/1)-DXC

In example 1 two 4/1 SDH cross-connects that support VC-12 and VC-4 switching are directly interconnected via a STM-16. In this case the VC-12 label could be defined in relation to the STM-16 interface with the full SUKLM set. In the second example the two 4/1 cross-connects are interconnected via a 4/4 cross-connect that supports only VC-4 switching. Do we need a VC-4 FA in this case between the two 4/1 cross-connects to setup the VC-12 connection?

Regards

Juergen

> -----Original Message-----
> From: Mannie, Eric [mailto:[email-masked]]
> Sent: Thursday, December 13, 2001 6:57 PM
> To: 'Heiles Juergen '; ''John Drake' '; 'Maarten Vissers '; 'manoj
> juneja '
> Cc: [email-masked] '
> Subject: RE: Lambda LSP establishment
> 
> 
> Hi All,
> 
> A few comments,
> 
> >In MPLS the FA establishes "virtual" layer networks. In 
> GMPLS the layer
> networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, 
> OCh, OMS, OTS). A
> FA basically corresponds to a real trail in a circuit 
> switched network.
> 
> Eric: ...and this trail is setup dynamically using GMPLS. That's the
> interest. One can think of SDH/SONET FAs as shortcuts or 
> express-routes.
> 
> >One special thing about the SDH label is, that it includes a 
> hierarchy as
> it identifies the lower order VC in a higher order VC in a 
> STM-N signal.
> Note that this is somehow in contradiction with a statement 
> in the GMPLS
> signaling document which says 
> 
> >"A Generalized Label only carries a single level of label, 
> i.e., it is 
>    non-hierarchical.  When multiple levels of label (LSPs 
> within LSPs) 
>    are required, each LSP must be established separately, see [MPLS- 
>    HIERARCHY]." 
> 
> No, hierarchy of labels is not hierarchy of layers. And even 
> one should have
> a common definition of what means a "layer". This text says 
> that we cannot
> have multiple embedded labels, e.g. one label containting a 
> label stack.
> This is a signaling stuff that doesn't imply anything on the transport
> plane.
> 
> Now, a label identifies ONE LSP at an interface. This LSP can 
> be HO or LO in
> SDH. The label can be fully specified or partially specified, 
> depending on
> the context where the LSP is established.
> 
> E.g. when an LSP is established over a FA, the highest part 
> of the LSP label
> is not relevant. When the FA LSP is established the lowest 
> part of the FA
> LSP label is not relevant.
> 
> If a low order LSP is established without any higher order 
> FA, the label is
> fully specified. As you said the link is indeed the "ultimate 
> FA" in that
> case. Except that from the routing point of view a link and 
> an FA are two
> different things. There is a routing adjacency "over" a link 
> but not over a
> FA.
> 
> The SDH/SONET label just includes what you need to include in 
> each scenario.
> 
> Moreover, the label MUST be interpreted according to the type 
> of interface
> for which it is used. It is possible to code two labels 
> having the same
> value but a complete different meaning. Labels are context 
> sensitive of
> course.
> 
> For instance, an LSP over an STM-0 interface or over a FA 
> will have the
> highest part set to zero, and could possibly have the same 
> lowest part. You
> cannot understand what means the label without knowning the 
> detail of the
> interface. In that case, the interface is either an STM-0 
> interface or a
> VC-3 FA. And of course that FA and STM-0 interface are two 
> different things,
> but from the LSP point of view, in both cases what it wants 
> is a VC-3 in
> which it can be multiplexed.
> 
> Hope this helps.
> 
> I start to wonder if we should have an informational draft describing
> different scenarios of SDH/SONET LSP establishment. That 
> could complement
> the SDH/SONET signaling drafts and the GMPLS architecture. 
> That could solve
> many terminology and modeling issues.
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Heiles Juergen
> To: 'John Drake'; Maarten Vissers; manoj juneja
> Cc: [email-masked]
> Sent: 12/13/01 11:15 AM
> Subject: RE: Lambda LSP establishment
> 
> Let me express my understanding of FAs in MPLS/GMPLS, please 
> correct me
> if I am wrong. I have also some questions related to the label
> generation and interactions between layer networks.
> 
> The label in MPLS is local to the link between two adjacent MPLS
> switches, it indicates a LSP in this link. This link is therefore the
> ultimate FA. An already established LSP between two MPLS 
> switches, which
> don't have to be adjacent, can be used to transport/tunnel other LSPs
> between this two nodes. This already established LSP 
> generates a virtual
> adjacency between the two nodes, the FA. As several LSPs can 
> use this FA
> it is also a kind of virtual multiplexing.
> If you compare it with a circuit switched network the FA is a server
> layer trail that provides transport (a link connection) for 
> one or more
> client layer signals.
> In MPLS the FA establishes "virtual" layer networks. In GMPLS 
> the layer
> networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, OCh, OMS,
> OTS). A FA basically corresponds to a real trail in a circuit switched
> network.
> In GMPLS the label is also local to the link between the two devices
> that perform the switching. For example for SDH the VC-N is identified
> by the STM-N link/port and the SUKLM number according to
> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt. The STM-N port is 
> identified by
> the interface ID (I am not sure on this) and SUKLM is the SDH 
> label that
> locates the VC within the STM-N.
> From just the SDH viewpoint the STM-N connection is the 
> ultimate server
> trail/FA. However the STM-N signal could be transported over a Optical
> Channel or G.709 ODU. The OCh or ODU can already start in the 
> equipment
> that performs the VC-N switching. So the STM-N signal is not the port,
> but the WDM signal is the port and the STM-N signal makes use of a OCh
> or ODU server layer trail. This server layer trail can be established
> via management or using GMPLS. 
> Can someone explain how a label for a VC-4 is generated in this case
> (pre-established OCh or ODU trail via management or setup 
> using GMPLS).
> This interaction between the different technologies/labels need in my
> view some further explanation.
> 
> One special thing about the SDH label is, that it includes a hierarchy
> as it identifies the lower order VC in a higher order VC in a STM-N
> signal. Note that this is somehow in contradiction with a statement in
> the GMPLS signaling document which says 
> "A Generalized Label only carries a single level of label, i.e., it is
>    non-hierarchical.  When multiple levels of label (LSPs within LSPs)
>    are required, each LSP must be established separately, see [MPLS-
>    HIERARCHY]."
> Following this statement each layer should have its own label
> independent of server layers.
> The combination of hierarchies in labels is based on technology (e.g.
> SDH, Sonet, G.709 ODU) but has in my view no real technical 
> reason. The
> SDH label for example fits to standard STM-N signals, but not 
> to sub-STM
> signals.
> For the SDH the full SUKLM number is used if a e.g. VC-12 is 
> located in
> relation to a STM-N interface. If it is located in relation to a VC-4
> (the VC-4 is in this case a FA) SUK are set to 0. For me it 
> is not clear
> in which case I use the first and in which case I use the 
> second case as
> a VC-4 trail is always needed for a VC-12 connection. This 
> VC-4 could be
> established using management or GMPLS. However it should have no
> influence on the label. 
> Some more information is needed in my view in this area.
> 
> 
> Juergen
>  
> 
> > -----Original Message-----
> > From: John Drake [mailto:[email-masked]]
> > Sent: Wednesday, December 12, 2001 6:54 AM
> > To: Maarten Vissers; manoj juneja
> > Cc: [email-masked]
> > Subject: RE: Lambda LSP establishment
> > 
> > 
> > fortunately, this is just your opinion
> > 
> > -----Original Message-----
> > From: Maarten Vissers [mailto:[email-masked]]
> > Sent: Tuesday, December 11, 2001 9:31 PM
> > To: manoj juneja
> > Cc: [email-masked]
> > Subject: Re: Lambda LSP establishment
> > 
> > 
> > Manoj,
> > 
> > Forget the FA stuff, it is not appropriate in circuit 
> > networks. It only
> > applies
> > to MPLS. We should remove it when it is used in relation with PDH,
> > SDH/SONET,
> > OTN and pre-OTN. The text in sdh-sonet draft should state 
> > that if there is a
> > LOVC link (IETF: link bundle/TE link) then the LOVC signals 
> > use a label with
> > "00KLM".
> > 
> > Regards,
> > 
> > Maarten
> > 
> > manoj juneja wrote:
> > > 
> > > Hi Marteen,
> > >             The concept of FA is mentioned for SDH/SONET in 
> > gmpls-sdh
> > > -sonet draft. It says that if u have a HOVC trail as a FA 
> > (advertized
> > > as a link) then u can allocate the lower level signals in 
> > it by making
> > > the higher bits of label as 0s (i.e. S and U}. This is fine 
> > for the same
> > > technology. What about the case where the TDM LSP has to 
> be tunneled
> > through
> > > the Lambda LSP ? What will be the form of label (i.e. 
> > {SUKLM} or lambda
> > > etc.) ?
> > > 
> > > Regards,
> > > manoj.
> > > 
> > > >From: Maarten Vissers <[email-masked]>
> > > >To: manoj juneja <[email-masked]>
> > > >CC: [email-masked]
> > > >Subject: Re: Lambda LSP establishment
> > > >Date: Tue, 11 Dec 2001 15:56:41 +0100
> > > >
> > > >Manoj,
> > > >
> > > >You refer to one wavelength to be available between A-E without
> > wavelength
> > > >conversion capability. This suggests that you operate at 
> > the OCh layer
> > > >network.
> > > >Then you specify the capacity of the 4 OCh link 
> > connections (A-B, B-C,
> > C-D,
> > > >D-E)
> > > >to be "C". Say that C is about 10 Gbit/s. You then assume 
> > that there is a
> > > >request for an OCh signal with capacity C/4 (e.g. 2.5 
> > Gbit/s) between C
> > and
> > > >E.
> > > >The result is that the OCh link connections C-D and D-E 
> > are transporting
> > > >the OCh
> > > >signal (of e.g. 2.5G). These OCh link connections are now 
> > in service and
> > > >not
> > > >longer available to an other OCh connection request. I.e. 
> > a request for
> > an
> > > >OCh
> > > >connection between A and E will be rejected.
> > > >
> > > >FAs are not applicable in the circuit layers. IF there is 
> > a trail in
> > server
> > > >layer X, then there is a link in its client layer Y. X and 
> > Y are thus
> > > >different
> > > >layer networks and signals.
> > > >
> > > >If C-E is a "FA", then in an OTN the C-E connection would 
> > be an OCh trail
> > > >supporting an ODUk (k=1 if OCh is 2G5) link with a single link
> > connection.
> > > >
> > > >Note a FA in MPLS creates essentially a MPLS sublayer 
> > network. Such is
> > not
> > > >possible in the SDH/SONET, OTN, PDH or ATM technologies.
> > > >
> > > >Regards,
> > > >
> > > >Maarten
> > > >
> > > >OCh link connections
> > > >
> > > >manoj juneja wrote:
> > > > >
> > > > > Hi All,
> > > > >         If I have 5 nodes A, B, C, D and E connected as 
> > shown. Assume
> > > > > that only one wavelength is available on the path A to E (no
> > wavelength
> > > > > conversion capability is there on the complete path). 
> > Let the capacity
> > > > > of the wavelength be C. Further assume a request arrives for
> > connection
> > > > > from node C to E for a line capacity of C/4. This 
> > request will be
> > > > > successful as we have available wavelength. Now If 
> > another request
> > > > > comes at node A to establish another connection from 
> > node A to node E
> > > > > via nodes {A,B,C,D,E} for a line capacity of C/4. 
> > Should this request
> > > > > be successful as we have already allocated the wavelength ?
> > > > >
> > > > > If the previous connection from C to E of capacity 
> C/4 had been
> > > > > advertised as a FA, in that case will the IInd 
> request succeed ?
> > > > >
> > > > > If the previous connection from C to E of capacity C/4 
> > had not been
> > > > > advertised as FA then what will be the fate of IInd 
> connection ?
> > > > >
> > > > >        A <--> B <---> C <----> D <---> <----> E
> > > > >
> > > > > Regards,
> > > > > manoj.
> > > > >
> > > > > 
> > _________________________________________________________________
> > > > > Get your FREE download of MSN Explorer at
> > > >http://explorer.msn.com/intl.asp
> > > ><< mvissers.vcf >>
> > > 
> > > _________________________________________________________________
> > > Send and receive Hotmail on your mobile device: 
> http://mobile.msn.com
> 

Delivery-date: Wed, 19 Dec 2001 18:13:41 -0800
Date: Wed, 19 Dec 2001 17:59:49 -0800
From: Sudheer Dharanikota <[email-masked]>
To: manoj juneja <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Fwd: Comments on GMPLS signalling drafts

This is a multi-part message in MIME format.
--------------C41D4996C586D52DAD4E08CC
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi Manoj:

You are asking for improvising GMPLS documents on bandwidth modification,
which is still in infacy stage at ITU. We should draw line some where,
as to which features will go into first version of the GMPLS standard.

- sudheer

manoj juneja wrote:

> Hi Dimitri,
>                My main concern was that if some topic is still being
> discussed (like waveband and bandwidth modification for TDM LSPs), it
> should be mentioned in the drafts that these sections are still not
> complete and are under discussions/further study. To a reader of the
> GMPLS drafts it should be clear that what all features are fully
> specified by the IETF and there is no further conflict in the industry.
> I still feel that there should be some reference for the bandwidth
> modification for all the technologies (SDH/SONET, LSC and FSC) in the
> drafrs.
>
> After reading the drafts one can question that :
>
> a) Can I increase the bandwidth of a TDM/FSC/LSC LSP ? If yes then
> how ? Even one can question that is it under the scope of GMPLS ?
>
> These comments are just for completeness of the drafts before proceeding to
> the RFC status.
>
> Regards,
> manoj.
>
> >From: Dimitri Papadimitriou <[email-masked]>
> >To: manoj juneja <[email-masked]>
> >CC: [email-masked], [email-masked], [email-masked]
> >Subject: Re: Fwd: Comments on GMPLS signalling drafts
> >Date: Wed, 19 Dec 2001 18:35:55 +0100
> >
> >Manoj,
> >
> >On the following "bandwidth modification" and "waveband switching":
> >
> >The first one is an ongoing topic discussed for instance in
> >http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
> >that will be reviewed and updated for the next upcoming meetings
> >
> >On "waveband switching" the question is do we consider something
> >further than what's already included in the version -07.txt. We
> >have provided for this purpose some ideas in:
> >http://www.ietf.org/internet-drafts/draft-douville-ccamp-gmpls-waveband-extensions-00.txt
> >
> >CCAMP (and IETF) community should tell us if it is worth going on
> >with the latter topic. If there is any interest, etc. But anyhow
> >this is for further discussion (i.e. not within the scope of the
> >current last call). It is now greatly time to move on (as said by
> >Lou)...
> >
> >Regards,
> >- dimitri.
> >
> >manoj juneja wrote:
> > >
> > > Hi Lou/Eric/Dimitri,
> > >
> > >   Please see the following para from gmpls-architecture draft :
> > >
> > >    "LSP modification consists in changing some LSP parameters, but
> > >    normally without changing the route. It is supported using the
> > >    same mechanism as re-routing. However, the semantic of LSP
> > >    modification will differ from one technology to the other. For
> > >    instance, further studies are required to understand the impact
> > >    of dynamically changing some SDH/SONET circuit characteristics such
> > >    as the bandwidth, the protection type, the transparency, the
> > >    concatenation etc."
> > >
> > > If u say that SE style of reservation is supported then how are u going
> >to
> > > share the bandwidth of SDH/SONET, Lambda or Fiber LSPs ? How can one
> >assign
> > > diferent labels (labels are the physical resources on the link) to
> >different
> > > senders that belong to the same RSVP session. Is it  that the SE style
> >of
> > > reservation only supported to modify the bandwidth of LSP ? Can I modify
> >the
> > > bandwidth of LSC/FSC LSP ? If yes then how ?
> > >
> > > Do u people think that waveband section is compelte in the drafts ?
> > >
> > > Please see other comments inline.
> > >
> > > Regards,
> > > manoj.
> > >
> > > >From: Lou Berger <[email-masked]>
> > > >To: "manoj juneja" <[email-masked]>
> > > >CC: <[email-masked]>,<[email-masked]>,
> > > ><[email-masked]>
> > > >Subject: Re: Fwd: Comments on GMPLS signalling drafts
> > > >Date: Fri, 14 Dec 2001 15:18:34 -0500
> > > >
> > > >see comments inline.
> > > >
> > > >At 09:10 PM 12/13/2001, manoj juneja wrote:
> > > >
> > > >
> > > >
> > > >> >From: "manoj juneja" <[email-masked]>
> > > >> >To: [email-masked]
> > > >> >Subject: Comments on GMPLS signalling drafts
> > > >> >Date: Tue, 11 Dec 2001 16:15:10 -0700
> > > >> >
> > > >> >Hi All,
> > > >> >
> > > >> >1. SE-style supported by GMPLS or not ?
> > > >> >
> > > >
> > > >GMPLS doesn't modify this.  See the appropriate base protocol docs.
> > > >
> > > >>As labels are the resources on the link, one can't allocate different
> > > >> >label to different senders in the same RSVP session.
> > > >> >
> > > >
> > > >I don't think you fully understand SE.  I suggest you read the base
> > > >documents. (2205 and RSVP-TE)
> > > >
> > > >>
> > > >> >2. Bandwidth modification for TDM, LSC and FSC LSPs. There is a
> > > >> >separate draft for TDM LSP bandwidth modification but what about the
> > > >> >bandwidth modification for other types of LSPs ? There is no mention
> >of
> > > >> >these in any of the GMPLS drafts.
> > > >> >
> > > >
> > > >GMPLS doesn't modify this.  See the appropriate base protocol docs.
> > > >
> > > >>
> > > >> >3. It should be mentioned clearly that waveband section is still not
> > > >> >complete in the drafts.
> > > >> >
> > >
> > > >> >4. For IF_ID_RSVP_HOP object, there are couple of TLVs defined. What
> > > >> >about the Component_If_Id_Downstream/Upstream TLV ? The revised
> > > >> >bundling draft has removed these 2 TLVs. What about the GMPLS
> >signalling
> > > >> >drafts ?
> > > >> >
> > > >
> > > >It's still in, see the drafts for explanations.
> > > >
> > > [Manoj]: What I want to say is that Component_If_Id_Downstream and
> >Upstream
> > > TLVs of IF_ID_RSVP_HOP object have been removed from the bundling draft.
> >Do
> > > u still want to keep these TLVs in GMPLS drafts ? If yes then is there
> >any
> > > reason for keeping these ?
> > >
> > > >> >5. STM-0 label representation using {SUKLM} should be mentioned in
> >the
> > > >> >drafts (because it is a special case).
> > > >> >
> > > >
> > > >the sonet draft is the right place for this.  I defer to Eric on this.
> > > >
> > > [Manoj]: Thanks for putting this info in the new version of the draft.
> > > >>
> > > >> >6. It should be mentioned that bandwidth encoding parameter is
> >useful
> > > >> >for what all type of LSPs i.e. TDM, LSC, FSC, PSC etc.
> > > >> >
> > > [Manoj]: I think u should include what all technologies will make use of
> > > this parameter.
> > >
> > > >> >7. There is an example scenario for contention resolution in case of
> >bi-
> > > >> >directional LSPs. It should be mentioned that  :
> > > >> >
> > > >> >"contention resolution is an optimization, not a correctness issue
> >...
> > > >> >and no procedure can provide optimal resolution in all cases. An
> > > >> >implementor
> > > >> >may do differently to provide better resolution."
> > > >> >
> > > >> >The above quotes are extracted from one of the mails from Fong Liaw.
> > > >> >
> > > >> >If this is the case then this should be mentioned in the drafts.
> > > >> >
> > > >
> > > >Read the Acknowledgments section of the draft.  (I'm sure Fong will be
> > > >happy to see you protecting her interests!)
> > > >
> > > >>
> > > >> >8. The LSP hierarchy concept is still not clear. Some days back I
> >posted
> > > >> >one
> > > >> >doubt related to tunneling of TDM LSP over Lambda LSP using the
> >concept
> > > >>of
> > > >> >forwarding adjacency and different people replied with different
> > > >>thoughts.
> > > >> >Does this mean this concept is not standardized in GMPLS ?
> > > >> >My question was :
> > > >> >
> > > >> >"If there are 4 nodes say A, B, C and D. There is a Lambda FA
> > > >> >established from A to D and if a new TDM LSP request comes to node A
> > > >> >which is to be tunneled through the already established lambda
> >FA-LSP
> > > >> >then the node A sends the Path/label request message directly to
> >node
> > > >> >D. What label the node D will send back to node A in the RESV/label
> > > >> >mapping message since the FA-LSP is just one label (lambda) ? Does
> >it
> > > >> >mean that all the LSPs which are tunneled through the lambda FA-LSP
> > > >> >will be allocated the same label by node D to node A ? If this type
> >of
> > > >> >scenario can't exist in GMPLS then please let me know that too."
> > > >
> > > >I believe this topic is being covered in other threads.
> > > >
> > > >> >
> > > >> >
> > > >> >Regards,
> > > >> >manoj.
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> >_________________________________________________________________
> > > >> >Join the world s largest e-mail service with MSN Hotmail.
> > > >> ><http://www.hotmail.com>http://www.hotmail.com
> > > >> >
> > > >> >
> > > >>
> > > >>_________________________________________________________________
> > > >>Get your FREE download of MSN Explorer at
> > > >><http://explorer.msn.com/intl.asp>http://explorer.msn.com/intl.asp.
> > > >
> > > >
> > >
> > > _________________________________________________________________
> > > Join the world’s largest e-mail service with MSN Hotmail.
> > > http://www.hotmail.com
> ><< dimitri.papadimitriou.vcf >>
>
> _________________________________________________________________
> Send and receive Hotmail on your mobile device: http://mobile.msn.com

--------------C41D4996C586D52DAD4E08CC
Content-Type: text/x-vcard; charset=us-ascii;
 name="sudheer.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Sudheer Dharanikota
Content-Disposition: attachment;
 filename="sudheer.vcf"

begin:vcard 
n:Dharanikota;Sudheer
tel;work:408-956-8000 x357
x-mozilla-html:FALSE
url:http://www.cs.odu.edu/~sudheer
org:Nayna Networks Inc.;CTO's office
version:2.1
email;internet:[email-masked]
title:Network Architect
adr;quoted-printable:;;481 Sycamore Drive=0D=0AMilpitas, CA 95035 USA;;;;
fn:Sudheer Dharanikota
end:vcard

--------------C41D4996C586D52DAD4E08CC--

Delivery-date: Wed, 19 Dec 2001 17:47:29 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Issue in Label Set Object structure
Date: Wed, 19 Dec 2001 18:37:35 -0700

Hi All,
        There seems to be some issue with the label set format. Can I
include the virtually concatenated SDH/SONET signal in the label set ?
If I want to have multiple subchannel elements in the label set
(basically a set of labels in the label set instead of range) then how
to determine that how many # of 4 byte octets comprise one virtual
concatenated signal ?
Or Is it that the subchannel element within the label set will also
include the object header for generalized label ?

Please let me know if I am missing something.
Regards,
manoj.

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

Delivery-date: Wed, 19 Dec 2001 17:40:37 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: Re: Fwd: Comments on GMPLS signalling drafts
Date: Wed, 19 Dec 2001 18:29:48 -0700

Hi Dimitri,
               My main concern was that if some topic is still being
discussed (like waveband and bandwidth modification for TDM LSPs), it
should be mentioned in the drafts that these sections are still not
complete and are under discussions/further study. To a reader of the
GMPLS drafts it should be clear that what all features are fully
specified by the IETF and there is no further conflict in the industry.
I still feel that there should be some reference for the bandwidth
modification for all the technologies (SDH/SONET, LSC and FSC) in the
drafrs.

After reading the drafts one can question that :

a) Can I increase the bandwidth of a TDM/FSC/LSC LSP ? If yes then
how ? Even one can question that is it under the scope of GMPLS ?

These comments are just for completeness of the drafts before proceeding to 
the RFC status.

Regards,
manoj.

>From: Dimitri Papadimitriou <[email-masked]>
>To: manoj juneja <[email-masked]>
>CC: [email-masked], [email-masked], [email-masked]
>Subject: Re: Fwd: Comments on GMPLS signalling drafts
>Date: Wed, 19 Dec 2001 18:35:55 +0100
>
>Manoj,
>
>On the following "bandwidth modification" and "waveband switching":
>
>The first one is an ongoing topic discussed for instance in
>http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
>that will be reviewed and updated for the next upcoming meetings
>
>On "waveband switching" the question is do we consider something
>further than what's already included in the version -07.txt. We
>have provided for this purpose some ideas in:
>http://www.ietf.org/internet-drafts/draft-douville-ccamp-gmpls-waveband-extensions-00.txt
>
>CCAMP (and IETF) community should tell us if it is worth going on
>with the latter topic. If there is any interest, etc. But anyhow
>this is for further discussion (i.e. not within the scope of the
>current last call). It is now greatly time to move on (as said by
>Lou)...
>
>Regards,
>- dimitri.
>
>manoj juneja wrote:
> >
> > Hi Lou/Eric/Dimitri,
> >
> >   Please see the following para from gmpls-architecture draft :
> >
> >    "LSP modification consists in changing some LSP parameters, but
> >    normally without changing the route. It is supported using the
> >    same mechanism as re-routing. However, the semantic of LSP
> >    modification will differ from one technology to the other. For
> >    instance, further studies are required to understand the impact
> >    of dynamically changing some SDH/SONET circuit characteristics such
> >    as the bandwidth, the protection type, the transparency, the
> >    concatenation etc."
> >
> > If u say that SE style of reservation is supported then how are u going 
>to
> > share the bandwidth of SDH/SONET, Lambda or Fiber LSPs ? How can one 
>assign
> > diferent labels (labels are the physical resources on the link) to 
>different
> > senders that belong to the same RSVP session. Is it  that the SE style 
>of
> > reservation only supported to modify the bandwidth of LSP ? Can I modify 
>the
> > bandwidth of LSC/FSC LSP ? If yes then how ?
> >
> > Do u people think that waveband section is compelte in the drafts ?
> >
> > Please see other comments inline.
> >
> > Regards,
> > manoj.
> >
> > >From: Lou Berger <[email-masked]>
> > >To: "manoj juneja" <[email-masked]>
> > >CC: <[email-masked]>,<[email-masked]>,
> > ><[email-masked]>
> > >Subject: Re: Fwd: Comments on GMPLS signalling drafts
> > >Date: Fri, 14 Dec 2001 15:18:34 -0500
> > >
> > >see comments inline.
> > >
> > >At 09:10 PM 12/13/2001, manoj juneja wrote:
> > >
> > >
> > >
> > >> >From: "manoj juneja" <[email-masked]>
> > >> >To: [email-masked]
> > >> >Subject: Comments on GMPLS signalling drafts
> > >> >Date: Tue, 11 Dec 2001 16:15:10 -0700
> > >> >
> > >> >Hi All,
> > >> >
> > >> >1. SE-style supported by GMPLS or not ?
> > >> >
> > >
> > >GMPLS doesn't modify this.  See the appropriate base protocol docs.
> > >
> > >>As labels are the resources on the link, one can't allocate different
> > >> >label to different senders in the same RSVP session.
> > >> >
> > >
> > >I don't think you fully understand SE.  I suggest you read the base
> > >documents. (2205 and RSVP-TE)
> > >
> > >>
> > >> >2. Bandwidth modification for TDM, LSC and FSC LSPs. There is a
> > >> >separate draft for TDM LSP bandwidth modification but what about the
> > >> >bandwidth modification for other types of LSPs ? There is no mention 
>of
> > >> >these in any of the GMPLS drafts.
> > >> >
> > >
> > >GMPLS doesn't modify this.  See the appropriate base protocol docs.
> > >
> > >>
> > >> >3. It should be mentioned clearly that waveband section is still not
> > >> >complete in the drafts.
> > >> >
> >
> > >> >4. For IF_ID_RSVP_HOP object, there are couple of TLVs defined. What
> > >> >about the Component_If_Id_Downstream/Upstream TLV ? The revised
> > >> >bundling draft has removed these 2 TLVs. What about the GMPLS 
>signalling
> > >> >drafts ?
> > >> >
> > >
> > >It's still in, see the drafts for explanations.
> > >
> > [Manoj]: What I want to say is that Component_If_Id_Downstream and 
>Upstream
> > TLVs of IF_ID_RSVP_HOP object have been removed from the bundling draft. 
>Do
> > u still want to keep these TLVs in GMPLS drafts ? If yes then is there 
>any
> > reason for keeping these ?
> >
> > >> >5. STM-0 label representation using {SUKLM} should be mentioned in 
>the
> > >> >drafts (because it is a special case).
> > >> >
> > >
> > >the sonet draft is the right place for this.  I defer to Eric on this.
> > >
> > [Manoj]: Thanks for putting this info in the new version of the draft.
> > >>
> > >> >6. It should be mentioned that bandwidth encoding parameter is 
>useful
> > >> >for what all type of LSPs i.e. TDM, LSC, FSC, PSC etc.
> > >> >
> > [Manoj]: I think u should include what all technologies will make use of
> > this parameter.
> >
> > >> >7. There is an example scenario for contention resolution in case of 
>bi-
> > >> >directional LSPs. It should be mentioned that  :
> > >> >
> > >> >"contention resolution is an optimization, not a correctness issue 
>...
> > >> >and no procedure can provide optimal resolution in all cases. An
> > >> >implementor
> > >> >may do differently to provide better resolution."
> > >> >
> > >> >The above quotes are extracted from one of the mails from Fong Liaw.
> > >> >
> > >> >If this is the case then this should be mentioned in the drafts.
> > >> >
> > >
> > >Read the Acknowledgments section of the draft.  (I'm sure Fong will be
> > >happy to see you protecting her interests!)
> > >
> > >>
> > >> >8. The LSP hierarchy concept is still not clear. Some days back I 
>posted
> > >> >one
> > >> >doubt related to tunneling of TDM LSP over Lambda LSP using the 
>concept
> > >>of
> > >> >forwarding adjacency and different people replied with different
> > >>thoughts.
> > >> >Does this mean this concept is not standardized in GMPLS ?
> > >> >My question was :
> > >> >
> > >> >"If there are 4 nodes say A, B, C and D. There is a Lambda FA
> > >> >established from A to D and if a new TDM LSP request comes to node A
> > >> >which is to be tunneled through the already established lambda 
>FA-LSP
> > >> >then the node A sends the Path/label request message directly to 
>node
> > >> >D. What label the node D will send back to node A in the RESV/label
> > >> >mapping message since the FA-LSP is just one label (lambda) ? Does 
>it
> > >> >mean that all the LSPs which are tunneled through the lambda FA-LSP
> > >> >will be allocated the same label by node D to node A ? If this type 
>of
> > >> >scenario can't exist in GMPLS then please let me know that too."
> > >
> > >I believe this topic is being covered in other threads.
> > >
> > >> >
> > >> >
> > >> >Regards,
> > >> >manoj.
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >_________________________________________________________________
> > >> >Join the world s largest e-mail service with MSN Hotmail.
> > >> ><http://www.hotmail.com>http://www.hotmail.com
> > >> >
> > >> >
> > >>
> > >>_________________________________________________________________
> > >>Get your FREE download of MSN Explorer at
> > >><http://explorer.msn.com/intl.asp>http://explorer.msn.com/intl.asp.
> > >
> > >
> >
> > _________________________________________________________________
> > Join the world’s largest e-mail service with MSN Hotmail.
> > http://www.hotmail.com
><< dimitri.papadimitriou.vcf >>

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

Delivery-date: Wed, 19 Dec 2001 16:26:24 -0800
content-class: urn:content-classes:message
Subject: RE: Intra-area Crankback
Date: Wed, 19 Dec 2001 19:15:00 -0500
From: "Ash, Gerald R (Jerry), ALCTA" <[email-masked]>
To: "Don Fedyk" <[email-masked]>
Cc: "Ash, Gerald R (Jerry), ALCTA" <[email-masked]>, "Adrian Farrel" <[email-masked]>, "Atsushi Iwata" <[email-masked]>, "Norihito Fujita" <[email-masked]>, "Simon Marshall-Unitt" <[email-masked]>, "ccamp" <[email-masked]>

Don,

>The issue is that if people implement crank back only they don't=20
>get the benefit of feedback and therefore have only solved part=20
>of the problem. I agree that they can be independent. I think there=20
>is benefit to linking them.=20

Agreed that there is benefit in having both crankback and feedback in =
play.

>Also note that feedback does not alone imply that rerouting=20
>can be performed. A proper notify or failure reason must also=20
>be taken into account.=20

Agreed, this is what we were trying to point out in distinguishing =
crankback and feedback.=20

>From draft-iwata-mpls-crankback-02.txt=20
>  "In the feedback case [ASHW],=20
>   or in the current error sub-codes of the Notification message [CR-=20
>   LDP], one can infer a situation where rerouting can be done, but it=20
>   also can lead to other problems, which have been experienced in=20
>   practice, as illustrated below."=20
>This implies to me that the authors feel that feedback is somehow=20
>inferior to crankback.

Not at all.  We were trying to point out that crankback is a =
reroute-notify mechanism and if one emulates a 'crankback' (e.g., with a =
failure-notify), it is not a replacement for it.  We were not saying =
either feedback or crankback is superior or inferior, they do different =
things and both can provide needed functionality.  We have in fact =
pointed out the benefit of feedback in other drafts, e.g. =
http://www.ietf.org/internet-drafts/draft-ash-multi-area-te-reqmts-01.txt=
.  We'll revise the text in the next rev to remove any implied =
criticism, which was not intended.=20

Regards,
Jerry

Delivery-date: Wed, 19 Dec 2001 11:04:46 -0800
From: "Don Fedyk" <[email-masked]>
To: "Ash, Gerald R (Jerry), ALCTA" <[email-masked]>
Cc: "Ash, Gerald R (Jerry), ALCTA" <[email-masked]>, Adrian Farrel <[email-masked]>, Atsushi Iwata <[email-masked]>, Norihito Fujita <[email-masked]>, Simon Marshall-Unitt <[email-masked]>, ccamp <[email-masked]>
Subject: RE: Intra-area Crankback
Date: Wed, 19 Dec 2001 13:53:48 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C188BE.7E5D92F0
Content-Type: text/plain;
	charset="iso-8859-1"

Jerry 

The effect of feedback is to alleviate the race conditions 
that occur within a domain wrt updating the TE database. 
Crankback is the only form of information that can travel 
between domains since intimate topology knowledge is not useful. 
The issue is that if people implement crank back only they don't 
get the benefit of feedback and therefore have only solved part
of the problem. I agree that they can be independent. I think there
is benefit to linking them. Crankback within a domain does nothing
to alleviate the race conditions each LSP must learn the same 
lessons.  

I guess what frustrates me about this is we specifically 
saw feedback as have an advantage over crankback and having 
crankback specified as an alternative to feeback means the 
message didn't get through. For example out of your draft you 
point out drawbacks in feedback which I disagree do not exist. 
Also note that feedback does not alone imply that rerouting 
can be performed. A proper notify or failure reason must also 
be taken into account.

>From draft-iwata-mpls-crankback-02.txt
"
2. Explicit versus implicit rerouting indications

   There have been problems in service provider networks when
   "inferring" from indirect information that rerouting is allowed.  In
   the case of using an explicit rerouting indication, rerouting is
   explicitly authorized and not inferred.  In the feedback case [ASHW],
   or in the current error sub-codes of the Notification message [CR-
   LDP], one can infer a situation where rerouting can be done, but it
   also can lead to other problems, which have been experienced in
   practice, as illustrated below."

This implies to me that the authors feel that feedback is somehow 
inferior to crankback. No mechanism is perfect. There are always 
situations where under heavy load you don't make the best route 
decisions. I do however fail to see the extra information that 
feedback provides within a domain as being inferior to crankback.

Don

> -----Original Message-----
> From: Ash, Gerald R (Jerry), ALCTA [mailto:[email-masked]]
> Sent: Monday, December 17, 2001 12:17 PM
> To: Fedyk, Don [BL60:1A00:EXCH]
> Cc: Ash, Gerald R (Jerry), ALCTA; Adrian Farrel; Atsushi 
> Iwata; Norihito
> Fujita; Simon Marshall-Unitt; ccamp
> Subject: RE: Intra-area Crankback
> 
> 
> Hi Don,
> 
> don> The feedback draft is intended for this type of operation. 
> don> Feedback is best within the area crank back is best outside 
> don> the area. We discussed all of this with the original authors 
> don> many many times. 
> don> Crankback is a primitive from of feedback. 
> 
> I recall perhaps one or two 'hallway discussions' along this 
> line.  Personally I think that feedback and crankback do 
> different things, one is not a replacement for the other.  
> Feedback feeds information to the TED, crankback is a 
> reroute-notify to the head-end or border LSR.  One can 
> emulate a 'crankback' with a failure-notify, just as well as 
> interpreting a feedback TLV as a 'crankback'.  It is not the 
> same as crankback nor a replacement for it.
> 
> Both can provide needed functionality.
> 
> Regards,
> Jerry
> 

------_=_NextPart_001_01C188BE.7E5D92F0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: Intra-area Crankback</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Jerry </FONT>
</P>

<P><FONT SIZE=2>The effect of feedback is to alleviate the race conditions </FONT>
<BR><FONT SIZE=2>that occur within a domain wrt updating the TE database. </FONT>
<BR><FONT SIZE=2>Crankback is the only form of information that can travel </FONT>
<BR><FONT SIZE=2>between domains since intimate topology knowledge is not useful. </FONT>
<BR><FONT SIZE=2>The issue is that if people implement crank back only they don't </FONT>
<BR><FONT SIZE=2>get the benefit of feedback and therefore have only solved part</FONT>
<BR><FONT SIZE=2>of the problem. I agree that they can be independent. I think there</FONT>
<BR><FONT SIZE=2>is benefit to linking them. Crankback within a domain does nothing</FONT>
<BR><FONT SIZE=2>to alleviate the race conditions each LSP must learn the same </FONT>
<BR><FONT SIZE=2>lessons.&nbsp; </FONT>
</P>

<P><FONT SIZE=2>I guess what frustrates me about this is we specifically </FONT>
<BR><FONT SIZE=2>saw feedback as have an advantage over crankback and having </FONT>
<BR><FONT SIZE=2>crankback specified as an alternative to feeback means the </FONT>
<BR><FONT SIZE=2>message didn't get through. For example out of your draft you </FONT>
<BR><FONT SIZE=2>point out drawbacks in feedback which I disagree do not exist. </FONT>
<BR><FONT SIZE=2>Also note that feedback does not alone imply that rerouting </FONT>
<BR><FONT SIZE=2>can be performed. A proper notify or failure reason must also </FONT>
<BR><FONT SIZE=2>be taken into account.</FONT>
</P>

<P><FONT SIZE=2>From draft-iwata-mpls-crankback-02.txt</FONT>
<BR><FONT SIZE=2>&quot;</FONT>
<BR><FONT SIZE=2>2. Explicit versus implicit rerouting indications</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; There have been problems in service provider networks when</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; &quot;inferring&quot; from indirect information that rerouting is allowed.&nbsp; In</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; the case of using an explicit rerouting indication, rerouting is</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; explicitly authorized and not inferred.&nbsp; In the feedback case [ASHW],</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; or in the current error sub-codes of the Notification message [CR-</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; LDP], one can infer a situation where rerouting can be done, but it</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; also can lead to other problems, which have been experienced in</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; practice, as illustrated below.&quot;</FONT>
</P>

<P><FONT SIZE=2>This implies to me that the authors feel that feedback is somehow </FONT>
<BR><FONT SIZE=2>inferior to crankback. No mechanism is perfect. There are always </FONT>
<BR><FONT SIZE=2>situations where under heavy load you don't make the best route </FONT>
<BR><FONT SIZE=2>decisions. I do however fail to see the extra information that </FONT>
<BR><FONT SIZE=2>feedback provides within a domain as being inferior to crankback.</FONT>
</P>

<P><FONT SIZE=2>Don</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Ash, Gerald R (Jerry), ALCTA [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Monday, December 17, 2001 12:17 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Fedyk, Don [BL60:1A00:EXCH]</FONT>
<BR><FONT SIZE=2>&gt; Cc: Ash, Gerald R (Jerry), ALCTA; Adrian Farrel; Atsushi </FONT>
<BR><FONT SIZE=2>&gt; Iwata; Norihito</FONT>
<BR><FONT SIZE=2>&gt; Fujita; Simon Marshall-Unitt; ccamp</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: Intra-area Crankback</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi Don,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; don&gt; The feedback draft is intended for this type of operation. </FONT>
<BR><FONT SIZE=2>&gt; don&gt; Feedback is best within the area crank back is best outside </FONT>
<BR><FONT SIZE=2>&gt; don&gt; the area. We discussed all of this with the original authors </FONT>
<BR><FONT SIZE=2>&gt; don&gt; many many times. </FONT>
<BR><FONT SIZE=2>&gt; don&gt; Crankback is a primitive from of feedback. </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I recall perhaps one or two 'hallway discussions' along this </FONT>
<BR><FONT SIZE=2>&gt; line.&nbsp; Personally I think that feedback and crankback do </FONT>
<BR><FONT SIZE=2>&gt; different things, one is not a replacement for the other.&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; Feedback feeds information to the TED, crankback is a </FONT>
<BR><FONT SIZE=2>&gt; reroute-notify to the head-end or border LSR.&nbsp; One can </FONT>
<BR><FONT SIZE=2>&gt; emulate a 'crankback' with a failure-notify, just as well as </FONT>
<BR><FONT SIZE=2>&gt; interpreting a feedback TLV as a 'crankback'.&nbsp; It is not the </FONT>
<BR><FONT SIZE=2>&gt; same as crankback nor a replacement for it.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Both can provide needed functionality.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Regards,</FONT>
<BR><FONT SIZE=2>&gt; Jerry</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C188BE.7E5D92F0--

Delivery-date: Wed, 19 Dec 2001 10:10:11 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: protection and restoration [was: Re: Moving right along ... g eneralized-signaling-06]
Date: Wed, 19 Dec 2001 18:03:20 -0000

Hi Maarten,

Maarten Vissers wrote 19 December 2001 13:25
<snipped top/tail>
> One of the requirements we have to meet is that traffic of 
> user A is not
> delivered to user B. Also during recovery from a failed 
> connection (either by
> means of protection swithcing, or restoration) we have to 
> guarantee that user A
> traffic is not delivered to user B.
NH=> Can I ask, is there a general agreement on this principle in this
group?  It's something operators usually insist on, so I'd like to know if
its agreed here and the mechanism that ensures this.

thanks, Neil

Delivery-date: Wed, 19 Dec 2001 09:52:05 -0800
Date: Wed, 19 Dec 2001 18:35:55 +0100
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: manoj juneja <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Fwd: Comments on GMPLS signalling drafts

This is a multi-part message in MIME format.
--------------20F81BC6C531111832E03726
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Manoj,

On the following "bandwidth modification" and "waveband switching":

The first one is an ongoing topic discussed for instance in 
http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-00.txt 
that will be reviewed and updated for the next upcoming meetings

On "waveband switching" the question is do we consider something
further than what's already included in the version -07.txt. We 
have provided for this purpose some ideas in: 
http://www.ietf.org/internet-drafts/draft-douville-ccamp-gmpls-waveband-extensions-00.txt 
 
CCAMP (and IETF) community should tell us if it is worth going on 
with the latter topic. If there is any interest, etc. But anyhow 
this is for further discussion (i.e. not within the scope of the 
current last call). It is now greatly time to move on (as said by 
Lou)...  

Regards,
- dimitri.

manoj juneja wrote:
> 
> Hi Lou/Eric/Dimitri,
> 
>   Please see the following para from gmpls-architecture draft :
> 
>    "LSP modification consists in changing some LSP parameters, but
>    normally without changing the route. It is supported using the
>    same mechanism as re-routing. However, the semantic of LSP
>    modification will differ from one technology to the other. For
>    instance, further studies are required to understand the impact
>    of dynamically changing some SDH/SONET circuit characteristics such
>    as the bandwidth, the protection type, the transparency, the
>    concatenation etc."
> 
> If u say that SE style of reservation is supported then how are u going to
> share the bandwidth of SDH/SONET, Lambda or Fiber LSPs ? How can one assign
> diferent labels (labels are the physical resources on the link) to different
> senders that belong to the same RSVP session. Is it  that the SE style of
> reservation only supported to modify the bandwidth of LSP ? Can I modify the
> bandwidth of LSC/FSC LSP ? If yes then how ?
> 
> Do u people think that waveband section is compelte in the drafts ?
> 
> Please see other comments inline.
> 
> Regards,
> manoj.
> 
> >From: Lou Berger <[email-masked]>
> >To: "manoj juneja" <[email-masked]>
> >CC: <[email-masked]>,<[email-masked]>,
> ><[email-masked]>
> >Subject: Re: Fwd: Comments on GMPLS signalling drafts
> >Date: Fri, 14 Dec 2001 15:18:34 -0500
> >
> >see comments inline.
> >
> >At 09:10 PM 12/13/2001, manoj juneja wrote:
> >
> >
> >
> >> >From: "manoj juneja" <[email-masked]>
> >> >To: [email-masked]
> >> >Subject: Comments on GMPLS signalling drafts
> >> >Date: Tue, 11 Dec 2001 16:15:10 -0700
> >> >
> >> >Hi All,
> >> >
> >> >1. SE-style supported by GMPLS or not ?
> >> >
> >
> >GMPLS doesn't modify this.  See the appropriate base protocol docs.
> >
> >>As labels are the resources on the link, one can't allocate different
> >> >label to different senders in the same RSVP session.
> >> >
> >
> >I don't think you fully understand SE.  I suggest you read the base
> >documents. (2205 and RSVP-TE)
> >
> >>
> >> >2. Bandwidth modification for TDM, LSC and FSC LSPs. There is a
> >> >separate draft for TDM LSP bandwidth modification but what about the
> >> >bandwidth modification for other types of LSPs ? There is no mention of
> >> >these in any of the GMPLS drafts.
> >> >
> >
> >GMPLS doesn't modify this.  See the appropriate base protocol docs.
> >
> >>
> >> >3. It should be mentioned clearly that waveband section is still not
> >> >complete in the drafts.
> >> >
> 
> >> >4. For IF_ID_RSVP_HOP object, there are couple of TLVs defined. What
> >> >about the Component_If_Id_Downstream/Upstream TLV ? The revised
> >> >bundling draft has removed these 2 TLVs. What about the GMPLS signalling
> >> >drafts ?
> >> >
> >
> >It's still in, see the drafts for explanations.
> >
> [Manoj]: What I want to say is that Component_If_Id_Downstream and Upstream
> TLVs of IF_ID_RSVP_HOP object have been removed from the bundling draft. Do
> u still want to keep these TLVs in GMPLS drafts ? If yes then is there any
> reason for keeping these ?
> 
> >> >5. STM-0 label representation using {SUKLM} should be mentioned in the
> >> >drafts (because it is a special case).
> >> >
> >
> >the sonet draft is the right place for this.  I defer to Eric on this.
> >
> [Manoj]: Thanks for putting this info in the new version of the draft.
> >>
> >> >6. It should be mentioned that bandwidth encoding parameter is useful
> >> >for what all type of LSPs i.e. TDM, LSC, FSC, PSC etc.
> >> >
> [Manoj]: I think u should include what all technologies will make use of
> this parameter.
> 
> >> >7. There is an example scenario for contention resolution in case of bi-
> >> >directional LSPs. It should be mentioned that  :
> >> >
> >> >"contention resolution is an optimization, not a correctness issue ...
> >> >and no procedure can provide optimal resolution in all cases. An
> >> >implementor
> >> >may do differently to provide better resolution."
> >> >
> >> >The above quotes are extracted from one of the mails from Fong Liaw.
> >> >
> >> >If this is the case then this should be mentioned in the drafts.
> >> >
> >
> >Read the Acknowledgments section of the draft.  (I'm sure Fong will be
> >happy to see you protecting her interests!)
> >
> >>
> >> >8. The LSP hierarchy concept is still not clear. Some days back I posted
> >> >one
> >> >doubt related to tunneling of TDM LSP over Lambda LSP using the concept
> >>of
> >> >forwarding adjacency and different people replied with different
> >>thoughts.
> >> >Does this mean this concept is not standardized in GMPLS ?
> >> >My question was :
> >> >
> >> >"If there are 4 nodes say A, B, C and D. There is a Lambda FA
> >> >established from A to D and if a new TDM LSP request comes to node A
> >> >which is to be tunneled through the already established lambda FA-LSP
> >> >then the node A sends the Path/label request message directly to node
> >> >D. What label the node D will send back to node A in the RESV/label
> >> >mapping message since the FA-LSP is just one label (lambda) ? Does it
> >> >mean that all the LSPs which are tunneled through the lambda FA-LSP
> >> >will be allocated the same label by node D to node A ? If this type of
> >> >scenario can't exist in GMPLS then please let me know that too."
> >
> >I believe this topic is being covered in other threads.
> >
> >> >
> >> >
> >> >Regards,
> >> >manoj.
> >> >
> >> >
> >> >
> >> >
> >> >_________________________________________________________________
> >> >Join the world s largest e-mail service with MSN Hotmail.
> >> ><http://www.hotmail.com>http://www.hotmail.com
> >> >
> >> >
> >>
> >>_________________________________________________________________
> >>Get your FREE download of MSN Explorer at
> >><http://explorer.msn.com/intl.asp>http://explorer.msn.com/intl.asp.
> >
> >
> 
> _________________________________________________________________
> Join the world’s largest e-mail service with MSN Hotmail.
> http://www.hotmail.com
--------------20F81BC6C531111832E03726
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------20F81BC6C531111832E03726--

Delivery-date: Wed, 19 Dec 2001 09:51:56 -0800
Date: Wed, 19 Dec 2001 18:35:41 +0100
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: Maarten Vissers <[email-masked]>
CC: Markus Jork <[email-masked]>, Lou Berger <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... generalized-rsvp-te-05

This is a multi-part message in MIME format.
--------------30E4F400DC439DD6286C7FD3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Maarten

Switching Type has been defined to enable for instance the 
following case if i well understood the explanations given 
in the existing I-Ds:

            --- CF ---
           |          |
   link 1  |          | link 2
-----------            ---------

- link 1 supports TDM LSP Encoding Type
- link 2 supports TDM LSP Encoding Type

however at the end of 
- link 1: PSC or LSC Switching capability can be provided
- link 2: PSC or LSC Switching capability can be provided

Notice that a Lambda LSP does not have to be established before 
the setup of the packet LSP. Consequently this feature provides 
additional about the implementation the Connection Function (CF) 
into the switch. So i can understand why you have some problem 
to understand this concept since typically CF implementation are 
left unspecified. Typically what do you have in such circumstances 
is the following:
                            
       link1     - CF1 -     link3
                |       |
                |       |
       link2   -|- CF2 -|-   link4
              |           |
              |           | 
    ----------             ---------

where CF_1=PSC and CF_2=LSC

with link 1 and link 3 supporting "packet" LSP Encoding
and  link 2 and link 4 supporting "lambda" LSP Encoding

In all the examples that you have listed:
- either the switching type through the LSP EncType and Signal Type
- or only the LSP Encoding Type (in case of Ethernet for instance)
so in such cases the Switching Type provides a redundant information.

Hope this helps you to understand the underlying concept.

Cheers,
- dimitri.

Maarten Vissers wrote:
> 
> Markus, John, Lou, Manoj,
> 
> I also still have a major issue to understand the switching type... or more
> precise I have the feeling it is too coarse and ill defined. Let me provide some
> more examples to evaluate:
> 
> Frist Markus' network example... it will look like the following in reality
> 
>  R1 ------ OXC1 ------ OXC2 ------ R2
>      OC-N        OC-N        OC-N
> 
>               OC-N trail
>   |<------------------------------>|
> 
>              STS-Nc trail
>  |<-------------------------------->|
> 
>               IP Link
> |<---------------------------------->|
> 
> I assume that OXC1/2 are all optical cross connects which pass through the
> complete OC-N signals.
> 
> In order to route IP packets between R1 and R2, you need to set up an OC-N trail
> between R1 and R2. Once this is done, you need to set up a STS-Nc trail between
> R1 and R2. Once this is done you have an IP link with a bandwidth of 9 584 640
> kbit/s established between R1 and R2. Now IP signals can flow between R1 and R2.
> 
> Now make the example a bit more complex and let me add a SONET cross connect in
> the chain.
> 
>  R1 ------ OXC1 ------ OXC2 ------ DXC1 ------ R2
>      OC-N        OC-N        OC-N        OC-N
> 
>               OC-N trail              OC-N trail
>   |<------------------------------>|  |<------>|
> 
>                   STS-Nc trail
>  |<-------------------------------------------->|
> 
>                       IP Link
> |<---------------------------------------------->|
> 
> The physical interface in each case is an OC-N. The DXC1 is a SONET cross
> connect, which terminates the OC-N Section and Line layers and forwards the
> STS-Nc signal.
> 
> What would the switching types be in this case when an LSP is requested between
> R1 and R2?
> 
> Now assume that the transport network contains some OTN OXCs interconnected via
> 40G wavelengths. The Routers are having STM-16 physical interfaces with VC-4-16c
> path signal carrying IP traffic. The DXC1 is a SDH cross connect with an OTN
> OTM-0.3 (i.e. 40G) interface, which is carrying ODU1 (2G5) signals with STM-16
> inside.
> 
>  R1 -------- OXC1 ---------- OXC2 ---------- OXC3 --------- DXC1 -------- R2
>      STM-16        OTM-64.3        OTM-40.3        OTM-0.3        STM-16
> 
>                            OCh trail
>                 |<-------------------------->|
> 
>                               ODU3 trail
>                |<----------------------------------------->|
> 
>                                  ODU1 trail
>              |<-------------------------------------------->|
> 
>                           STM-16 trail                        STM-16 trail
>   |<-------------------------------------------------------->||<-------->|
> 
>                              VC-4-16c trail
>  |<---------------------------------------------------------------------->|
> 
>                                  IP Link
> |<------------------------------------------------------------------------>|
> 
> What would the switching types be in this case when an LSP is requested between
> R1 and R2?
> 
> But a router may also connect via a GE interface. The ethernet frames are then
> forwarded in OXC1 via a virtual concatenated VC-4-Xv to R2 (which has a STM-16
> interface supporting VC-4-Xv). As VC-4-Xv signals can only be carried in sTM-N
> signals, there is an STM-16 trail between OXC1 and DXC1. There is another STM-16
> trail between DXC1 and R2.
> The OXCs are part of an OTN network, so the STM-16 that is created in the OXC1
> is mapped into an ODU1 and this ODU1 is switched to an OTM-64.3 port. In this
> port the ODU1 signal is TDM multiplexed into an ODU3 and this ODU3 is put onto a
> wavelenght (via OTU3V and OCh). OXC2 is an OCh (all optical) switch, capable to
> forward the true wavelenght signal between the two OTM-64.3 and OTM-40.3 line
> ports. The OCh signal is terminated in the OTM-40.3 line port in OXC3 and the
> ODU3 is switched to the egress OTM-0.3 interface port. Arriving at DXC1, the
> ODu3 is terminated, the ODU1 is demultiplexed from the ODU3, the ODU1 is
> terminated and the STM-16 is extracted. Then the sTM-16 is terminated and the X
> VC-4 signals are switched to the egress STM-16 signal. At R2 the STM-16 signal
> is terminated, the X-VC-4 signals are connected to the VC-4-Xv port and
> terminated making the  ethernet frames available. The ehternet frames are
> terminated and the IP packets are now accessible.
> 
>  R1 ------ OXC1 ---------- OXC2 ---------- OXC3 --------- DXC1 -------- R2
>      1 GE        OTM-64.3        OTM-40.3        OTM-0.3        STM-16
> 
>                            OCh trail
>               |<-------------------------->|
> 
>                               ODU3 trail
>              |<----------------------------------------->|
> 
>                                  ODU1 trail
>             |<-------------------------------------------->|
> 
>    GE trail                   STM-16 trail                    STM-16 trail
>   |<----->||<---------------------------------------------->||<-------->|
> 
>                              VC-4-Xv (X=1..7) trail
>           |<------------------------------------------------------------>|
> 
>                              Ethernet MAC link
>  |<---------------------------------------------------------------------->|
> 
>                                  IP Link
> |<------------------------------------------------------------------------>|
> 
> Question is again the switching types you will see when requesting a LSP between
> R1 and R2.
> 
> Regards,
> 
> Maarten
> 
> Markus Jork wrote:
> > Let's look at the example of two IP routers connected to a cloud of
> > opaque OXCs:
> >
> > R1 ----- OXC1 ----- OXC2 ----- R2
> >     LSC        LSC        PSC
> >
> > OXC1 and OXC2 switch the Sonet stream from an incoming interface to
> > some outgoing interface, that's why links R1-OXC1 and OXC1-OCX2
> > are advertised as LSC in the IGP. Link OXC2-R2 is PSC because R2 looks
> > at the incoming IP packets. The encoding on the links is OC192.
> >
> > Now I want to setup an LSP between R1 and R2. (This LSP is essentially
> > a "lightpath" through the optical cloud and will be advertised as FA
> > so that PSC LSPs can be tunneled through it later.)
> > What is the switching type requested in the Generalized Label Request
> > object? I would expect LSC.
> > But section 2.1 of draft-ietf-mpls-generalized-rsvp-te-06 says:
> >
> >    A Generalized Label Request object is set by the ingress node,
> >    transparently passed by transit nodes, and used by the egress node.
> >
> > This would suggest the switching type needs to be PSC.
> > But then the text in 2.1.1 says:
> >
> >    Nodes MUST verify that the type indicated in the Switching Type
> >    parameter is supported on the corresponding incoming interface.  If
> >    the type cannot be supported, the node MUST generate a PathErr
> >    message with a "Routing problem/Switching Type" indication.
> >
> > So when the Path message requested PSC, it would be rejected by OXC1
> > and OXC2. When it requested LSC it would be rejected by R2.
> > The transit nodes can't modify the switching type in the Path message
> > because they don't have enough knowledge to pick the right one.
> > How is this supposed to work?
> >
> > thanks for any clarification,
> > Markus
--------------30E4F400DC439DD6286C7FD3
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------30E4F400DC439DD6286C7FD3--

Delivery-date: Wed, 19 Dec 2001 09:51:28 -0800
Date: Wed, 19 Dec 2001 18:35:22 +0100
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: "Mannie, Eric" <[email-masked]>
CC: "'Stephen Trowbridge'" <[email-masked]>, John Drake <[email-masked]>, Maarten Vissers <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

This is a multi-part message in MIME format.
--------------986C2E8614D315EF8C772696
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Eric, all,

Yes of course, whatever you call it "working" and "protection"
/ "primary" and "secondary" / "apple" and "orange" the important
think is that the semantic of these words is interpreted in the
same way by the ingress and egress LSR. 

Back to e-mails we have exchanged in May/June on this issue, we 
had already determine that the semantic of the LSP we have provided
up to now in the current context is only "primary" and "secondary"
and that using a fast notification mechanism and Path activation
will cover basic needs today.

Back to previous meetings, we also discussed these issues and
concluded (i think it was in March) that protection and restoration 
will be covered in details during the next GMPLS steps. More
complex one can be defined (standardized in further work i think
this is purpose of this charter item).

Hope this clarifies,
- dimitri.

"Mannie, Eric" wrote:
> 
> Hello Stephen,
> 
> John refers to fast restoration schemes that are being studied at the IETF.
> Such schemes are widely implemented in the new classes of optical/TDM
> equipments.
> 
> The wording of the text just need to use the terms "working" LSP and
> "protecting" LSP, instead of primary and secondary. That's just an editing
> modification.
> 
> The bit itself is useful to qualify the LSP being established.
> 
> The mechanisms to be applied to this qualification will be detailed in other
> documents.
> 
> In the mean time, I guess that this bit can be used by implementations for a
> simple restoration scheme (e.g. first establish working and protecting LSPs,
> resources of protecting LSP may be "soft reserved", i.e. for extra-traffic,
> when a fault occur send an RSVP-TE rapid failure notification to the source,
> send Path with bit set to "working" on protecting LSP, this kills all LSPs
> using these resources, when acked switch to this LSP).
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Tuesday, December 18, 2001 7:38 PM
> To: John Drake
> Cc: Maarten Vissers; [email-masked]
> Subject: Re: Moving right along ... generalized-signaling-06
> 
> John,
> The problem here is that this is not compatible with transport plane
> protection.
> Assume you do 1:n MSP protection according to ITU Rec. G.841. The operation
> of
> the protection group is controlled by exchange of the K1, K2 bytes in the
> MSOH of the PROTECTION MS. If the control plane reuses the protection MS at
> for a different LSP at a time when the state of the protection group is
> "No Request" (assuming no extra traffic carried on the protection section in
> the
> transport plane), this disables the protection since the endpoints of the
> protection group are no longer able to exchange K1, K2 over the protection
> channel. Even though the payload is unused and irrelevant to the transport
> plane at this point, the exchange of overhead is essential to proper
> operation
> of the protection group.
> Regards,
> Steve
> 
> John Drake wrote:
> >
> > Steven,
> >
> > The basic idea is that if a connection is of type 'secondary', then other
> > LSPs of type 'primary' between the same or different source/destination
> > pairs MAY use its resources in intermediate nodes, until that LSP is
> > converted into a 'primary' with a subsequent Path/Resv flow.  At this
> point,
> > other LSPs that were using its resources may get pre-empted.  Think of the
> > primary/secondary mechanism as a way to ensure temporal priority while
> > allowing network resources to be re-used; i.e., an LSP of type 'secondary'
> > is carrying no data.
> >
> > So in the 1:1 case the protect LSP could be established either as a
> primary
> > or secondary LSP, while in the 1:N case the protect LSP would be
> established
> > as a secondary.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:[email-masked]]
> > Sent: Thursday, December 13, 2001 12:15 PM
> > To: John Drake
> > Cc: Maarten Vissers; [email-masked]
> > Subject: Re: Moving right along ... generalized-signaling-06
> >
> > John,
> > It would seem from this standpoint, ANY transport plane protection
> > must use "primary" for all trails. You have already made this argument
> > for the 1+1 case to carry the permanently bridged copy of the payload.
> >
> > In 1:1 or 1:n, when protection is not being used to carry one/any of
> > the normal traffic signals, it may either carry a null signal (no bridge)
> > or transport plane extra traffic. Even if the transport plane has only
> > a null signal on protection, the control plane cannot itself place extra
> > traffic on any portion of the end-to-end protection channel as this is
> > where the APS protocol is carried to coordinate the 1:1 or 1:n protection.
> > The protection channel overhead is chosen to carry the APS since it is
> > necessary to exchange APS bytes to complete a switch when working channels
> > are failed. If the protection channel has failed and APS cannot be
> > exchanged,
> > normal traffic signals will not be selected from protection.
> > Regards,
> > Steve
> >
> > John Drake wrote:
> > >
> > > Maarten,
> > >
> > > That's fine, however it's beside the point.  The semantics of
> > > Primary/Secondary refer to the control plane and whether the node
> > > establishing a given LSP is planning to use it at the time it's
> > established
> > > or at a later time.  As I indicated in an earlier note, 1+1 transport
> > plane
> > > protection would be accomplished in the control plane by establishing
> two
> > > LSPs of type Primary.  The control plane really doesn't care which LSP
> the
> > > transport plane is using as Working and which as Protect, although that
> > > information is available to the control plane at the LSP endpoints.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Maarten Vissers [mailto:[email-masked]]
> > > Sent: Thursday, December 13, 2001 12:15 AM
> > > To: [email-masked]
> > > Subject: Re: Moving right along ... generalized-signaling-06
> > >
> > > There exist well defined protection terminology in ITU-T for the
> transport
> > > plane. "Working" and "Protection" are being used and not
> > primary/secondary.
> > > E.g.
> > > a 1+1 architecture has one working connection, one protection connection
> > and
> > > a
> > > permanent bridge.
> > >
> > > Besides working/protection indication for the transport entity, there is
> > > - "active" and "standby" to indicate if the signal is selected from the
> > > working
> > > or protection transport entity; i.e. if selector selects from working,
> the
> > > working is active and protection is standby, if the selector selects
> from
> > > protection the working is standby and the protection is active.
> > > - "normal" and "extra traffic" signal. The normal signal is protected.
> > >
> > > Regards,
> > >
> > > Maarten
> > >
> > > [email-masked] wrote:
> > > >
> > > > Jonathan....review the text below....I think the problem is 1:1.
> > > >
> > > > neil
> > > >
> > > > > -----Original Message-----
> > > > > From: Jonathan Lang [mailto:[email-masked]]
> > > > > Sent: 12 December 2001 17:46
> > > > > To: 'Ben Mack-Crane'; John Drake
> > > > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > > > Subject: RE: Moving right along ... generalized-signaling-06
> > > > >
> > > > >
> > > > > Ben,
> > > > >   Please see inline.
> > > > >
> > > > > Thanks,
> > > > > Jonathan
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > > > Sent: Wednesday, December 12, 2001 8:56 AM
> > > > > > To: John Drake
> > > > > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > > > >
> > > > > >
> > > > > > See comment below.
> > > > > >
> > > > > > Regards,
> > > > > > Ben
> > > > > >
> > > > > > John Drake wrote:
> > > > > > >
> > > > > > > Snipped
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > > > > Sent: Tuesday, December 11, 2001 6:38 AM
> > > > > > > To: Lou Berger
> > > > > > > Cc: Kireeti Kompella; [email-masked]
> > > > > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >7) In Protection Information it states "The resources
> > > > > > allocated for a
> > > > > > > > >    secondary LSP MAY be used by other LSPs until the
> > > > > > primary LSP fails
> > > > > > > > >    over to the secondary LSP."  This may not always be
> > > > > > the case.  An
> > > > > > > > >    explicit flag indicating whether or not extra
> > > > > > traffic may use the
> > > > > > > > >    secondary path resources is needed.
> > > > > > > >
> > > > > > > > ??? This is the purpose of this bit.
> > > > > > >
> > > > > > > This is not clear from the definition.  The bit is defined
> > > > > > as indicating
> > > > > > > the LSP is a secondary (or protecting) LSP and in 1+1
> > > > > protection the
> > > > > > > secondary LSP may not be used for extra traffic.
> > > > > > >
> > > > > > > Perhaps the problem here is that protection features are
> > > > > > being defined
> > > > > > > before the protection framework and requirements are
> > > > > done.  Is this
> > > > > > > presupposing some particular outcome of the recovery work in
> CAMP?
> > > > > > >
> > > > > > > JD:  I think the definition of the bit is fine.  For both
> > > > > > 1+1 and 1:1
> > > > > > > protection, there would be a pair of Primary LSPs between
> > > > > the source
> > > > > > > and destination, rather than a Primary and a Secondary.
> > > > > >
> > > > > > This is an unusual use of terms.  I have never encountered a case
> > > > > > where both the working and recovery paths are call "primary."
> > > > > >
> > > > > > This is not consistent with either draft-mpls-recovery-framework
> > > > > > or with draft-lang-ccamp-recovery.  I think this is a sign that
> the
> > > > > > protection work is immature and not ready for progressing to RFC.
> > > > > >
> > > > > For 1+1 path protection, both working/recovery paths are
> > > > > carrying user data
> > > > > traffic and it is an endpoint decision as to which path is
> > > > > actually the
> > > > > working/recovery path.  At a transit node, both paths need to
> > > > > be treated as
> > > > > primary, as the resources are currently being used and
> > > > > obviously can't be
> > > > > used for Extra Traffic.
> > > > >
--------------986C2E8614D315EF8C772696
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------986C2E8614D315EF8C772696--

Delivery-date: Wed, 19 Dec 2001 09:51:18 -0800
Date: Wed, 19 Dec 2001 18:34:39 +0100
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: John Drake <[email-masked]>
CC: "'Stephen Trowbridge'" <[email-masked]>, Maarten Vissers <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

This is a multi-part message in MIME format.
--------------8986464869B5E4647CEE556F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John,

To be more generic, any technology that does not support associated
overhead (SDH/Sonet) or non-associated overhead (G.709 OCh) can use
the control plane for protection switching purposes.

In addition to the references you have provided i would like to add
the following one:

http://search.ietf.org/internet-drafts/draft-many-optical-restoration-01.txt

Cheers,
- dimitri.   

John Drake wrote:
> 
> Stephen,
> 
> You're absolutely right if you want to use K1/K2 to signal the switchover
> from working to protect.  We were planning to use the control plane
> signalling protocols, since we have to deal with more than just SONET/SDH.
> See for example:
> 
> http://search.ietf.org/internet-drafts/draft-li-shared-mesh-restoration-01.t
> xt
> 
> http://search.ietf.org/internet-drafts/draft-bala-protection-restoration-sig
> naling-00.txt
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Tuesday, December 18, 2001 10:38 AM
> To: John Drake
> Cc: Maarten Vissers; [email-masked]
> Subject: Re: Moving right along ... generalized-signaling-06
> 
> John,
> The problem here is that this is not compatible with transport plane
> protection.
> Assume you do 1:n MSP protection according to ITU Rec. G.841. The operation
> of
> the protection group is controlled by exchange of the K1, K2 bytes in the
> MSOH of the PROTECTION MS. If the control plane reuses the protection MS at
> for a different LSP at a time when the state of the protection group is
> "No Request" (assuming no extra traffic carried on the protection section in
> the
> transport plane), this disables the protection since the endpoints of the
> protection group are no longer able to exchange K1, K2 over the protection
> channel. Even though the payload is unused and irrelevant to the transport
> plane at this point, the exchange of overhead is essential to proper
> operation
> of the protection group.
> Regards,
> Steve
> 
> John Drake wrote:
> >
> > Steven,
> >
> > The basic idea is that if a connection is of type 'secondary', then other
> > LSPs of type 'primary' between the same or different source/destination
> > pairs MAY use its resources in intermediate nodes, until that LSP is
> > converted into a 'primary' with a subsequent Path/Resv flow.  At this
> point,
> > other LSPs that were using its resources may get pre-empted.  Think of the
> > primary/secondary mechanism as a way to ensure temporal priority while
> > allowing network resources to be re-used; i.e., an LSP of type 'secondary'
> > is carrying no data.
> >
> > So in the 1:1 case the protect LSP could be established either as a
> primary
> > or secondary LSP, while in the 1:N case the protect LSP would be
> established
> > as a secondary.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:[email-masked]]
> > Sent: Thursday, December 13, 2001 12:15 PM
> > To: John Drake
> > Cc: Maarten Vissers; [email-masked]
> > Subject: Re: Moving right along ... generalized-signaling-06
> >
> > John,
> > It would seem from this standpoint, ANY transport plane protection
> > must use "primary" for all trails. You have already made this argument
> > for the 1+1 case to carry the permanently bridged copy of the payload.
> >
> > In 1:1 or 1:n, when protection is not being used to carry one/any of
> > the normal traffic signals, it may either carry a null signal (no bridge)
> > or transport plane extra traffic. Even if the transport plane has only
> > a null signal on protection, the control plane cannot itself place extra
> > traffic on any portion of the end-to-end protection channel as this is
> > where the APS protocol is carried to coordinate the 1:1 or 1:n protection.
> > The protection channel overhead is chosen to carry the APS since it is
> > necessary to exchange APS bytes to complete a switch when working channels
> > are failed. If the protection channel has failed and APS cannot be
> > exchanged,
> > normal traffic signals will not be selected from protection.
> > Regards,
> > Steve
> >
> > John Drake wrote:
> > >
> > > Maarten,
> > >
> > > That's fine, however it's beside the point.  The semantics of
> > > Primary/Secondary refer to the control plane and whether the node
> > > establishing a given LSP is planning to use it at the time it's
> > established
> > > or at a later time.  As I indicated in an earlier note, 1+1 transport
> > plane
> > > protection would be accomplished in the control plane by establishing
> two
> > > LSPs of type Primary.  The control plane really doesn't care which LSP
> the
> > > transport plane is using as Working and which as Protect, although that
> > > information is available to the control plane at the LSP endpoints.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Maarten Vissers [mailto:[email-masked]]
> > > Sent: Thursday, December 13, 2001 12:15 AM
> > > To: [email-masked]
> > > Subject: Re: Moving right along ... generalized-signaling-06
> > >
> > > There exist well defined protection terminology in ITU-T for the
> transport
> > > plane. "Working" and "Protection" are being used and not
> > primary/secondary.
> > > E.g.
> > > a 1+1 architecture has one working connection, one protection connection
> > and
> > > a
> > > permanent bridge.
> > >
> > > Besides working/protection indication for the transport entity, there is
> > > - "active" and "standby" to indicate if the signal is selected from the
> > > working
> > > or protection transport entity; i.e. if selector selects from working,
> the
> > > working is active and protection is standby, if the selector selects
> from
> > > protection the working is standby and the protection is active.
> > > - "normal" and "extra traffic" signal. The normal signal is protected.
> > >
> > > Regards,
> > >
> > > Maarten
> > >
> > > [email-masked] wrote:
> > > >
> > > > Jonathan....review the text below....I think the problem is 1:1.
> > > >
> > > > neil
> > > >
> > > > > -----Original Message-----
> > > > > From: Jonathan Lang [mailto:[email-masked]]
> > > > > Sent: 12 December 2001 17:46
> > > > > To: 'Ben Mack-Crane'; John Drake
> > > > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > > > Subject: RE: Moving right along ... generalized-signaling-06
> > > > >
> > > > >
> > > > > Ben,
> > > > >   Please see inline.
> > > > >
> > > > > Thanks,
> > > > > Jonathan
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > > > Sent: Wednesday, December 12, 2001 8:56 AM
> > > > > > To: John Drake
> > > > > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > > > >
> > > > > >
> > > > > > See comment below.
> > > > > >
> > > > > > Regards,
> > > > > > Ben
> > > > > >
> > > > > > John Drake wrote:
> > > > > > >
> > > > > > > Snipped
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > > > > Sent: Tuesday, December 11, 2001 6:38 AM
> > > > > > > To: Lou Berger
> > > > > > > Cc: Kireeti Kompella; [email-masked]
> > > > > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >7) In Protection Information it states "The resources
> > > > > > allocated for a
> > > > > > > > >    secondary LSP MAY be used by other LSPs until the
> > > > > > primary LSP fails
> > > > > > > > >    over to the secondary LSP."  This may not always be
> > > > > > the case.  An
> > > > > > > > >    explicit flag indicating whether or not extra
> > > > > > traffic may use the
> > > > > > > > >    secondary path resources is needed.
> > > > > > > >
> > > > > > > > ??? This is the purpose of this bit.
> > > > > > >
> > > > > > > This is not clear from the definition.  The bit is defined
> > > > > > as indicating
> > > > > > > the LSP is a secondary (or protecting) LSP and in 1+1
> > > > > protection the
> > > > > > > secondary LSP may not be used for extra traffic.
> > > > > > >
> > > > > > > Perhaps the problem here is that protection features are
> > > > > > being defined
> > > > > > > before the protection framework and requirements are
> > > > > done.  Is this
> > > > > > > presupposing some particular outcome of the recovery work in
> CAMP?
> > > > > > >
> > > > > > > JD:  I think the definition of the bit is fine.  For both
> > > > > > 1+1 and 1:1
> > > > > > > protection, there would be a pair of Primary LSPs between
> > > > > the source
> > > > > > > and destination, rather than a Primary and a Secondary.
> > > > > >
> > > > > > This is an unusual use of terms.  I have never encountered a case
> > > > > > where both the working and recovery paths are call "primary."
> > > > > >
> > > > > > This is not consistent with either draft-mpls-recovery-framework
> > > > > > or with draft-lang-ccamp-recovery.  I think this is a sign that
> the
> > > > > > protection work is immature and not ready for progressing to RFC.
> > > > > >
> > > > > For 1+1 path protection, both working/recovery paths are
> > > > > carrying user data
> > > > > traffic and it is an endpoint decision as to which path is
> > > > > actually the
> > > > > working/recovery path.  At a transit node, both paths need to
> > > > > be treated as
> > > > > primary, as the resources are currently being used and
> > > > > obviously can't be
> > > > > used for Extra Traffic.
> > > > >
--------------8986464869B5E4647CEE556F
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------8986464869B5E4647CEE556F--

Delivery-date: Wed, 19 Dec 2001 09:46:23 -0800
Date: Wed, 19 Dec 2001 18:37:00 +0100
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: Maarten Vissers <[email-masked]>
CC: "Mannie, Eric" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: GMPLS signaling documents updated per last calls

This is a multi-part message in MIME format.
--------------C98D972D8359A4EA3CF28E63
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This discussion is going into limbos because once a solution  
is provided and agreed by all parties, afterwards the elements 
having enabled to come up to this decision disappear... for
instance, VT3 SPE now are not used anymore... were they used 
one week before and just stop now ? 

Mor generally, since it is not the job of the CCAMP community to 
verify if the content of ITU/T1X1 specifications are implemented 
in current networks it is for me irrelevant to state as done by 
Stephen that they are not used. How can i verify such assertion ?

At the end of the day i have got the following impression ITU
T1 people blind the differences they maintain in their own
documents... Deborah/Stephen sorry but GR.253 specification has 
just been extended to LCAS capabilities so T1X1 and ITU maintains
their own version (G.707 is also being extended)... in this 
context sorry but we are at a point where people maintains 
artificial discussions for reasons which are very difficult 
to understand ? 

Very interesting the following e-mail from Maarten, why do i 
have to keep two terms in order to translate the same entity
if Sonet is a subset of SDH ? 

Cheers,
- dimitri.

Maarten Vissers wrote:
> 
> Eric,
> 
> It is not the intention to leave the choice of LSP encoding type and SU label
> structure to the vendor. This would give immediate interworking problems.
> 
> VC-11/VT1.5, VC-12/VT-2, VC-2/VT-6, VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c,
> VC-4-16c/STS-48c, VC-4-64c/STS-192c and VC-4-256c/STS-768c must all have LSP
> encoding type "SDH". Also STS-1/STM-0 upto STM-256/STS-768 must have the LSP
> encoding type "SDH".
> 
> VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, VC-4-16c/STS-48c, VC-4-64c/STS-192c
> and VC-4-256c/STS-768c must all have the same SDH-based "SU" structure.
> 
> Looking at the label text in section 3 of the sonet-sdh document, I find it very
> confusing to read that SONET doesn't use the "U" field. As we indicated before
> there is no STS type signal that isn't having an SDH equivalent; i.e. there are
> no specific higher order SONET signals left. It is therefore much better to take
> out the SONET text for the SU label part altogether. Otherwise we will get a lot
> of confusion in the marketplace.
> 
> Also the examples with STS-1 (examples 3 to 5 in secton 3) must use the label
> with U in the range 2 to 4; the STS-1 is equivalent to the VC-3 in SDH and must
> thus use the "SDH" SU format.
> 
> -------
> 
> All,
> 
> With the clarification on VT-3 given by Deborah, I would request to consider a
> further simplification of the GMPLS standard: delete the LSP encoding type
> "SONET" and rename the LSP encoding type "SDH" into "SDH/SONET". Then there
> would be no ambiguity left at all.
> 
> Regards,
> 
> Maarten
> 
> "Mannie, Eric" wrote:
> >
> > Hi Jonathan,
> >
> > > Why SHOULD and not MUST?  This ambiguity is likely to create
> > interoperability problems in the future...
> >
> > To leave to the manufacturer and to the user the right to decide if he/she
> > wants to signal an LSP as either SDH or SONET. There is no interoperability
> > problem at all since you use EITHER SDH OR SONET. If you decide to request
> > an SDH signal with what do you want to have interoperability issue at this
> > stage ? The sentence means indeed "one should better use SDH than SONET" !
> > Once you decided, there is no issue.
> >
> > > I'm curious what sort of backward compatability is necessary, as a
> > "standard" doesn't exist currently that this needs to be backward
> > compatible with...
> >
> > Backward compatibility with the OIF UNI 1.0 Implementation Agreement, with
> > the implementations that could not care of SDH, with implementations that
> > still do a distinction between SONET and SDH for some reasons, with the
> > implementations that could still use the VT3 (DS1C) (I don't have
> > confirmation that nobody is using it today, and this is not the goal of this
> > draft to state what is obsolete or not in SONET), etc.
> >
> > Anyway, there is no issue, the SONET label format is not used until SONET is
> > explicitly requested as such. This is not a primary feature of the draft,
> > but a *secondary feature*, for SONET lovers. Otherwise, SDH is used for
> > everything, consequently you don't care of the SONET label, you skip it in
> > the draft, you ignore it, you don't implement it and you just use a full SDH
> > implementation.
> >
> > I think that the solution is quite simple: if the SONET signal is indeed an
> > SDH signal, why do you bother with SONET ? Just ask for an SDH signal,
> > that's all.
> >
> > By the way, since according to some folks SONET is just a subset of SDH, why
> > do we care about SONET in these documents ? Why don't we simply remove all
> > references to SONET ?
> >
> > Is there somebody on this mailing list that cares about SONET ? If yes, why
> > ? Who is still manufacturing SONET boxes ? Why is that not called SDH ?
> >
> > Kind regards,
> >
> > Eric
> >
> > -----Original Message-----
> > From: Jonathan Sadler [mailto:[email-masked]]
> > Sent: Tuesday, December 18, 2001 9:57 PM
> > To: Mannie, Eric
> > Cc: 'Stephen Trowbridge'; Kireeti Kompella; [email-masked];
> > [email-masked]; [email-masked]
> > Subject: Re: GMPLS signaling documents updated per last calls
> >
> > Eric -
> >
> > Comments inline...
> >
> > Jonathan Sadler
> >
> > "Mannie, Eric" wrote:
> > > "A SONET signal which has an identical SDH signal SHOULD be requested
> > using
> > > the same traffic parameters as for the equivalent SDH signal, and will
> > > consequently use the SDH label."
> >
> > Why SHOULD and not MUST?  This ambiguity is likely to create
> > interoperability problems in the future...
> >
> > > We spend with Maarten a lot of time to write that sentence (not easy to
> > > write).
> > >
> > > Maybe that it should be better written:
> > >
> > > "A SONET signal which has an identical SDH signal SHOULD be requested as
> > an
> > > SDH signal using the same traffic parameters as for the equivalent SDH
> > > signal, and will consequently use the SDH label."
> >
> > Again, "SHOULD" needs to be replaced with "MUST"...
> >
> > > This doesn't mean that the SONET signal format disappear (simply not used
> > in
> > > that case), for backward compatibility we need to keep it.
> >
> > I'm curious what sort of backward compatability is necessary, as a
> > "standard" doesn't exist currently that this needs to be backward
> > compatible with...
> >
> > > Kind regards,
> > >
> > > Eric
> > >
> > > -----Original Message-----
> > > From: Stephen Trowbridge [mailto:[email-masked]]
> > > Sent: Tuesday, December 18, 2001 7:46 PM
> > > To: Kireeti Kompella
> > > Cc: [email-masked]; [email-masked]; [email-masked];
> > > [email-masked]; [email-masked]
> > > Subject: Re: GMPLS signaling documents updated per last calls
> > >
> > > Kireeti,
> > > The one outlyer is VT3 (3 Megabits). VC-3 is an extremely popular
> > > rate in both SONET and SDH. I exchanged an email with Deborah Brungard
> > > (T1X1.5 chair) on this one and I take the liberty of sharing her response:
> > >
> > > Deborah Brungard wrote:
> > > > The VT3 (3M) structure was defined - but no services (mappings) were
> > ever
> > > defined for it. So there are no services/equip
> > > > with it. My take was if in the future it was ever defined (doubtful), we
> > > would be adding it to g707 also. So then it
> > > > would just be part of g707 too.
> > >
> > > So basically, there are no mappings or equipment functions for this rate,
> > > and as far as we know no network equipment or networks supporting it.
> > > Deborah suggests that if we were ever to define such mappings, that this
> > > would be proposed for addition to G.707 and hence be part of SDH.
> > >
> > > I think our agreement had been to use the SDH label for all signals that
> > > had the same multiplex structure in SONET and SDH. In Salt Lake City, we
> > > thought
> > > that this was everything except VT3. Given that VT3 seems not to be a
> > "real"
> > > signal at this point and will likely be added to SDH if it ever becomes
> > > real, does our agreement then become that we use SDH labels for
> > everything?
> > >
> > > Regards,
> > > Steve
> > >
> > > Kireeti Kompella wrote:
> > > >
> > > > Hi Deborah,
> > > >
> > > > > I previously made the
> > > > > comments to merge the (1) SDH and SONET values as one value
> > > >
> > > > There was a meeting among Steve Trowbridge, Maarten Vissers,
> > > > Eric Mannie, Dimitri Papadimitriou, the CCAMP ADs and chairs on
> > > > several issues, among them this one.  The upshot was that whenever
> > > > possible, the SDH label should be used, with the encoding type
> > > > set to SDH (i.e., G.707); however, there are signals that have
> > > > no SDH equivalent (if I remember right, VC-3 -- someone correct
> > > > me!), so we will keep SONET labels and encoding types around
> > > > for that case and for legacy equipment.
> > > >
> > > > The revised SONET/SDH document will contain the exact wording.
> > > > I will also be sending a reply to the ITU communication stating
> > > > the agreement we came to.
> > > >
> > > > Kireeti.
--------------C98D972D8359A4EA3CF28E63
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------C98D972D8359A4EA3CF28E63--

Delivery-date: Wed, 19 Dec 2001 09:28:51 -0800
From: Randy Bush <[email-masked]>
To: Philip Matthews <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: FYI - Discussion of LDP resiliency in MPLS WG
Date: Wed, 19 Dec 2001 09:24:35 -0800

you must post from your subscription address

randy

> Message-ID: <[email-masked]>
> MIME-Version: 1.0
> Content-Type: multipart/alternative;
> 	boundary="----_=_NextPart_001_01C188B1.8B73B710"
> From: Philip Matthews <[email-masked]>
> To: "[email-masked]'" <[email-masked]>
> Subject: FYI - Discussion of LDP resiliency in MPLS WG
> Date: Wed, 19 Dec 2001 12:21:07 -0500
> 
> For those not subscribed to the MPLS WG list,
> I just posted a note on the status of the various proposals
> for LDP resiliency to the MPLS WG mailing list.
> 
> People in CCAMP might also be interested in this work,
> because some of it also applies to CR-LDP, and because
> there are similar proposals for RSVP-TE, as well as
> for various routing protocols.
> 
> I will ask that people interesting in contributing
> post their comments to the MPLS WG, and not to CCAMP,
> since the work is happening in the former.
> 
> - Philip
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
> <HEAD>
> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
> <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
> <TITLE>FYI - Discussion of LDP resiliency in MPLS WG</TITLE>
> </HEAD>
> <BODY>
> 
> <P><FONT SIZE=2>For those not subscribed to the MPLS WG list,</FONT>
> <BR><FONT SIZE=2>I just posted a note on the status of the various proposals</FONT>
> <BR><FONT SIZE=2>for LDP resiliency to the MPLS WG mailing list.</FONT>
> </P>
> 
> <P><FONT SIZE=2>People in CCAMP might also be interested in this work,</FONT>
> <BR><FONT SIZE=2>because some of it also applies to CR-LDP, and because</FONT>
> <BR><FONT SIZE=2>there are similar proposals for RSVP-TE, as well as</FONT>
> <BR><FONT SIZE=2>for various routing protocols.</FONT>
> </P>
> 
> <P><FONT SIZE=2>I will ask that people interesting in contributing</FONT>
> <BR><FONT SIZE=2>post their comments to the MPLS WG, and not to CCAMP,</FONT>
> <BR><FONT SIZE=2>since the work is happening in the former.</FONT>
> </P>
> 
> <P><FONT SIZE=2>- Philip</FONT>
> </P>
> 
> </BODY>
> </HTML>

Delivery-date: Wed, 19 Dec 2001 07:55:29 -0800
To: George Newsome <[email-masked]>
cc: CCAMP <[email-masked]>
Subject: Re: GMPLS Issue - Ethernet LSP Enc Type 
Date: Wed, 19 Dec 2001 07:34:32 -0800
From: Yakov Rekhter <[email-masked]>

George,

> > > > At 10:55 AM 12/18/2001, Ben Mack-Crane wrote:
> > > >
> > > > >The following issue raised 10/29/01 has not been addressed.
> > > >
> ........................
> > > >
> > > > The current wording is what was agreed to.
> > > >
> > >
> > >So if I understand this correctly, the wording that you allude to was
> > >agreed in private discusions?
> > 
> > To be precise, the wording was agreed to among all the authors.
> > 
> I stand corrected - agreed to in private discussions among all the
> authors.
> 
> > >Without public discussion,
> > 
> > I think you'd agree that it's impractical to review in detail every change
> > in a draft, prior to it being made, on the ccamp list.  What we have done
> > is to reach agreement first among the co-authors and then to review the
> > changes as part of issuing the new drafts.   The encoding type change was
> > made *9* months ago.  There has been ample opportunity for review and comme
> > comment.
> > 
> Actually I disagree. In other bodies documents are reviewed on a line by
> line basis until all parties indicate agreement.

I hope it would not surprise you that the rules of "other bodies" 
may not apply to the IETF, as in the IETF there is a need only for "rough 
consensus", and not for all parties to reach an agreement. 

Yakov.

Delivery-date: Wed, 19 Dec 2001 07:53:36 -0800
Date: Wed, 19 Dec 2001 10:31:15 -0500
To: "George Newsome" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: GMPLS Issue - Ethernet LSP Enc Type
Cc: "Berger, Lou" <[email-masked]>, "Ben Mack-Crane" <[email-masked]>, "CCAMP" <[email-masked]>,[email-masked]

George,
         See responses below.

At 10:14 AM 12/19/2001, George Newsome wrote:

>Lou Berger wrote:
> >
> > At 09:19 AM 12/19/2001, George Newsome wrote:
> > >Lou Berger wrote:
> > > >
> > > > At 10:55 AM 12/18/2001, Ben Mack-Crane wrote:
> > > >
> > > > >The following issue raised 10/29/01 has not been addressed.
> > > >
>........................
> > > >
> > > > The current wording is what was agreed to.
> > > >
> > >
> > >So if I understand this correctly, the wording that you allude to was
> > >agreed in private discusions?
> >
> > To be precise, the wording was agreed to among all the authors.
> >
>I stand corrected - agreed to in private discussions among all the
>authors.

I was clarifying my earlier statement, my apologies if it came off as 
correcting you.

> > >Without public discussion,
> >
> > I think you'd agree that it's impractical to review in detail every change
> > in a draft, prior to it being made, on the ccamp list.  What we have done
> > is to reach agreement first among the co-authors and then to review the
> > changes as part of issuing the new drafts.   The encoding type change was
> > made *9* months ago.  There has been ample opportunity for review and 
> comment.
> >
>Actually I disagree. In other bodies documents are reviewed on a line by
>line basis until all parties indicate agreement.

I'm surprised to see you say this as you must know this is not how things 
work in the IETF.

>........
> >
> > isn't there some quote about pleasing all the people all the time...
> >
>Isn't there also some quote that in science and engineering, volume of
>opinion != correctness?

Again, per my last message:
>again, one person objecting != lack of "rough consensus".
>
>Remember this item has not changed since March.
>
>Unless the WG chair says otherwise, I see this issues as closed.

Lou

>Regards
>
>        George

Delivery-date: Wed, 19 Dec 2001 07:20:05 -0800
Date: Wed, 19 Dec 2001 10:14:40 -0500
From: George Newsome <[email-masked]>
Organization: Lucent Technologies, Bell Labs
To: Lou Berger <[email-masked]>
CC: Ben Mack-Crane <[email-masked]>, CCAMP <[email-masked]>
Subject: Re: GMPLS Issue - Ethernet LSP Enc Type

Lou Berger wrote:
> 
> At 09:19 AM 12/19/2001, George Newsome wrote:
> >Lou Berger wrote:
> > >
> > > At 10:55 AM 12/18/2001, Ben Mack-Crane wrote:
> > >
> > > >The following issue raised 10/29/01 has not been addressed.
> > >
........................
> > >
> > > The current wording is what was agreed to.
> > >
> >
> >So if I understand this correctly, the wording that you allude to was
> >agreed in private discusions?
> 
> To be precise, the wording was agreed to among all the authors.
> 
I stand corrected - agreed to in private discussions among all the
authors.

> >Without public discussion,
> 
> I think you'd agree that it's impractical to review in detail every change
> in a draft, prior to it being made, on the ccamp list.  What we have done
> is to reach agreement first among the co-authors and then to review the
> changes as part of issuing the new drafts.   The encoding type change was
> made *9* months ago.  There has been ample opportunity for review and comment.
> 
Actually I disagree. In other bodies documents are reviewed on a line by
line basis until all parties indicate agreement.

........
> 
> isn't there some quote about pleasing all the people all the time...
> 
Isn't there also some quote that in science and engineering, volume of
opinion != correctness?

Regards

       George

Delivery-date: Wed, 19 Dec 2001 06:43:27 -0800
Date: Wed, 19 Dec 2001 09:40:46 -0500
To: George Newsome <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: GMPLS Issue - Ethernet LSP Enc Type
Cc: Lou Berger <[email-masked]>, Ben Mack-Crane <[email-masked]>,CCAMP <[email-masked]>

At 09:19 AM 12/19/2001, George Newsome wrote:
>Lou Berger wrote:
> >
> > At 10:55 AM 12/18/2001, Ben Mack-Crane wrote:
> >
> > >The following issue raised 10/29/01 has not been addressed.
> >
> > I disagree.  We talked in person on this and I said the same thing on 
> the list.
> >
> > > > >1) There seems to be no difference as far as label allocation
> > > > >    is concerned between LSP Encoding Types Ethernet V2/DIX (2)
> > > > >    and Ethernet 802.3 (10).  One Encoding type would seem to
> > > > >    be sufficient.
> > > >
> > > > I agree, but some feel that this is needed to properly establish 
> LSPs in
> > > > systems what would terminate each type differently.
> > >
> > >I don't recall seeing anything on the list about the reasoning about this.
> > >can someone provide a pointer to where this was described?
> >
> > As I mentioned at the IETF, it was in private discussions.
> >
> > >Since LSP Encoding type is intended to describe the LSP for transit nodes
> > >and G-PID is intended to describe the LSP contents for the purpose of
> > >terminating it at the ends, information relevant only to termination
> > >should be conveyed in G-PID.
> > >
> > >Perhaps changing the name of this LSP Encoding Type to "Ethernet Phy"
> > >would make this clearer.
> >
> > The current wording is what was agreed to.
> >
>
>So if I understand this correctly, the wording that you allude to was
>agreed in private discusions?

To be precise, the wording was agreed to among all the authors.

>Without public discussion,

I think you'd agree that it's impractical to review in detail every change 
in a draft, prior to it being made, on the ccamp list.  What we have done 
is to reach agreement first among the co-authors and then to review the 
changes as part of issuing the new drafts.   The encoding type change was 
made *9* months ago.  There has been ample opportunity for review and comment.

>  it seems hard to claim that the issue has
>been resolved,

again, one person objecting != lack of "rough consensus".

Remember this item has not changed since March.

Unless the WG chair says otherwise, I see this issues as closed.

>and Ben is clearly not satisfied.

isn't there some quote about pleasing all the people all the time...

Lou

>Regards
>
>         George

Delivery-date: Wed, 19 Dec 2001 06:32:14 -0800
To: "Maarten Vissers" <[email-masked]>
cc: "Markus Jork" <[email-masked]>, "Berger, Lou" <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... generalized-rsvp-te-05 
Date: Wed, 19 Dec 2001 06:20:56 -0800
From: Yakov Rekhter <[email-masked]>

Maarten,

>Markus, John, Lou, Manoj,
>
>I also still have a major issue to understand the switching type... or more
>precise I have the feeling it is too coarse and ill defined. Let me 
>provide some more examples to evaluate:
>
>Frist Markus' network example... it will look like the following in reality
>
>  R1 ------ OXC1 ------ OXC2 ------ R2
>      OC-N        OC-N        OC-N
>
>               OC-N trail
>   |<------------------------------>|
>
>              STS-Nc trail
>  |<-------------------------------->|
>
>               IP Link
>|<---------------------------------->|
>
>I assume that OXC1/2 are all optical cross connects which pass through the
>complete OC-N signals.
>
>In order to route IP packets between R1 and R2, you need to set up an OC-N 
>trail between R1 and R2. 

Correct. 

(Stating the obvious) the Switching Type for that LSP will 
be set to LSC.

> Once this is done, you need to set up a STS-Nc trail between
> R1 and R2. Once this is done you have an IP link with a bandwidth of 9 584 
> 640 kbit/s established between R1 and R2. 
> Now IP signals can flow between R1 and R2.

There is no need to establish an STS-Nc trail between R1 and R2 - the OC-N
LSP is sufficient.

>Now make the example a bit more complex and let me add a SONET cross 
>connect in the chain.
>
>  R1 ------ OXC1 ------ OXC2 ------ DXC1 ------ R2
>      OC-N        OC-N        OC-N        OC-N
>
>               OC-N trail              OC-N trail
>   |<------------------------------>|  |<------>|
>
>                   STS-Nc trail
>  |<-------------------------------------------->|
>
>                       IP Link
>|<---------------------------------------------->|
>
>The physical interface in each case is an OC-N. The DXC1 is a SONET cross
>connect, which terminates the OC-N Section and Line layers and forwards the
>STS-Nc signal.
>
>What would the switching types be in this case when an LSP is requested 
>between R1 and R2?

(stating the obvious) TDM.

Yakov.

Delivery-date: Wed, 19 Dec 2001 06:31:29 -0800
Date: Wed, 19 Dec 2001 09:19:43 -0500
From: George Newsome <[email-masked]>
Organization: Lucent Technologies, Bell Labs
To: Lou Berger <[email-masked]>
CC: Ben Mack-Crane <[email-masked]>, CCAMP <[email-masked]>
Subject: Re: GMPLS Issue - Ethernet LSP Enc Type

Lou Berger wrote:
> 
> At 10:55 AM 12/18/2001, Ben Mack-Crane wrote:
> 
> >The following issue raised 10/29/01 has not been addressed.
> 
> I disagree.  We talked in person on this and I said the same thing on the list.
> 
> > > >1) There seems to be no difference as far as label allocation
> > > >    is concerned between LSP Encoding Types Ethernet V2/DIX (2)
> > > >    and Ethernet 802.3 (10).  One Encoding type would seem to
> > > >    be sufficient.
> > >
> > > I agree, but some feel that this is needed to properly establish LSPs in
> > > systems what would terminate each type differently.
> >
> >I don't recall seeing anything on the list about the reasoning about this.
> >can someone provide a pointer to where this was described?
> 
> As I mentioned at the IETF, it was in private discussions.
> 
> >Since LSP Encoding type is intended to describe the LSP for transit nodes
> >and G-PID is intended to describe the LSP contents for the purpose of
> >terminating it at the ends, information relevant only to termination
> >should be conveyed in G-PID.
> >
> >Perhaps changing the name of this LSP Encoding Type to "Ethernet Phy"
> >would make this clearer.
> 
> The current wording is what was agreed to.
> 

So if I understand this correctly, the wording that you allude to was
agreed in private discusions?

Without public discussion, it seems hard to claim that the issue has
been resolved, and Ben is clearly not satisfied.

Regards

	George

Delivery-date: Wed, 19 Dec 2001 06:09:27 -0800
Date: Wed, 19 Dec 2001 08:57:13 -0500
To: <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: RE: Fwd: Comments on GMPLS signalling drafts
Cc: "Berger, Lou" <[email-masked]>, "manoj juneja" <[email-masked]>,<[email-masked]>, <[email-masked]>,<[email-masked]>

Fong,
         Thank you for the explanation.  Given where we are in the process 
and that it is acceptable, we should leave it as it stands.

As usual, thank you for the comments.

Lou

PS Yes, I misread Manoj's comments.  Obviously, I thought he was saying 
that we used your text without reference.  As you know, and as indicated in 
the document, we have integrated text that you have proposed.

At 09:26 PM 12/18/2001, Fong Liaw wrote:

>Lou
>
>I was not in London, so probably just not being informed.
>The proposed change does not create interoperability problem
>since there is only one node that would resolves it,
>but I have no problem keeping the current text either.  The problem
>seems to be that the same question keeps on coming back and
>there are situations where a different resolution will result
>in slightly better call setup.  A typical scenario is that
>a call coming from network to user has gone a long way and
>usually has priority on getting the resources.
>
>The question we are facing here is whether different
>behavior, if does not create interoperability issue,
>is allowed. From my read of the draft, it is not ..
>Again, I have no problem with current text so you don't
>have to convince me, I thought you agree with manoj's
>comment and in that case the current text does not
>reflect it.
>
>Regards,
>-Fong
>
> > -----Original Message-----
> > From: [email-masked] 
> [<mailto:[email-masked]>mailto:[email-masked]]On
> > Behalf Of Lou Berger
> > Sent: Tuesday, December 18, 2001 3:22 PM
> > To: Fong Liaw
> > Cc: Berger, Lou; manoj juneja; [email-masked];
> > [email-masked]; [email-masked]
> > Subject: Re: Fwd: Comments on GMPLS signalling drafts
> >
> >
> > Fong,
> >          As you know, we've discussed this many times.  The last time it
> > was discussed in detail (London if memory serves) my memory is that we
> > decided to keep current working as is because (a) different vendor
> > approaches can lead to interoperability issues and (b) this is a common
> > tie-breaker solution.
> >
> > Lou
> >
> >
> > At 04:33 PM 12/14/2001, Fong Liaw wrote:
> >
> > >Lou
> > >
> > >I am happy to see my interest protected, however
> > >I think manoj is asking to insert the "optimization
> > >vs. correctness" text into the draft. Right now,
> > >-07 text says a node with higher node id MUST send
> > >a PathErr etc. this does not allow for different
> > >behavior.
> > >
> > >I would suggest to change the text slightly as
> > >following:
> > >
> > >"To resolve contention, the node with the higher node
> > >ID will
> > >    win the contention and it MUST issue a
> > >    ^^^ resolve
> > >PathErr/NOTIFICATION message
> > >^^^^^^^PathErr/Path/Notification
> > >    with a "Routing problem/Label allocation failure"
> > >indication.  "
> > >                ^ for the LSP that loses in the
> > >resolution.
> > >
> > >We can also specify the default behavior is that
> > >"the LSP requested by a higher node id wins the
> > >resolution."
> > >
> > >Regards,
> > >-Fong
> > >
> > > > > >
> > > > > >7. There is an example scenario for contention
> > > > resolution in case of bi-
> > > > > >directional LSPs. It should be mentioned that  :
> > > > > >
> > > > > >"contention resolution is an optimization, not a
> > > > correctness issue ...
> > > > > >and no procedure can provide optimal resolution
> > > > in all cases. An
> > > > > >implementor
> > > > > >may do differently to provide better resolution."
> > > > > >
> > > > > >The above quotes are extracted from one of the
> > > > mails from Fong Liaw.
> > > > > >
> > > > > >If this is the case then this should be mentioned
> > > > in the drafts.
> > > > > >
> > > >
> > > > Read the Acknowledgments section of the draft.  (I'm
> > > > sure Fong will be
> > > > happy to see you protecting her interests!)
> > > >
> > >
> > >__________________________________________________
> > >Do You Yahoo!?
> > >Check out Yahoo! Shopping and Yahoo! Auctions for all of
> > >your unique holiday gifts! Buy at
> > ><<http://shopping.yahoo.com>http://shopping.yahoo.com>http://shopping.y 
> ahoo.com
> > >or bid at 
> <<http://auctions.yahoo.com>http://auctions.yahoo.com>http://auctions.yahoo.com 
>
> >
>
>_________________________________________________________
>
>Do You Yahoo!?
>
>Get your free @yahoo.com address at 
><http://mail.yahoo.com>http://mail.yahoo.com
>

Delivery-date: Wed, 19 Dec 2001 06:02:58 -0800
Cc: [email-masked]
Date: Wed, 19 Dec 2001 14:24:54 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: "Mannie, Eric" <[email-masked]>
Original-CC: [email-masked]
Subject: protection and restoration [was: Re: Moving right along ...  generalized-signaling-06]

This is a multi-part message in MIME format.
--------------85E34B708726E670AEA44156
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Eric,

One of the requirements we have to meet is that traffic of user A is not
delivered to user B. Also during recovery from a failed connection (either by
means of protection swithcing, or restoration) we have to guarantee that user A
traffic is not delivered to user B. This adds additional requirements to the
operation of the 1:1/ET (with extra traffic), 1:n, 1:n/ET, etc architectures;
these have a potential to temporarily connect A to B.

In protection switching this is guaranteed by means of the combination of
protection architecture and protection switching protocol type (1-phase,
2-phase, 3-phase protocols). 
The tail end normal output #i of the protected domain will never select from the
protection connection until it is guaranteed that normal input #i at the head
end is bridged onto this protection connection. And vice versa, the tail end
will deselect the protection connection before the head end will put a different
signal onto that protection connection.

I assume that for the case of restoration and fast restoration, the same
requirement is applicable. Has this requirement been considered in the work on
fast restoration?

It looks like "fast restoration" is a control plane based protection switching.
Is my understanding correct?

If so, with transport plane based protection switching build into SDH/SONET and
OTN, is fast restoration being a pre-OTN feature? I assume there is no need to
replace SDH/SONET/OTN transport plane based protection switching by control
plane based protection switching.
As pre-OTN (STM/OC-N or GE over WDM) doesn't have any protection switching
defined in the transport plane, pre-OTN has no alternative to control plane
based protection.

Regards,

Maarten

"Mannie, Eric" wrote:
> 
> Hello Stephen,
> 
> John refers to fast restoration schemes that are being studied at the IETF.
> Such schemes are widely implemented in the new classes of optical/TDM
> equipments.
> 
> The wording of the text just need to use the terms "working" LSP and
> "protecting" LSP, instead of primary and secondary. That's just an editing
> modification.
> 
> The bit itself is useful to qualify the LSP being established.
> 
> The mechanisms to be applied to this qualification will be detailed in other
> documents.
> 
> In the mean time, I guess that this bit can be used by implementations for a
> simple restoration scheme (e.g. first establish working and protecting LSPs,
> resources of protecting LSP may be "soft reserved", i.e. for extra-traffic,
> when a fault occur send an RSVP-TE rapid failure notification to the source,
> send Path with bit set to "working" on protecting LSP, this kills all LSPs
> using these resources, when acked switch to this LSP).
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Tuesday, December 18, 2001 7:38 PM
> To: John Drake
> Cc: Maarten Vissers; [email-masked]
> Subject: Re: Moving right along ... generalized-signaling-06
> 
> John,
> The problem here is that this is not compatible with transport plane
> protection.
> Assume you do 1:n MSP protection according to ITU Rec. G.841. The operation
> of
> the protection group is controlled by exchange of the K1, K2 bytes in the
> MSOH of the PROTECTION MS. If the control plane reuses the protection MS at
> for a different LSP at a time when the state of the protection group is
> "No Request" (assuming no extra traffic carried on the protection section in
> the
> transport plane), this disables the protection since the endpoints of the
> protection group are no longer able to exchange K1, K2 over the protection
> channel. Even though the payload is unused and irrelevant to the transport
> plane at this point, the exchange of overhead is essential to proper
> operation
> of the protection group.
> Regards,
> Steve
> 
> John Drake wrote:
> >
> > Steven,
> >
> > The basic idea is that if a connection is of type 'secondary', then other
> > LSPs of type 'primary' between the same or different source/destination
> > pairs MAY use its resources in intermediate nodes, until that LSP is
> > converted into a 'primary' with a subsequent Path/Resv flow.  At this
> point,
> > other LSPs that were using its resources may get pre-empted.  Think of the
> > primary/secondary mechanism as a way to ensure temporal priority while
> > allowing network resources to be re-used; i.e., an LSP of type 'secondary'
> > is carrying no data.
> >
> > So in the 1:1 case the protect LSP could be established either as a
> primary
> > or secondary LSP, while in the 1:N case the protect LSP would be
> established
> > as a secondary.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:[email-masked]]
> > Sent: Thursday, December 13, 2001 12:15 PM
> > To: John Drake
> > Cc: Maarten Vissers; [email-masked]
> > Subject: Re: Moving right along ... generalized-signaling-06
> >
> > John,
> > It would seem from this standpoint, ANY transport plane protection
> > must use "primary" for all trails. You have already made this argument
> > for the 1+1 case to carry the permanently bridged copy of the payload.
> >
> > In 1:1 or 1:n, when protection is not being used to carry one/any of
> > the normal traffic signals, it may either carry a null signal (no bridge)
> > or transport plane extra traffic. Even if the transport plane has only
> > a null signal on protection, the control plane cannot itself place extra
> > traffic on any portion of the end-to-end protection channel as this is
> > where the APS protocol is carried to coordinate the 1:1 or 1:n protection.
> > The protection channel overhead is chosen to carry the APS since it is
> > necessary to exchange APS bytes to complete a switch when working channels
> > are failed. If the protection channel has failed and APS cannot be
> > exchanged,
> > normal traffic signals will not be selected from protection.
> > Regards,
> > Steve
> >
> > John Drake wrote:
> > >
> > > Maarten,
> > >
> > > That's fine, however it's beside the point.  The semantics of
> > > Primary/Secondary refer to the control plane and whether the node
> > > establishing a given LSP is planning to use it at the time it's
> > established
> > > or at a later time.  As I indicated in an earlier note, 1+1 transport
> > plane
> > > protection would be accomplished in the control plane by establishing
> two
> > > LSPs of type Primary.  The control plane really doesn't care which LSP
> the
> > > transport plane is using as Working and which as Protect, although that
> > > information is available to the control plane at the LSP endpoints.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Maarten Vissers [mailto:[email-masked]]
> > > Sent: Thursday, December 13, 2001 12:15 AM
> > > To: [email-masked]
> > > Subject: Re: Moving right along ... generalized-signaling-06
> > >
> > > There exist well defined protection terminology in ITU-T for the
> transport
> > > plane. "Working" and "Protection" are being used and not
> > primary/secondary.
> > > E.g.
> > > a 1+1 architecture has one working connection, one protection connection
> > and
> > > a
> > > permanent bridge.
> > >
> > > Besides working/protection indication for the transport entity, there is
> > > - "active" and "standby" to indicate if the signal is selected from the
> > > working
> > > or protection transport entity; i.e. if selector selects from working,
> the
> > > working is active and protection is standby, if the selector selects
> from
> > > protection the working is standby and the protection is active.
> > > - "normal" and "extra traffic" signal. The normal signal is protected.
> > >
> > > Regards,
> > >
> > > Maarten
> > >
> > > [email-masked] wrote:
> > > >
> > > > Jonathan....review the text below....I think the problem is 1:1.
> > > >
> > > > neil
> > > >
> > > > > -----Original Message-----
> > > > > From: Jonathan Lang [mailto:[email-masked]]
> > > > > Sent: 12 December 2001 17:46
> > > > > To: 'Ben Mack-Crane'; John Drake
> > > > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > > > Subject: RE: Moving right along ... generalized-signaling-06
> > > > >
> > > > >
> > > > > Ben,
> > > > >   Please see inline.
> > > > >
> > > > > Thanks,
> > > > > Jonathan
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > > > Sent: Wednesday, December 12, 2001 8:56 AM
> > > > > > To: John Drake
> > > > > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > > > >
> > > > > >
> > > > > > See comment below.
> > > > > >
> > > > > > Regards,
> > > > > > Ben
> > > > > >
> > > > > > John Drake wrote:
> > > > > > >
> > > > > > > Snipped
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > > > > Sent: Tuesday, December 11, 2001 6:38 AM
> > > > > > > To: Lou Berger
> > > > > > > Cc: Kireeti Kompella; [email-masked]
> > > > > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >7) In Protection Information it states "The resources
> > > > > > allocated for a
> > > > > > > > >    secondary LSP MAY be used by other LSPs until the
> > > > > > primary LSP fails
> > > > > > > > >    over to the secondary LSP."  This may not always be
> > > > > > the case.  An
> > > > > > > > >    explicit flag indicating whether or not extra
> > > > > > traffic may use the
> > > > > > > > >    secondary path resources is needed.
> > > > > > > >
> > > > > > > > ??? This is the purpose of this bit.
> > > > > > >
> > > > > > > This is not clear from the definition.  The bit is defined
> > > > > > as indicating
> > > > > > > the LSP is a secondary (or protecting) LSP and in 1+1
> > > > > protection the
> > > > > > > secondary LSP may not be used for extra traffic.
> > > > > > >
> > > > > > > Perhaps the problem here is that protection features are
> > > > > > being defined
> > > > > > > before the protection framework and requirements are
> > > > > done.  Is this
> > > > > > > presupposing some particular outcome of the recovery work in
> CAMP?
> > > > > > >
> > > > > > > JD:  I think the definition of the bit is fine.  For both
> > > > > > 1+1 and 1:1
> > > > > > > protection, there would be a pair of Primary LSPs between
> > > > > the source
> > > > > > > and destination, rather than a Primary and a Secondary.
> > > > > >
> > > > > > This is an unusual use of terms.  I have never encountered a case
> > > > > > where both the working and recovery paths are call "primary."
> > > > > >
> > > > > > This is not consistent with either draft-mpls-recovery-framework
> > > > > > or with draft-lang-ccamp-recovery.  I think this is a sign that
> the
> > > > > > protection work is immature and not ready for progressing to RFC.
> > > > > >
> > > > > For 1+1 path protection, both working/recovery paths are
> > > > > carrying user data
> > > > > traffic and it is an endpoint decision as to which path is
> > > > > actually the
> > > > > working/recovery path.  At a transit node, both paths need to
> > > > > be treated as
> > > > > primary, as the resources are currently being used and
> > > > > obviously can't be
> > > > > used for Extra Traffic.
> > > > >
--------------85E34B708726E670AEA44156
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------85E34B708726E670AEA44156--

Delivery-date: Wed, 19 Dec 2001 01:19:51 -0800
Date: Wed, 19 Dec 2001 10:14:05 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

This is a multi-part message in MIME format.
--------------6BA58095FEA1B65CE1735158
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

All,

Zhi-Wei Lin wrote:
> 
> Hi,
> 
> I think active/standby and extra-traffic/normal-traffic are also two
> separate descriptors. 

They are indeed separate descriptors. See e.g. draft G.gps.

> Extra traffic may be carried on a standby connection (but a standby 
> connection does not necessarily have extra traffic on it).

Correct. 1+1 prot architecture can't even support extra traffic.
E.g. 1:1 and 1:n architectures can support extra traffic. As a 1:1 architecture
is more complex than a 1+1 scheme, such 1:1 architecture will typically be
deployed when extra traffic support is required. See for
advantages/disadvantages associated with each protection architecture section
6.2 of draft G.gps:

Possible advantages of the 1+1 architecture include:
1) low complexity.
2) for the case of unidirectional switching, the possibility to support dual
node interconnect of protected subnetworks.

Possible disadvantages of the 1+1 architecture include:
3) 100% extra capacity.

Possible advantages of the 1:n, m:n, (1:1)n architecture include:
1) possibility to provide protection access; the protection transport
entity/bandwidth can transport an extra traffic signal during periods the
protection transport entity/bandwidth is not required to transport a normal
traffic signal.
2) extra capacity restricted to 100/n % or m x 100/n %
3) for case of m:n, protection is possible for up to m faults.

Possible disadvantages of the 1:n, m:n, (1:1)n architecture include:
4) complexity.
5) for case of SNC protection class, the need for additional sublayer
termination functions at ingress and egress points of the protected domain on
each working and protection transport entity.
6) does not support dual node interconnect of protected subnetworks.
7) n >= 2: each of the n working transport entities must be routed via different
facilities and equipment to prevent the existence of common points of failure
that can not be protected by the single protection transport entity in a 1:n and
(1:1)n architecture. 

NOTE:	Typically, n+1 alternative paths between two nodes in the network will not
be available. As such, 1:n and (1:1)n, with n >= 2, architectures will not
provide adequate protection for the n normal signals transported normally via
the n working transport entities. n = 1 seems the only reasonable choice.

NOTE:	In ATM, protection access is not explicitly required to allow usage of the
normally unused protection bandwidth; ABR and UBR traffic could use this
protection bandwidth by means of a over-subscription of the bandwidth of the
server signal containing the protection transport entity. The ABR/UBR higher
layer control mechanism is assumed to reduce the traffic when the protection is
actually used. The ingress/egress nodes of the protection domain do not have to
align with ingress/egress nodes of ABR/UBR traffic. This adds flexibility to the
network, and reduces complexity.

> 
> How do we define normal traffic? Is this user traffic carried by working
> path (when working is active), or also carried by recovery path (when
> recovery is active)?

Normal traffic signal is defined as follows (see G.gps):

3.10.1	Normal traffic signal - Traffic signal that is protected by two
alternative transport entities, called working and protection entities.

3.10.2	Extra traffic signal - Traffic signal that is carried over the protection
transport entity and/or bandwidth when that transport entity/bandwidth is not
being used for the protection of a normal traffic signal; i.e. when protection
transport entity is standby. Whenever the protection transport entity/bandwidth
is required to protect or restore the normal traffic on the working entity, the
extra traffic is pre-empted. Extra traffic is not protected.

3.10.3	Null signal - The null signal is indicated on the protection transport
entity if it is not used to carry normal or extra traffic. The null signal can
be any kind of signal that conforms to the signal structure of the specific
layer and is ignored (not selected) at the tail end of the protection.

> 
> And once you defined these, I think you still may need to specify
> whether a connection is revertive or non-revertive.

Revertive and non-revertive are protection "operation types".

> 
> For example, take the case of 1+1. One operator may decide to use
> non-revertive (because both paths are "equivalent") so avoid a switching
> hit on the traffic (order of milliseconds?), while another operator may
> decide to use revertive (because the recovery path is much longer/more
> hops). 

Section 6.4/G.gps lists 5 cases where revertive operation may be appropriate:

1) Where parts of the protection transport entity may be taken to provide
capacity to meet a more urgent need.  For example, where protection transport
entity can be taken out of service to release capacity for use in restoring
other traffic.
2) Where the protection transport entity may be subject to frequent
re-arrangement.  For example, where a network has limited capacity and
protection routes are frequently re-arranged to maximize network efficiency when
changes occur in the network.
3) Where the protection transport entity is of significantly lower performance
than the working transport entity.  For example, where the protection transport
entity has a worse error performance or longer delay than the working transport
entity.
4) When an operator needs to know which transport entities are carrying normal
traffic in order to simplify the management of the network.
5) Where dual node interconnect mechanism is applied to reliably interconnect
two protected subnetworks. 

> Could these decisions be made per protected LSP basis? 

Yes.

> If yes, then would tail-end need to know which mode it is operating/to
> use (the intermediate nodes don't need to know this)?

For the case of 1+1 architecture with "uni-directional switching" (switching
type is another parameter) only the tail end needs to know the operation type.
For a bi-directional connection, each tail end needs to know its operation
type... in principle one direction can use non-revertive whereas the other
direction can use revertive... but this is not logical, so default is to have
both tail ends operating with the same operation type.

For 1+1/1:n "bi-directional switching" both head end and tail ends need to know
operation type, and the operation type must be the same at both ends.
Intermediate nodes don't need to know about any of those protection parameters.
Those protection parameters are allocated to the protection processes at the
edge of the protected domain. See also figure 3 in section 3.2 in VBI
contribution D.301 (SG15, Oct. 2001).

Regards,

Maarten

> 
> Zhi
> 
> Ben Mack-Crane wrote:
> 
> > Maarten,
> >
> > In the work on a recovery framework for mpls (draft-ietf-mpls-recovery-frmwrk-03.txt)
> > we chose "working path" and "recovery path."  We used "recovery" instead of "protection"
> > because it seemed a more neutral term given that we were including both protection
> > switching and reroute recovery mechanisms.
> >
> > We did not address the state (active/standby).  We use the terms "extra traffic" and
> > "working traffic" (perhaps the latter could be changed to "normal traffic").
> >
> > It would be useful in moving forward in CCAMP if we could try to adopt terms
> > that are consistent with those in current use elsewhere.
> >
> > Regards,
> > Ben
> >
> > Maarten Vissers wrote:
> >
> >>There exist well defined protection terminology in ITU-T for the transport
> >>plane. "Working" and "Protection" are being used and not primary/secondary. E.g.
> >>a 1+1 architecture has one working connection, one protection connection and a
> >>permanent bridge.
> >>
> >>Besides working/protection indication for the transport entity, there is
> >>- "active" and "standby" to indicate if the signal is selected from the working
> >>or protection transport entity; i.e. if selector selects from working, the
> >>working is active and protection is standby, if the selector selects from
> >>protection the working is standby and the protection is active.
> >>- "normal" and "extra traffic" signal. The normal signal is protected.
> >>
> >>Regards,
> >>
> >>Maarten
> >>
> >>[email-masked] wrote:
> >>
> >>>Jonathan....review the text below....I think the problem is 1:1.
> >>>
> >>>neil
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: Jonathan Lang [mailto:[email-masked]]
> >>>>Sent: 12 December 2001 17:46
> >>>>To: 'Ben Mack-Crane'; John Drake
> >>>>Cc: Lou Berger; Kireeti Kompella; [email-masked]
> >>>>Subject: RE: Moving right along ... generalized-signaling-06
> >>>>
> >>>>
> >>>>Ben,
> >>>>  Please see inline.
> >>>>
> >>>>Thanks,
> >>>>Jonathan
> >>>>
> >>>>
> >>>>>-----Original Message-----
> >>>>>From: Ben Mack-Crane [mailto:[email-masked]]
> >>>>>Sent: Wednesday, December 12, 2001 8:56 AM
> >>>>>To: John Drake
> >>>>>Cc: Lou Berger; Kireeti Kompella; [email-masked]
> >>>>>Subject: Re: Moving right along ... generalized-signaling-06
> >>>>>
> >>>>>
> >>>>>See comment below.
> >>>>>
> >>>>>Regards,
> >>>>>Ben
> >>>>>
> >>>>>John Drake wrote:
> >>>>>
> >>>>>>Snipped
> >>>>>>
> >>>>>>-----Original Message-----
> >>>>>>From: Ben Mack-Crane [mailto:[email-masked]]
> >>>>>>Sent: Tuesday, December 11, 2001 6:38 AM
> >>>>>>To: Lou Berger
> >>>>>>Cc: Kireeti Kompella; [email-masked]
> >>>>>>Subject: Re: Moving right along ... generalized-signaling-06
> >>>>>>
> >>>>>>
> >>>>>>>>7) In Protection Information it states "The resources
> >>>>>>>>
> >>>>>allocated for a
> >>>>>
> >>>>>>>>   secondary LSP MAY be used by other LSPs until the
> >>>>>>>>
> >>>>>primary LSP fails
> >>>>>
> >>>>>>>>   over to the secondary LSP."  This may not always be
> >>>>>>>>
> >>>>>the case.  An
> >>>>>
> >>>>>>>>   explicit flag indicating whether or not extra
> >>>>>>>>
> >>>>>traffic may use the
> >>>>>
> >>>>>>>>   secondary path resources is needed.
> >>>>>>>>
> >>>>>>>??? This is the purpose of this bit.
> >>>>>>>
> >>>>>>This is not clear from the definition.  The bit is defined
> >>>>>>
> >>>>>as indicating
> >>>>>
> >>>>>>the LSP is a secondary (or protecting) LSP and in 1+1
> >>>>>>
> >>>>protection the
> >>>>
> >>>>>>secondary LSP may not be used for extra traffic.
> >>>>>>
> >>>>>>Perhaps the problem here is that protection features are
> >>>>>>
> >>>>>being defined
> >>>>>
> >>>>>>before the protection framework and requirements are
> >>>>>>
> >>>>done.  Is this
> >>>>
> >>>>>>presupposing some particular outcome of the recovery work in CAMP?
> >>>>>>
> >>>>>>JD:  I think the definition of the bit is fine.  For both
> >>>>>>
> >>>>>1+1 and 1:1
> >>>>>
> >>>>>>protection, there would be a pair of Primary LSPs between
> >>>>>>
> >>>>the source
> >>>>
> >>>>>>and destination, rather than a Primary and a Secondary.
> >>>>>>
> >>>>>This is an unusual use of terms.  I have never encountered a case
> >>>>>where both the working and recovery paths are call "primary."
> >>>>>
> >>>>>This is not consistent with either draft-mpls-recovery-framework
> >>>>>or with draft-lang-ccamp-recovery.  I think this is a sign that the
> >>>>>protection work is immature and not ready for progressing to RFC.
> >>>>>
> >>>>>
> >>>>For 1+1 path protection, both working/recovery paths are
> >>>>carrying user data
> >>>>traffic and it is an endpoint decision as to which path is
> >>>>actually the
> >>>>working/recovery path.  At a transit node, both paths need to
> >>>>be treated as
> >>>>primary, as the resources are currently being used and
> >>>>obviously can't be
> >>>>used for Extra Traffic.
> >>>>
> >>>>
> >
--------------6BA58095FEA1B65CE1735158
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------6BA58095FEA1B65CE1735158--

Delivery-date: Wed, 19 Dec 2001 00:42:08 -0800
Cc: [email-masked]
Date: Wed, 19 Dec 2001 09:39:07 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Ben Mack-Crane <[email-masked]>
Original-CC: [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

This is a multi-part message in MIME format.
--------------F4686F4EFA632F5479589A26
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ben,

GMPLS is a control plane with the intention to perform a connection management
role for the transport plane. Protection is a transport plane build in feature,
and it would certainly be wise that GMPLS uses the same terminology as the
transport plane. It will definitely reduce the amount of misunderstanding and
thus interworking problems.

A major difference between protection and restoration is that protection makes
use of pre-assigned capacity between nodes, whereas restoration makes use of any
capacity available between nodes. I.e. this latter capacity is not typically
pre-assigned to a particular connection.

Therefore, it is better to have terminology associated with those differences.
I.e. for protection "working" and "protection" connections and "normal" and
"extra traffic" signals are applicable and should be used. For restoration there
is only one connection active at any time, so the working/protection doesn't
apply here... I do not have terminology yet, I can only offer some
suggestions...

Before there is a signal fail condition in the network, all traffic is
transported over one connection between ingress and egress points of the
network. What is the terminology we use for such connections? E.g. "normal
connection" or just "connection"?

Some of the unused (G.805) link capacity and fabric capacity may be reserved for
rerouting of the normal signals when their transport is interrupted.

When a signal fail condition exists, alternate connections or connection
segments are to be computed and set up after which the original connection or
connection segment is released. At this point there is just one connection
present... i.e. the normal connection or just the connection.

So we need terminology to identify the alternate connection (segment), which
exists as alternate connection (segment) for the period up to the release of the
original connection (segment). I.e. it is a temporary indication, and thus more
like a state. So perhaps "alternate" and "original" connection (segment) are the
appropriate terms to use to indicate the temporary states assigned to existing
interrupted connection (segment) and its replacement.

Regards,

Maarten
PS. the term "path" is a reserved term in the transport plane. A "path" is a
"trail in a path layer network". Restoration typically implies the replacement
of one (serial compound) link connection by another (serial compound) link
connection. Restoration doesn't replace trails.

Ben Mack-Crane wrote:
> 
> Maarten,
> 
> In the work on a recovery framework for mpls (draft-ietf-mpls-recovery-frmwrk-03.txt)
> we chose "working path" and "recovery path."  We used "recovery" instead of "protection"
> because it seemed a more neutral term given that we were including both protection
> switching and reroute recovery mechanisms.
> 
> We did not address the state (active/standby).  We use the terms "extra traffic" and
> "working traffic" (perhaps the latter could be changed to "normal traffic").
> 
> It would be useful in moving forward in CCAMP if we could try to adopt terms
> that are consistent with those in current use elsewhere.
> 
> Regards,
> Ben
> 
> Maarten Vissers wrote:
> >
> > There exist well defined protection terminology in ITU-T for the transport
> > plane. "Working" and "Protection" are being used and not primary/secondary. E.g.
> > a 1+1 architecture has one working connection, one protection connection and a
> > permanent bridge.
> >
> > Besides working/protection indication for the transport entity, there is
> > - "active" and "standby" to indicate if the signal is selected from the working
> > or protection transport entity; i.e. if selector selects from working, the
> > working is active and protection is standby, if the selector selects from
> > protection the working is standby and the protection is active.
> > - "normal" and "extra traffic" signal. The normal signal is protected.
> >
> > Regards,
> >
> > Maarten
> >
> > [email-masked] wrote:
> > >
> > > Jonathan....review the text below....I think the problem is 1:1.
> > >
> > > neil
> > >
> > > > -----Original Message-----
> > > > From: Jonathan Lang [mailto:[email-masked]]
> > > > Sent: 12 December 2001 17:46
> > > > To: 'Ben Mack-Crane'; John Drake
> > > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > > Subject: RE: Moving right along ... generalized-signaling-06
> > > >
> > > >
> > > > Ben,
> > > >   Please see inline.
> > > >
> > > > Thanks,
> > > > Jonathan
> > > >
> > > > > -----Original Message-----
> > > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > > Sent: Wednesday, December 12, 2001 8:56 AM
> > > > > To: John Drake
> > > > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > > >
> > > > >
> > > > > See comment below.
> > > > >
> > > > > Regards,
> > > > > Ben
> > > > >
> > > > > John Drake wrote:
> > > > > >
> > > > > > Snipped
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > > > Sent: Tuesday, December 11, 2001 6:38 AM
> > > > > > To: Lou Berger
> > > > > > Cc: Kireeti Kompella; [email-masked]
> > > > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >7) In Protection Information it states "The resources
> > > > > allocated for a
> > > > > > > >    secondary LSP MAY be used by other LSPs until the
> > > > > primary LSP fails
> > > > > > > >    over to the secondary LSP."  This may not always be
> > > > > the case.  An
> > > > > > > >    explicit flag indicating whether or not extra
> > > > > traffic may use the
> > > > > > > >    secondary path resources is needed.
> > > > > > >
> > > > > > > ??? This is the purpose of this bit.
> > > > > >
> > > > > > This is not clear from the definition.  The bit is defined
> > > > > as indicating
> > > > > > the LSP is a secondary (or protecting) LSP and in 1+1
> > > > protection the
> > > > > > secondary LSP may not be used for extra traffic.
> > > > > >
> > > > > > Perhaps the problem here is that protection features are
> > > > > being defined
> > > > > > before the protection framework and requirements are
> > > > done.  Is this
> > > > > > presupposing some particular outcome of the recovery work in CAMP?
> > > > > >
> > > > > > JD:  I think the definition of the bit is fine.  For both
> > > > > 1+1 and 1:1
> > > > > > protection, there would be a pair of Primary LSPs between
> > > > the source
> > > > > > and destination, rather than a Primary and a Secondary.
> > > > >
> > > > > This is an unusual use of terms.  I have never encountered a case
> > > > > where both the working and recovery paths are call "primary."
> > > > >
> > > > > This is not consistent with either draft-mpls-recovery-framework
> > > > > or with draft-lang-ccamp-recovery.  I think this is a sign that the
> > > > > protection work is immature and not ready for progressing to RFC.
> > > > >
> > > > For 1+1 path protection, both working/recovery paths are
> > > > carrying user data
> > > > traffic and it is an endpoint decision as to which path is
> > > > actually the
> > > > working/recovery path.  At a transit node, both paths need to
> > > > be treated as
> > > > primary, as the resources are currently being used and
> > > > obviously can't be
> > > > used for Extra Traffic.
> > > >
--------------F4686F4EFA632F5479589A26
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------F4686F4EFA632F5479589A26--

Delivery-date: Wed, 19 Dec 2001 00:09:25 -0800
Cc: "[email-masked]'" <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked], [email-masked], [email-masked]
Date: Wed, 19 Dec 2001 09:04:43 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: "Mannie, Eric" <[email-masked]>
Original-CC: "[email-masked]'" <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: GMPLS signaling documents updated per last calls

This is a multi-part message in MIME format.
--------------B7B3EC8D37E3A20AD0A18BEF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Eric,

It is not the intention to leave the choice of LSP encoding type and SU label
structure to the vendor. This would give immediate interworking problems.

VC-11/VT1.5, VC-12/VT-2, VC-2/VT-6, VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c,
VC-4-16c/STS-48c, VC-4-64c/STS-192c and VC-4-256c/STS-768c must all have LSP
encoding type "SDH". Also STS-1/STM-0 upto STM-256/STS-768 must have the LSP
encoding type "SDH".

VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, VC-4-16c/STS-48c, VC-4-64c/STS-192c
and VC-4-256c/STS-768c must all have the same SDH-based "SU" structure. 

Looking at the label text in section 3 of the sonet-sdh document, I find it very
confusing to read that SONET doesn't use the "U" field. As we indicated before
there is no STS type signal that isn't having an SDH equivalent; i.e. there are
no specific higher order SONET signals left. It is therefore much better to take
out the SONET text for the SU label part altogether. Otherwise we will get a lot
of confusion in the marketplace.

Also the examples with STS-1 (examples 3 to 5 in secton 3) must use the label
with U in the range 2 to 4; the STS-1 is equivalent to the VC-3 in SDH and must
thus use the "SDH" SU format.

-------

All,

With the clarification on VT-3 given by Deborah, I would request to consider a
further simplification of the GMPLS standard: delete the LSP encoding type
"SONET" and rename the LSP encoding type "SDH" into "SDH/SONET". Then there
would be no ambiguity left at all.

Regards,

Maarten

"Mannie, Eric" wrote:
> 
> Hi Jonathan,
> 
> > Why SHOULD and not MUST?  This ambiguity is likely to create
> interoperability problems in the future...
> 
> To leave to the manufacturer and to the user the right to decide if he/she
> wants to signal an LSP as either SDH or SONET. There is no interoperability
> problem at all since you use EITHER SDH OR SONET. If you decide to request
> an SDH signal with what do you want to have interoperability issue at this
> stage ? The sentence means indeed "one should better use SDH than SONET" !
> Once you decided, there is no issue.
> 
> > I'm curious what sort of backward compatability is necessary, as a
> "standard" doesn't exist currently that this needs to be backward
> compatible with...
> 
> Backward compatibility with the OIF UNI 1.0 Implementation Agreement, with
> the implementations that could not care of SDH, with implementations that
> still do a distinction between SONET and SDH for some reasons, with the
> implementations that could still use the VT3 (DS1C) (I don't have
> confirmation that nobody is using it today, and this is not the goal of this
> draft to state what is obsolete or not in SONET), etc.
> 
> Anyway, there is no issue, the SONET label format is not used until SONET is
> explicitly requested as such. This is not a primary feature of the draft,
> but a *secondary feature*, for SONET lovers. Otherwise, SDH is used for
> everything, consequently you don't care of the SONET label, you skip it in
> the draft, you ignore it, you don't implement it and you just use a full SDH
> implementation.
> 
> I think that the solution is quite simple: if the SONET signal is indeed an
> SDH signal, why do you bother with SONET ? Just ask for an SDH signal,
> that's all.
> 
> By the way, since according to some folks SONET is just a subset of SDH, why
> do we care about SONET in these documents ? Why don't we simply remove all
> references to SONET ?
> 
> Is there somebody on this mailing list that cares about SONET ? If yes, why
> ? Who is still manufacturing SONET boxes ? Why is that not called SDH ?
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Jonathan Sadler [mailto:[email-masked]]
> Sent: Tuesday, December 18, 2001 9:57 PM
> To: Mannie, Eric
> Cc: 'Stephen Trowbridge'; Kireeti Kompella; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: GMPLS signaling documents updated per last calls
> 
> Eric -
> 
> Comments inline...
> 
> Jonathan Sadler
> 
> "Mannie, Eric" wrote:
> > "A SONET signal which has an identical SDH signal SHOULD be requested
> using
> > the same traffic parameters as for the equivalent SDH signal, and will
> > consequently use the SDH label."
> 
> Why SHOULD and not MUST?  This ambiguity is likely to create
> interoperability problems in the future...
> 
> > We spend with Maarten a lot of time to write that sentence (not easy to
> > write).
> >
> > Maybe that it should be better written:
> >
> > "A SONET signal which has an identical SDH signal SHOULD be requested as
> an
> > SDH signal using the same traffic parameters as for the equivalent SDH
> > signal, and will consequently use the SDH label."
> 
> Again, "SHOULD" needs to be replaced with "MUST"...
> 
> > This doesn't mean that the SONET signal format disappear (simply not used
> in
> > that case), for backward compatibility we need to keep it.
> 
> I'm curious what sort of backward compatability is necessary, as a
> "standard" doesn't exist currently that this needs to be backward
> compatible with...
> 
> > Kind regards,
> >
> > Eric
> >
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:[email-masked]]
> > Sent: Tuesday, December 18, 2001 7:46 PM
> > To: Kireeti Kompella
> > Cc: [email-masked]; [email-masked]; [email-masked];
> > [email-masked]; [email-masked]
> > Subject: Re: GMPLS signaling documents updated per last calls
> >
> > Kireeti,
> > The one outlyer is VT3 (3 Megabits). VC-3 is an extremely popular
> > rate in both SONET and SDH. I exchanged an email with Deborah Brungard
> > (T1X1.5 chair) on this one and I take the liberty of sharing her response:
> >
> > Deborah Brungard wrote:
> > > The VT3 (3M) structure was defined - but no services (mappings) were
> ever
> > defined for it. So there are no services/equip
> > > with it. My take was if in the future it was ever defined (doubtful), we
> > would be adding it to g707 also. So then it
> > > would just be part of g707 too.
> >
> > So basically, there are no mappings or equipment functions for this rate,
> > and as far as we know no network equipment or networks supporting it.
> > Deborah suggests that if we were ever to define such mappings, that this
> > would be proposed for addition to G.707 and hence be part of SDH.
> >
> > I think our agreement had been to use the SDH label for all signals that
> > had the same multiplex structure in SONET and SDH. In Salt Lake City, we
> > thought
> > that this was everything except VT3. Given that VT3 seems not to be a
> "real"
> > signal at this point and will likely be added to SDH if it ever becomes
> > real, does our agreement then become that we use SDH labels for
> everything?
> >
> > Regards,
> > Steve
> >
> > Kireeti Kompella wrote:
> > >
> > > Hi Deborah,
> > >
> > > > I previously made the
> > > > comments to merge the (1) SDH and SONET values as one value
> > >
> > > There was a meeting among Steve Trowbridge, Maarten Vissers,
> > > Eric Mannie, Dimitri Papadimitriou, the CCAMP ADs and chairs on
> > > several issues, among them this one.  The upshot was that whenever
> > > possible, the SDH label should be used, with the encoding type
> > > set to SDH (i.e., G.707); however, there are signals that have
> > > no SDH equivalent (if I remember right, VC-3 -- someone correct
> > > me!), so we will keep SONET labels and encoding types around
> > > for that case and for legacy equipment.
> > >
> > > The revised SONET/SDH document will contain the exact wording.
> > > I will also be sending a reply to the ITU communication stating
> > > the agreement we came to.
> > >
> > > Kireeti.
--------------B7B3EC8D37E3A20AD0A18BEF
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------B7B3EC8D37E3A20AD0A18BEF--

Delivery-date: Tue, 18 Dec 2001 18:28:42 -0800
Reply-To: <[email-masked]>
From: "Fong Liaw" <[email-masked]>
To: "Lou Berger" <[email-masked]>
Cc: "manoj juneja" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Fwd: Comments on GMPLS signalling drafts
Date: Tue, 18 Dec 2001 18:26:14 -0800

Lou

I was not in London, so probably just not being informed.
The proposed change does not create interoperability problem
since there is only one node that would resolves it,
but I have no problem keeping the current text either.  The problem
seems to be that the same question keeps on coming back and 
there are situations where a different resolution will result
in slightly better call setup.  A typical scenario is that
a call coming from network to user has gone a long way and
usually has priority on getting the resources. 

The question we are facing here is whether different
behavior, if does not create interoperability issue,
is allowed. From my read of the draft, it is not ...
Again, I have no problem with current text so you don't
have to convince me, I thought you agree with manoj's
comment and in that case the current text does not
reflect it.

Regards,
-Fong

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Lou Berger
> Sent: Tuesday, December 18, 2001 3:22 PM
> To: Fong Liaw
> Cc: Berger, Lou; manoj juneja; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: Fwd: Comments on GMPLS signalling drafts
> 
> 
> Fong,
>          As you know, we've discussed this many times.  The last time it 
> was discussed in detail (London if memory serves) my memory is that we 
> decided to keep current working as is because (a) different vendor 
> approaches can lead to interoperability issues and (b) this is a common 
> tie-breaker solution.
> 
> Lou
> 
> 
> At 04:33 PM 12/14/2001, Fong Liaw wrote:
> 
> >Lou
> >
> >I am happy to see my interest protected, however
> >I think manoj is asking to insert the "optimization
> >vs. correctness" text into the draft. Right now,
> >-07 text says a node with higher node id MUST send
> >a PathErr etc. this does not allow for different
> >behavior.
> >
> >I would suggest to change the text slightly as
> >following:
> >
> >"To resolve contention, the node with the higher node
> >ID will
> >    win the contention and it MUST issue a
> >    ^^^ resolve
> >PathErr/NOTIFICATION message
> >^^^^^^^PathErr/Path/Notification
> >    with a "Routing problem/Label allocation failure"
> >indication.  "
> >                ^ for the LSP that loses in the
> >resolution.
> >
> >We can also specify the default behavior is that
> >"the LSP requested by a higher node id wins the
> >resolution."
> >
> >Regards,
> >-Fong
> >
> > > > >
> > > > >7. There is an example scenario for contention
> > > resolution in case of bi-
> > > > >directional LSPs. It should be mentioned that  :
> > > > >
> > > > >"contention resolution is an optimization, not a
> > > correctness issue ...
> > > > >and no procedure can provide optimal resolution
> > > in all cases. An
> > > > >implementor
> > > > >may do differently to provide better resolution."
> > > > >
> > > > >The above quotes are extracted from one of the
> > > mails from Fong Liaw.
> > > > >
> > > > >If this is the case then this should be mentioned
> > > in the drafts.
> > > > >
> > >
> > > Read the Acknowledgments section of the draft.  (I'm
> > > sure Fong will be
> > > happy to see you protecting her interests!)
> > >
> >
> >__________________________________________________
> >Do You Yahoo!?
> >Check out Yahoo! Shopping and Yahoo! Auctions for all of
> >your unique holiday gifts! Buy at 
> ><http://shopping.yahoo.com>http://shopping.yahoo.com
> >or bid at <http://auctions.yahoo.com>http://auctions.yahoo.com
> 

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Delivery-date: Tue, 18 Dec 2001 16:35:28 -0800
Date: Tue, 18 Dec 2001 18:39:08 -0500
To: "Markus Jork" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: Moving right along ... generalized-rsvp-te-05 
Cc: "Berger, Lou" <[email-masked]>,<[email-masked]>

At 04:39 PM 12/17/2001, Markus Jork wrote:
>But section 2.1 of draft-ietf-mpls-generalized-rsvp-te-06 says:
>
>    A Generalized Label Request object is set by the ingress node,
>    transparently passed by transit nodes, and used by the egress node.

Markus,

You are correct that this text is no longer accurate with respect to the 
switching type parameter.  (It predates the reintroduction of this field.)

I'll update the text.

Thanks,
Lou

Delivery-date: Tue, 18 Dec 2001 16:35:24 -0800
Date: Tue, 18 Dec 2001 19:13:48 -0500
To: "Ben Mack-Crane" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: GMPLS Issue - Switching Type
Cc: "CCAMP" <[email-masked]>

Ben,
         how many times do you want me to restate this?  I'm getting the 
feeling you don't like my response, so you ask the question a different way.

See direct responses below:

Lou

At 11:15 AM 12/18/2001, Ben Mack-Crane wrote:

>In a brief discussion at the IETF meeting I was told that
>Switching Type really is Multiplexing Type

not by me!  This was one person's way of trying to explain this to 
you.  The text doesn't use these words.

>, that is, HOW the
>LSP is to be carried over a link (not what is switched or
>how it is switched).
>
>This raises a set of issues that have not yet been discussed.

It was discussed as part of the original documents.  It was removed and 
then reintroduced to match the routing draft.  I mentioned this to you at 
the IETF and in the text below.

>The first of these is: What problem is this solving?

See text below.

Lou

>Regards,
>Ben Mack-Crane
>
>The following issue raised 10/29/01 has not been addressed:
>
> >Switching Type continues to be ill-defined.  I have heard that the real
> >definition is different from that given in the current drafts.  If the
> >signaling information is not clearly defined and it's use described, we
> >can hardly expect interoperability.
>
>I can't speak for others.  My belief is that there is a very concrete
>definition.   I thought the text in the draft was clear as well, but let me
>try again:
>
>          Switching Type: 8 bits
>
>          Indicates the type of switching that should be performed
>          on a particular link.  This field is needed for links that
>          advertise more than one type of switching capability.
>          This field contains one of the values advertised for the
>          corresponding link in the routing Switching Capability
>          field as defined in [GMPLS-RTG].
>
>In other words, on links where one Switching Capability is advertised
>(which will be all the time for most equipment) Switching Type is set to
>the same value as advertised in routing.  On links where multiple Switching
>Capabilities are advertised, Switching Type is set to the value advertised
>in Switching Capability that matches the type of switching to be performed.
>
>[I'll put the revised text in the next rev...]

Delivery-date: Tue, 18 Dec 2001 16:35:24 -0800
Date: Tue, 18 Dec 2001 18:22:27 -0500
To: "Fong Liaw" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: Fwd: Comments on GMPLS signalling drafts
Cc: "Berger, Lou" <[email-masked]>, "manoj juneja" <[email-masked]>,<[email-masked]>, <[email-masked]>,<[email-masked]>

Fong,
         As you know, we've discussed this many times.  The last time it 
was discussed in detail (London if memory serves) my memory is that we 
decided to keep current working as is because (a) different vendor 
approaches can lead to interoperability issues and (b) this is a common 
tie-breaker solution.

Lou

At 04:33 PM 12/14/2001, Fong Liaw wrote:

>Lou
>
>I am happy to see my interest protected, however
>I think manoj is asking to insert the "optimization
>vs. correctness" text into the draft. Right now,
>-07 text says a node with higher node id MUST send
>a PathErr etc. this does not allow for different
>behavior.
>
>I would suggest to change the text slightly as
>following:
>
>"To resolve contention, the node with the higher node
>ID will
>    win the contention and it MUST issue a
>    ^^^ resolve
>PathErr/NOTIFICATION message
>^^^^^^^PathErr/Path/Notification
>    with a "Routing problem/Label allocation failure"
>indication.  "
>                ^ for the LSP that loses in the
>resolution.
>
>We can also specify the default behavior is that
>"the LSP requested by a higher node id wins the
>resolution."
>
>Regards,
>-Fong
>
> > > >
> > > >7. There is an example scenario for contention
> > resolution in case of bi-
> > > >directional LSPs. It should be mentioned that  :
> > > >
> > > >"contention resolution is an optimization, not a
> > correctness issue ...
> > > >and no procedure can provide optimal resolution
> > in all cases. An
> > > >implementor
> > > >may do differently to provide better resolution."
> > > >
> > > >The above quotes are extracted from one of the
> > mails from Fong Liaw.
> > > >
> > > >If this is the case then this should be mentioned
> > in the drafts.
> > > >
> >
> > Read the Acknowledgments section of the draft.  (I'm
> > sure Fong will be
> > happy to see you protecting her interests!)
> >
>
>__________________________________________________
>Do You Yahoo!?
>Check out Yahoo! Shopping and Yahoo! Auctions for all of
>your unique holiday gifts! Buy at 
><http://shopping.yahoo.com>http://shopping.yahoo.com
>or bid at <http://auctions.yahoo.com>http://auctions.yahoo.com

Delivery-date: Tue, 18 Dec 2001 16:35:20 -0800
Date: Tue, 18 Dec 2001 19:19:00 -0500
To: "Ben Mack-Crane" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: GMPLS Issue - Notify Message
Cc: "CCAMP" <[email-masked]>

Ben,

To be precise your message said:

>Well?  Does anyone else have thoughts on this?

Your previous mail was a statement and a request for comments.  I didn't 
see much support for this on the list.

Please remember the process is about "rough consensus" not individual vetoes.

Lou

At 11:16 AM 12/18/2001, Ben Mack-Crane wrote:

>The following issue raised 10/29/01 has not been addressed:
>
> > > >7) The Notify message is intended to "enable expedited notification of
> > > >    failures," but it relies on the IP layer which may be affected 
> by the
> > > >    failure that the Notify is reporting.  This could defeat the goal
> > > >    of rapid notification.  Without some means of guaranteeing the 
> Notify
> > > >    doesn't have to wait for IP routing convergence to be delivered,
> > > >    it isn't a satisfactory solution.
> > > >

Delivery-date: Tue, 18 Dec 2001 16:35:12 -0800
Date: Tue, 18 Dec 2001 19:00:50 -0500
To: "Ben Mack-Crane" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: GMPLS Issue - Bandwidth Encoding
Cc: "CCAMP" <[email-masked]>,[email-masked]

At 10:59 AM 12/18/2001, Ben Mack-Crane wrote:

>The following issue raised 10/29/01 has not been addressed:

Ben,
         Again, this has something that has been discussed many times.  My 
reading is that we have "rough consensus".

If you disagree, please take it up with the WG chair.

Lou

> > >4) In the "Bandwidth Encoding" section it states "For non-packet LSPs, it
> > >    is useful to define discrete values to identify the bandwidth of the
> > >    LSP."  For SONET/SDH this is unnecessary given the Signal Type is
> > >    provided.  For the other non-packet LSP types (Lambda and Fiber)
> > >    it is not clear that all the values cited in the example are relevant
> > >    (for example, a DS0 lambda would seem wasteful...).
> >
> > >    This is confusing, and should be clarified.  In fact, a 
> description of
> > >    exactly why this field is required is needed.
> >
> > We've gone over this text multiple times.  Do you have any suggested 
> wording.
> >
>
>I would gladly suggest wording if I understood the use for this.  It has 
>no use
>for Packet, PDH, SDH/SONET, or "Digital Wrapper," so I assume it is for 
>Lambda
>or Fiber.  However, several of the examples are not appropriate for this.
>Perhaps this should be moved to a technology specific document since it is
>not really general anyway.

Delivery-date: Tue, 18 Dec 2001 16:35:03 -0800
Date: Tue, 18 Dec 2001 18:57:24 -0500
To: "Ben Mack-Crane" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: GMPLS Issue - Ethernet LSP Enc Type
Cc: "CCAMP" <[email-masked]>

At 10:55 AM 12/18/2001, Ben Mack-Crane wrote:

>The following issue raised 10/29/01 has not been addressed.

I disagree.  We talked in person on this and I said the same thing on the list.

> > >1) There seems to be no difference as far as label allocation
> > >    is concerned between LSP Encoding Types Ethernet V2/DIX (2)
> > >    and Ethernet 802.3 (10).  One Encoding type would seem to
> > >    be sufficient.
> >
> > I agree, but some feel that this is needed to properly establish LSPs in
> > systems what would terminate each type differently.
>
>I don't recall seeing anything on the list about the reasoning about this.
>can someone provide a pointer to where this was described?

As I mentioned at the IETF, it was in private discussions.

>Since LSP Encoding type is intended to describe the LSP for transit nodes
>and G-PID is intended to describe the LSP contents for the purpose of
>terminating it at the ends, information relevant only to termination
>should be conveyed in G-PID.
>
>Perhaps changing the name of this LSP Encoding Type to "Ethernet Phy"
>would make this clearer.

The current wording is what was agreed to.

Lou

Delivery-date: Tue, 18 Dec 2001 15:48:04 -0800
Date: Tue, 18 Dec 2001 16:46:25 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: "Mannie, Eric" <[email-masked]>
CC: Kireeti Kompella <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: GMPLS signaling documents updated per last calls

Eric,
I understand that it took some effort to come up with the sentence to which
everyone agreed. The new information since SLC is, however, that the VT3
SONET format, which we thought was the only unique format to SONET, seems
to have no mappings and is not used. With this new information, would it
be better to have a different sentence?

Certainly there is nothing incorrect the way it is written, but it may be
more helpful to readers to know to just use the SDH labels.
Regards,
Steve

"Mannie, Eric" wrote:
> 
> Hi Stephen,
> 
> The current wording is (as it is written in the updated draft that I sent
> last week on the ccamp mailing list):
> 
> "A SONET signal which has an identical SDH signal SHOULD be requested using
> the same traffic parameters as for the equivalent SDH signal, and will
> consequently use the SDH label."
> 
> We spend with Maarten a lot of time to write that sentence (not easy to
> write).
> 
> Maybe that it should be better written:
> 
> "A SONET signal which has an identical SDH signal SHOULD be requested as an
> SDH signal using the same traffic parameters as for the equivalent SDH
> signal, and will consequently use the SDH label."
> 
> This means in practice: request an SDH signal when identical to a SONET
> signal. In that case, from the control plane point of view everything is
> SDH, i.e. the control plane is not aware of SONET at all. Of course, if an
> SDH signal is requested the SDH label is used. The distinction between SDH
> and SONET in that case being only at the connection monitoring level if I am
> right (please confirm).
> 
> This doesn't mean that the SONET signal format disappear (simply not used in
> that case), for backward compatibility we need to keep it.
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Tuesday, December 18, 2001 7:46 PM
> To: Kireeti Kompella
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: GMPLS signaling documents updated per last calls
> 
> Kireeti,
> The one outlyer is VT3 (3 Megabits). VC-3 is an extremely popular
> rate in both SONET and SDH. I exchanged an email with Deborah Brungard
> (T1X1.5 chair) on this one and I take the liberty of sharing her response:
> 
> Deborah Brungard wrote:
> > The VT3 (3M) structure was defined - but no services (mappings) were ever
> defined for it. So there are no services/equip
> > with it. My take was if in the future it was ever defined (doubtful), we
> would be adding it to g707 also. So then it
> > would just be part of g707 too.
> 
> So basically, there are no mappings or equipment functions for this rate,
> and as far as we know no network equipment or networks supporting it.
> Deborah suggests that if we were ever to define such mappings, that this
> would be proposed for addition to G.707 and hence be part of SDH.
> 
> I think our agreement had been to use the SDH label for all signals that
> had the same multiplex structure in SONET and SDH. In Salt Lake City, we
> thought
> that this was everything except VT3. Given that VT3 seems not to be a "real"
> signal at this point and will likely be added to SDH if it ever becomes
> real, does our agreement then become that we use SDH labels for everything?
> 
> Regards,
> Steve
> 
> Kireeti Kompella wrote:
> >
> > Hi Deborah,
> >
> > > I previously made the
> > > comments to merge the (1) SDH and SONET values as one value
> >
> > There was a meeting among Steve Trowbridge, Maarten Vissers,
> > Eric Mannie, Dimitri Papadimitriou, the CCAMP ADs and chairs on
> > several issues, among them this one.  The upshot was that whenever
> > possible, the SDH label should be used, with the encoding type
> > set to SDH (i.e., G.707); however, there are signals that have
> > no SDH equivalent (if I remember right, VC-3 -- someone correct
> > me!), so we will keep SONET labels and encoding types around
> > for that case and for legacy equipment.
> >
> > The revised SONET/SDH document will contain the exact wording.
> > I will also be sending a reply to the ITU communication stating
> > the agreement we came to.
> >
> > Kireeti.

Delivery-date: Tue, 18 Dec 2001 14:02:06 -0800
From: John Drake <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>
Cc: Maarten Vissers <[email-masked]>, [email-masked]
Subject: RE: Moving right along ... generalized-signaling-06
Date: Tue, 18 Dec 2001 13:56:26 -0800

Stephen,

You're absolutely right if you want to use K1/K2 to signal the switchover
from working to protect.  We were planning to use the control plane
signalling protocols, since we have to deal with more than just SONET/SDH.
See for example: 

http://search.ietf.org/internet-drafts/draft-li-shared-mesh-restoration-01.t
xt

http://search.ietf.org/internet-drafts/draft-bala-protection-restoration-sig
naling-00.txt

Thanks,

John

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Tuesday, December 18, 2001 10:38 AM
To: John Drake
Cc: Maarten Vissers; [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

John,
The problem here is that this is not compatible with transport plane
protection.
Assume you do 1:n MSP protection according to ITU Rec. G.841. The operation
of
the protection group is controlled by exchange of the K1, K2 bytes in the
MSOH of the PROTECTION MS. If the control plane reuses the protection MS at
for a different LSP at a time when the state of the protection group is
"No Request" (assuming no extra traffic carried on the protection section in
the
transport plane), this disables the protection since the endpoints of the
protection group are no longer able to exchange K1, K2 over the protection
channel. Even though the payload is unused and irrelevant to the transport
plane at this point, the exchange of overhead is essential to proper
operation
of the protection group.
Regards,
Steve

John Drake wrote:
> 
> Steven,
> 
> The basic idea is that if a connection is of type 'secondary', then other
> LSPs of type 'primary' between the same or different source/destination
> pairs MAY use its resources in intermediate nodes, until that LSP is
> converted into a 'primary' with a subsequent Path/Resv flow.  At this
point,
> other LSPs that were using its resources may get pre-empted.  Think of the
> primary/secondary mechanism as a way to ensure temporal priority while
> allowing network resources to be re-used; i.e., an LSP of type 'secondary'
> is carrying no data.
> 
> So in the 1:1 case the protect LSP could be established either as a
primary
> or secondary LSP, while in the 1:N case the protect LSP would be
established
> as a secondary.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Thursday, December 13, 2001 12:15 PM
> To: John Drake
> Cc: Maarten Vissers; [email-masked]
> Subject: Re: Moving right along ... generalized-signaling-06
> 
> John,
> It would seem from this standpoint, ANY transport plane protection
> must use "primary" for all trails. You have already made this argument
> for the 1+1 case to carry the permanently bridged copy of the payload.
> 
> In 1:1 or 1:n, when protection is not being used to carry one/any of
> the normal traffic signals, it may either carry a null signal (no bridge)
> or transport plane extra traffic. Even if the transport plane has only
> a null signal on protection, the control plane cannot itself place extra
> traffic on any portion of the end-to-end protection channel as this is
> where the APS protocol is carried to coordinate the 1:1 or 1:n protection.
> The protection channel overhead is chosen to carry the APS since it is
> necessary to exchange APS bytes to complete a switch when working channels
> are failed. If the protection channel has failed and APS cannot be
> exchanged,
> normal traffic signals will not be selected from protection.
> Regards,
> Steve
> 
> John Drake wrote:
> >
> > Maarten,
> >
> > That's fine, however it's beside the point.  The semantics of
> > Primary/Secondary refer to the control plane and whether the node
> > establishing a given LSP is planning to use it at the time it's
> established
> > or at a later time.  As I indicated in an earlier note, 1+1 transport
> plane
> > protection would be accomplished in the control plane by establishing
two
> > LSPs of type Primary.  The control plane really doesn't care which LSP
the
> > transport plane is using as Working and which as Protect, although that
> > information is available to the control plane at the LSP endpoints.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Maarten Vissers [mailto:[email-masked]]
> > Sent: Thursday, December 13, 2001 12:15 AM
> > To: [email-masked]
> > Subject: Re: Moving right along ... generalized-signaling-06
> >
> > There exist well defined protection terminology in ITU-T for the
transport
> > plane. "Working" and "Protection" are being used and not
> primary/secondary.
> > E.g.
> > a 1+1 architecture has one working connection, one protection connection
> and
> > a
> > permanent bridge.
> >
> > Besides working/protection indication for the transport entity, there is
> > - "active" and "standby" to indicate if the signal is selected from the
> > working
> > or protection transport entity; i.e. if selector selects from working,
the
> > working is active and protection is standby, if the selector selects
from
> > protection the working is standby and the protection is active.
> > - "normal" and "extra traffic" signal. The normal signal is protected.
> >
> > Regards,
> >
> > Maarten
> >
> > [email-masked] wrote:
> > >
> > > Jonathan....review the text below....I think the problem is 1:1.
> > >
> > > neil
> > >
> > > > -----Original Message-----
> > > > From: Jonathan Lang [mailto:[email-masked]]
> > > > Sent: 12 December 2001 17:46
> > > > To: 'Ben Mack-Crane'; John Drake
> > > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > > Subject: RE: Moving right along ... generalized-signaling-06
> > > >
> > > >
> > > > Ben,
> > > >   Please see inline.
> > > >
> > > > Thanks,
> > > > Jonathan
> > > >
> > > > > -----Original Message-----
> > > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > > Sent: Wednesday, December 12, 2001 8:56 AM
> > > > > To: John Drake
> > > > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > > >
> > > > >
> > > > > See comment below.
> > > > >
> > > > > Regards,
> > > > > Ben
> > > > >
> > > > > John Drake wrote:
> > > > > >
> > > > > > Snipped
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > > > Sent: Tuesday, December 11, 2001 6:38 AM
> > > > > > To: Lou Berger
> > > > > > Cc: Kireeti Kompella; [email-masked]
> > > > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >7) In Protection Information it states "The resources
> > > > > allocated for a
> > > > > > > >    secondary LSP MAY be used by other LSPs until the
> > > > > primary LSP fails
> > > > > > > >    over to the secondary LSP."  This may not always be
> > > > > the case.  An
> > > > > > > >    explicit flag indicating whether or not extra
> > > > > traffic may use the
> > > > > > > >    secondary path resources is needed.
> > > > > > >
> > > > > > > ??? This is the purpose of this bit.
> > > > > >
> > > > > > This is not clear from the definition.  The bit is defined
> > > > > as indicating
> > > > > > the LSP is a secondary (or protecting) LSP and in 1+1
> > > > protection the
> > > > > > secondary LSP may not be used for extra traffic.
> > > > > >
> > > > > > Perhaps the problem here is that protection features are
> > > > > being defined
> > > > > > before the protection framework and requirements are
> > > > done.  Is this
> > > > > > presupposing some particular outcome of the recovery work in
CAMP?
> > > > > >
> > > > > > JD:  I think the definition of the bit is fine.  For both
> > > > > 1+1 and 1:1
> > > > > > protection, there would be a pair of Primary LSPs between
> > > > the source
> > > > > > and destination, rather than a Primary and a Secondary.
> > > > >
> > > > > This is an unusual use of terms.  I have never encountered a case
> > > > > where both the working and recovery paths are call "primary."
> > > > >
> > > > > This is not consistent with either draft-mpls-recovery-framework
> > > > > or with draft-lang-ccamp-recovery.  I think this is a sign that
the
> > > > > protection work is immature and not ready for progressing to RFC.
> > > > >
> > > > For 1+1 path protection, both working/recovery paths are
> > > > carrying user data
> > > > traffic and it is an endpoint decision as to which path is
> > > > actually the
> > > > working/recovery path.  At a transit node, both paths need to
> > > > be treated as
> > > > primary, as the resources are currently being used and
> > > > obviously can't be
> > > > used for Extra Traffic.
> > > >

Delivery-date: Tue, 18 Dec 2001 13:48:30 -0800
From: "Mannie, Eric" <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>, John Drake <[email-masked]>
Cc: Maarten Vissers <[email-masked]>, [email-masked]
Subject: RE: Moving right along ... generalized-signaling-06
Date: Tue, 18 Dec 2001 22:40:03 +0100

Hello Stephen,

John refers to fast restoration schemes that are being studied at the IETF.
Such schemes are widely implemented in the new classes of optical/TDM
equipments.

The wording of the text just need to use the terms "working" LSP and
"protecting" LSP, instead of primary and secondary. That's just an editing
modification.

The bit itself is useful to qualify the LSP being established.

The mechanisms to be applied to this qualification will be detailed in other
documents.

In the mean time, I guess that this bit can be used by implementations for a
simple restoration scheme (e.g. first establish working and protecting LSPs,
resources of protecting LSP may be "soft reserved", i.e. for extra-traffic,
when a fault occur send an RSVP-TE rapid failure notification to the source,
send Path with bit set to "working" on protecting LSP, this kills all LSPs
using these resources, when acked switch to this LSP).

Kind regards,

Eric

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Tuesday, December 18, 2001 7:38 PM
To: John Drake
Cc: Maarten Vissers; [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

John,
The problem here is that this is not compatible with transport plane
protection.
Assume you do 1:n MSP protection according to ITU Rec. G.841. The operation
of
the protection group is controlled by exchange of the K1, K2 bytes in the
MSOH of the PROTECTION MS. If the control plane reuses the protection MS at
for a different LSP at a time when the state of the protection group is
"No Request" (assuming no extra traffic carried on the protection section in
the
transport plane), this disables the protection since the endpoints of the
protection group are no longer able to exchange K1, K2 over the protection
channel. Even though the payload is unused and irrelevant to the transport
plane at this point, the exchange of overhead is essential to proper
operation
of the protection group.
Regards,
Steve

John Drake wrote:
> 
> Steven,
> 
> The basic idea is that if a connection is of type 'secondary', then other
> LSPs of type 'primary' between the same or different source/destination
> pairs MAY use its resources in intermediate nodes, until that LSP is
> converted into a 'primary' with a subsequent Path/Resv flow.  At this
point,
> other LSPs that were using its resources may get pre-empted.  Think of the
> primary/secondary mechanism as a way to ensure temporal priority while
> allowing network resources to be re-used; i.e., an LSP of type 'secondary'
> is carrying no data.
> 
> So in the 1:1 case the protect LSP could be established either as a
primary
> or secondary LSP, while in the 1:N case the protect LSP would be
established
> as a secondary.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Thursday, December 13, 2001 12:15 PM
> To: John Drake
> Cc: Maarten Vissers; [email-masked]
> Subject: Re: Moving right along ... generalized-signaling-06
> 
> John,
> It would seem from this standpoint, ANY transport plane protection
> must use "primary" for all trails. You have already made this argument
> for the 1+1 case to carry the permanently bridged copy of the payload.
> 
> In 1:1 or 1:n, when protection is not being used to carry one/any of
> the normal traffic signals, it may either carry a null signal (no bridge)
> or transport plane extra traffic. Even if the transport plane has only
> a null signal on protection, the control plane cannot itself place extra
> traffic on any portion of the end-to-end protection channel as this is
> where the APS protocol is carried to coordinate the 1:1 or 1:n protection.
> The protection channel overhead is chosen to carry the APS since it is
> necessary to exchange APS bytes to complete a switch when working channels
> are failed. If the protection channel has failed and APS cannot be
> exchanged,
> normal traffic signals will not be selected from protection.
> Regards,
> Steve
> 
> John Drake wrote:
> >
> > Maarten,
> >
> > That's fine, however it's beside the point.  The semantics of
> > Primary/Secondary refer to the control plane and whether the node
> > establishing a given LSP is planning to use it at the time it's
> established
> > or at a later time.  As I indicated in an earlier note, 1+1 transport
> plane
> > protection would be accomplished in the control plane by establishing
two
> > LSPs of type Primary.  The control plane really doesn't care which LSP
the
> > transport plane is using as Working and which as Protect, although that
> > information is available to the control plane at the LSP endpoints.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Maarten Vissers [mailto:[email-masked]]
> > Sent: Thursday, December 13, 2001 12:15 AM
> > To: [email-masked]
> > Subject: Re: Moving right along ... generalized-signaling-06
> >
> > There exist well defined protection terminology in ITU-T for the
transport
> > plane. "Working" and "Protection" are being used and not
> primary/secondary.
> > E.g.
> > a 1+1 architecture has one working connection, one protection connection
> and
> > a
> > permanent bridge.
> >
> > Besides working/protection indication for the transport entity, there is
> > - "active" and "standby" to indicate if the signal is selected from the
> > working
> > or protection transport entity; i.e. if selector selects from working,
the
> > working is active and protection is standby, if the selector selects
from
> > protection the working is standby and the protection is active.
> > - "normal" and "extra traffic" signal. The normal signal is protected.
> >
> > Regards,
> >
> > Maarten
> >
> > [email-masked] wrote:
> > >
> > > Jonathan....review the text below....I think the problem is 1:1.
> > >
> > > neil
> > >
> > > > -----Original Message-----
> > > > From: Jonathan Lang [mailto:[email-masked]]
> > > > Sent: 12 December 2001 17:46
> > > > To: 'Ben Mack-Crane'; John Drake
> > > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > > Subject: RE: Moving right along ... generalized-signaling-06
> > > >
> > > >
> > > > Ben,
> > > >   Please see inline.
> > > >
> > > > Thanks,
> > > > Jonathan
> > > >
> > > > > -----Original Message-----
> > > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > > Sent: Wednesday, December 12, 2001 8:56 AM
> > > > > To: John Drake
> > > > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > > >
> > > > >
> > > > > See comment below.
> > > > >
> > > > > Regards,
> > > > > Ben
> > > > >
> > > > > John Drake wrote:
> > > > > >
> > > > > > Snipped
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > > > Sent: Tuesday, December 11, 2001 6:38 AM
> > > > > > To: Lou Berger
> > > > > > Cc: Kireeti Kompella; [email-masked]
> > > > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >7) In Protection Information it states "The resources
> > > > > allocated for a
> > > > > > > >    secondary LSP MAY be used by other LSPs until the
> > > > > primary LSP fails
> > > > > > > >    over to the secondary LSP."  This may not always be
> > > > > the case.  An
> > > > > > > >    explicit flag indicating whether or not extra
> > > > > traffic may use the
> > > > > > > >    secondary path resources is needed.
> > > > > > >
> > > > > > > ??? This is the purpose of this bit.
> > > > > >
> > > > > > This is not clear from the definition.  The bit is defined
> > > > > as indicating
> > > > > > the LSP is a secondary (or protecting) LSP and in 1+1
> > > > protection the
> > > > > > secondary LSP may not be used for extra traffic.
> > > > > >
> > > > > > Perhaps the problem here is that protection features are
> > > > > being defined
> > > > > > before the protection framework and requirements are
> > > > done.  Is this
> > > > > > presupposing some particular outcome of the recovery work in
CAMP?
> > > > > >
> > > > > > JD:  I think the definition of the bit is fine.  For both
> > > > > 1+1 and 1:1
> > > > > > protection, there would be a pair of Primary LSPs between
> > > > the source
> > > > > > and destination, rather than a Primary and a Secondary.
> > > > >
> > > > > This is an unusual use of terms.  I have never encountered a case
> > > > > where both the working and recovery paths are call "primary."
> > > > >
> > > > > This is not consistent with either draft-mpls-recovery-framework
> > > > > or with draft-lang-ccamp-recovery.  I think this is a sign that
the
> > > > > protection work is immature and not ready for progressing to RFC.
> > > > >
> > > > For 1+1 path protection, both working/recovery paths are
> > > > carrying user data
> > > > traffic and it is an endpoint decision as to which path is
> > > > actually the
> > > > working/recovery path.  At a transit node, both paths need to
> > > > be treated as
> > > > primary, as the resources are currently being used and
> > > > obviously can't be
> > > > used for Extra Traffic.
> > > >

Delivery-date: Tue, 18 Dec 2001 13:43:48 -0800
From: "Mannie, Eric" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: 'Stephen Trowbridge' <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked], [email-masked],  [email-masked]
Subject: RE: GMPLS signaling documents updated per last calls
Date: Tue, 18 Dec 2001 22:39:06 +0100

Hi Jonathan,

> Why SHOULD and not MUST?  This ambiguity is likely to create
interoperability problems in the future...

To leave to the manufacturer and to the user the right to decide if he/she
wants to signal an LSP as either SDH or SONET. There is no interoperability
problem at all since you use EITHER SDH OR SONET. If you decide to request
an SDH signal with what do you want to have interoperability issue at this
stage ? The sentence means indeed "one should better use SDH than SONET" !
Once you decided, there is no issue.

> I'm curious what sort of backward compatability is necessary, as a
"standard" doesn't exist currently that this needs to be backward
compatible with...

Backward compatibility with the OIF UNI 1.0 Implementation Agreement, with
the implementations that could not care of SDH, with implementations that
still do a distinction between SONET and SDH for some reasons, with the
implementations that could still use the VT3 (DS1C) (I don't have
confirmation that nobody is using it today, and this is not the goal of this
draft to state what is obsolete or not in SONET), etc.

Anyway, there is no issue, the SONET label format is not used until SONET is
explicitly requested as such. This is not a primary feature of the draft,
but a *secondary feature*, for SONET lovers. Otherwise, SDH is used for
everything, consequently you don't care of the SONET label, you skip it in
the draft, you ignore it, you don't implement it and you just use a full SDH
implementation.

I think that the solution is quite simple: if the SONET signal is indeed an
SDH signal, why do you bother with SONET ? Just ask for an SDH signal,
that's all.

By the way, since according to some folks SONET is just a subset of SDH, why
do we care about SONET in these documents ? Why don't we simply remove all
references to SONET ?

Is there somebody on this mailing list that cares about SONET ? If yes, why
? Who is still manufacturing SONET boxes ? Why is that not called SDH ?

Kind regards,

Eric

-----Original Message-----
From: Jonathan Sadler [mailto:[email-masked]]
Sent: Tuesday, December 18, 2001 9:57 PM
To: Mannie, Eric
Cc: 'Stephen Trowbridge'; Kireeti Kompella; [email-masked];
[email-masked]; [email-masked]
Subject: Re: GMPLS signaling documents updated per last calls

Eric -

Comments inline...

Jonathan Sadler

"Mannie, Eric" wrote:
> "A SONET signal which has an identical SDH signal SHOULD be requested
using
> the same traffic parameters as for the equivalent SDH signal, and will
> consequently use the SDH label."

Why SHOULD and not MUST?  This ambiguity is likely to create
interoperability problems in the future...

> We spend with Maarten a lot of time to write that sentence (not easy to
> write).
> 
> Maybe that it should be better written:
> 
> "A SONET signal which has an identical SDH signal SHOULD be requested as
an
> SDH signal using the same traffic parameters as for the equivalent SDH
> signal, and will consequently use the SDH label."

Again, "SHOULD" needs to be replaced with "MUST"...

> This doesn't mean that the SONET signal format disappear (simply not used
in
> that case), for backward compatibility we need to keep it.

I'm curious what sort of backward compatability is necessary, as a
"standard" doesn't exist currently that this needs to be backward
compatible with...

> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Tuesday, December 18, 2001 7:46 PM
> To: Kireeti Kompella
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: GMPLS signaling documents updated per last calls
> 
> Kireeti,
> The one outlyer is VT3 (3 Megabits). VC-3 is an extremely popular
> rate in both SONET and SDH. I exchanged an email with Deborah Brungard
> (T1X1.5 chair) on this one and I take the liberty of sharing her response:
> 
> Deborah Brungard wrote:
> > The VT3 (3M) structure was defined - but no services (mappings) were
ever
> defined for it. So there are no services/equip
> > with it. My take was if in the future it was ever defined (doubtful), we
> would be adding it to g707 also. So then it
> > would just be part of g707 too.
> 
> So basically, there are no mappings or equipment functions for this rate,
> and as far as we know no network equipment or networks supporting it.
> Deborah suggests that if we were ever to define such mappings, that this
> would be proposed for addition to G.707 and hence be part of SDH.
> 
> I think our agreement had been to use the SDH label for all signals that
> had the same multiplex structure in SONET and SDH. In Salt Lake City, we
> thought
> that this was everything except VT3. Given that VT3 seems not to be a
"real"
> signal at this point and will likely be added to SDH if it ever becomes
> real, does our agreement then become that we use SDH labels for
everything?
> 
> Regards,
> Steve
> 
> Kireeti Kompella wrote:
> >
> > Hi Deborah,
> >
> > > I previously made the
> > > comments to merge the (1) SDH and SONET values as one value
> >
> > There was a meeting among Steve Trowbridge, Maarten Vissers,
> > Eric Mannie, Dimitri Papadimitriou, the CCAMP ADs and chairs on
> > several issues, among them this one.  The upshot was that whenever
> > possible, the SDH label should be used, with the encoding type
> > set to SDH (i.e., G.707); however, there are signals that have
> > no SDH equivalent (if I remember right, VC-3 -- someone correct
> > me!), so we will keep SONET labels and encoding types around
> > for that case and for legacy equipment.
> >
> > The revised SONET/SDH document will contain the exact wording.
> > I will also be sending a reply to the ITU communication stating
> > the agreement we came to.
> >
> > Kireeti.

Delivery-date: Tue, 18 Dec 2001 13:03:04 -0800
Date: Tue, 18 Dec 2001 14:57:03 -0600
From: Jonathan Sadler <[email-masked]>
Reply-To: [email-masked]
To: "Mannie, Eric" <[email-masked]>
CC: "'Stephen Trowbridge'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: GMPLS signaling documents updated per last calls

Eric -

Comments inline...

Jonathan Sadler

"Mannie, Eric" wrote:
> "A SONET signal which has an identical SDH signal SHOULD be requested using
> the same traffic parameters as for the equivalent SDH signal, and will
> consequently use the SDH label."

Why SHOULD and not MUST?  This ambiguity is likely to create
interoperability problems in the future...

> We spend with Maarten a lot of time to write that sentence (not easy to
> write).
> 
> Maybe that it should be better written:
> 
> "A SONET signal which has an identical SDH signal SHOULD be requested as an
> SDH signal using the same traffic parameters as for the equivalent SDH
> signal, and will consequently use the SDH label."

Again, "SHOULD" needs to be replaced with "MUST"...

> This doesn't mean that the SONET signal format disappear (simply not used in
> that case), for backward compatibility we need to keep it.

I'm curious what sort of backward compatability is necessary, as a
"standard" doesn't exist currently that this needs to be backward
compatible with...

> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Tuesday, December 18, 2001 7:46 PM
> To: Kireeti Kompella
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: GMPLS signaling documents updated per last calls
> 
> Kireeti,
> The one outlyer is VT3 (3 Megabits). VC-3 is an extremely popular
> rate in both SONET and SDH. I exchanged an email with Deborah Brungard
> (T1X1.5 chair) on this one and I take the liberty of sharing her response:
> 
> Deborah Brungard wrote:
> > The VT3 (3M) structure was defined - but no services (mappings) were ever
> defined for it. So there are no services/equip
> > with it. My take was if in the future it was ever defined (doubtful), we
> would be adding it to g707 also. So then it
> > would just be part of g707 too.
> 
> So basically, there are no mappings or equipment functions for this rate,
> and as far as we know no network equipment or networks supporting it.
> Deborah suggests that if we were ever to define such mappings, that this
> would be proposed for addition to G.707 and hence be part of SDH.
> 
> I think our agreement had been to use the SDH label for all signals that
> had the same multiplex structure in SONET and SDH. In Salt Lake City, we
> thought
> that this was everything except VT3. Given that VT3 seems not to be a "real"
> signal at this point and will likely be added to SDH if it ever becomes
> real, does our agreement then become that we use SDH labels for everything?
> 
> Regards,
> Steve
> 
> Kireeti Kompella wrote:
> >
> > Hi Deborah,
> >
> > > I previously made the
> > > comments to merge the (1) SDH and SONET values as one value
> >
> > There was a meeting among Steve Trowbridge, Maarten Vissers,
> > Eric Mannie, Dimitri Papadimitriou, the CCAMP ADs and chairs on
> > several issues, among them this one.  The upshot was that whenever
> > possible, the SDH label should be used, with the encoding type
> > set to SDH (i.e., G.707); however, there are signals that have
> > no SDH equivalent (if I remember right, VC-3 -- someone correct
> > me!), so we will keep SONET labels and encoding types around
> > for that case and for legacy equipment.
> >
> > The revised SONET/SDH document will contain the exact wording.
> > I will also be sending a reply to the ITU communication stating
> > the agreement we came to.
> >
> > Kireeti.

Delivery-date: Tue, 18 Dec 2001 12:24:21 -0800
From: Markus Jork <[email-masked]>
To: John Drake <[email-masked]>
cc: [email-masked]
Subject: Re: Moving right along ... generalized-rsvp-te-05 
Date: Tue, 18 Dec 2001 15:23:37 -0500

> Markus,
> 
> The router would specify LSC in the generalized label request.  The
> Router/OXC links are PSC at the router end and LSC at the OXC end.
> 
> Thanks,
> 
> John

Good, this is what I expected. But as I said the spec seems to be
in conflict with this interpretation. How about we change 
the sentence:

    Nodes MUST verify that the type indicated in the Switching Type
    parameter is supported on the corresponding incoming interface.

to:

    Transit nodes MUST verify that the type indicated in the Switching Type
    parameter is supported on the corresponding incoming interface.

I guess egress nodes could check that the Switching Type parameter is
supported on the far end of the incoming link.

Thanks,
Markus

> -----Original Message-----
> From: Markus Jork [mailto:[email-masked]]
> Sent: Monday, December 17, 2001 1:39 PM
> To: Lou Berger
> Cc: [email-masked]
> Subject: Re: Moving right along ... generalized-rsvp-te-05 
> 
> 
> Lou,
> 
> I think there is still some confusion in the draft regarding
> the switching type. Of course it could also be that the draft
> is perfectly clear and I'm confused...
> 
> Quoting a response you gave to Manoj/Ben:
> 
> > > >
> > > > >A Tunnel (FA) is a type
> > > > >    of link, not a class of switching.  This adds to the
> > > > >    confusion I've noted about the need for and use of Switching
> > > > >    Type.
> > >
> > >Switching Type continues to be ill-defined.  I have heard that the real
> > >definition is different from that given in the current drafts.  If the
> > >signaling information is not clearly defined and it's use described, we
> > >can hardly expect interoperability.
> > 
> > I can't speak for others.  My belief is that there is a very concrete 
> > definition.   I thought the text in the draft was clear as well, but let
> me 
> > try again:
> > 
> > 
> >          Switching Type: 8 bits
> > 
> >          Indicates the type of switching that should be performed
> >          on a particular link.  This field is needed for links that
> >          advertise more than one type of switching capability.
> >          This field contains one of the values advertised for the
> >          corresponding link in the routing Switching Capability
> >          field as defined in [GMPLS-RTG].
> > 
> > In other words, on links where one Switching Capability is advertised 
> > (which will be all the time for most equipment) Switching Type is set to 
> > the same value as advertised in routing.  On links where multiple
> Switching 
> > Capabilities are advertised, Switching Type is set to the value advertised
> 
> > in Switching Capability that matches the type of switching to be
> performed.
> > 
> > [I'll put the revised text in the next rev...]
> > 
> 
> Let's look at the example of two IP routers connected to a cloud of
> opaque OXCs:
> 
> R1 ----- OXC1 ----- OXC2 ----- R2
>     LSC        LSC        PSC
> 
> OXC1 and OXC2 switch the Sonet stream from an incoming interface to
> some outgoing interface, that's why links R1-OXC1 and OXC1-OCX2
> are advertised as LSC in the IGP. Link OXC2-R2 is PSC because R2 looks
> at the incoming IP packets. The encoding on the links is OC192.
> 
> Now I want to setup an LSP between R1 and R2. (This LSP is essentially
> a "lightpath" through the optical cloud and will be advertised as FA
> so that PSC LSPs can be tunneled through it later.)
> What is the switching type requested in the Generalized Label Request
> object? I would expect LSC.
> But section 2.1 of draft-ietf-mpls-generalized-rsvp-te-06 says:
> 
>    A Generalized Label Request object is set by the ingress node,
>    transparently passed by transit nodes, and used by the egress node.
> 
> This would suggest the switching type needs to be PSC.
> But then the text in 2.1.1 says:
> 
>    Nodes MUST verify that the type indicated in the Switching Type
>    parameter is supported on the corresponding incoming interface.  If
>    the type cannot be supported, the node MUST generate a PathErr
>    message with a "Routing problem/Switching Type" indication.
> 
> So when the Path message requested PSC, it would be rejected by OXC1
> and OXC2. When it requested LSC it would be rejected by R2.
> The transit nodes can't modify the switching type in the Path message
> because they don't have enough knowledge to pick the right one.
> How is this supposed to work?
> 
> thanks for any clarification,
> Markus 
> 
> 
> 
> 

Delivery-date: Tue, 18 Dec 2001 12:20:49 -0800
From: "Mannie, Eric" <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>, Kireeti Kompella <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked]
Subject: RE: GMPLS signaling documents updated per last calls
Date: Tue, 18 Dec 2001 21:16:05 +0100

Hi Stephen,

The current wording is (as it is written in the updated draft that I sent
last week on the ccamp mailing list):

"A SONET signal which has an identical SDH signal SHOULD be requested using
the same traffic parameters as for the equivalent SDH signal, and will
consequently use the SDH label."

We spend with Maarten a lot of time to write that sentence (not easy to
write).

Maybe that it should be better written:

"A SONET signal which has an identical SDH signal SHOULD be requested as an
SDH signal using the same traffic parameters as for the equivalent SDH
signal, and will consequently use the SDH label."

This means in practice: request an SDH signal when identical to a SONET
signal. In that case, from the control plane point of view everything is
SDH, i.e. the control plane is not aware of SONET at all. Of course, if an
SDH signal is requested the SDH label is used. The distinction between SDH
and SONET in that case being only at the connection monitoring level if I am
right (please confirm).

This doesn't mean that the SONET signal format disappear (simply not used in
that case), for backward compatibility we need to keep it.

Kind regards,

Eric

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Tuesday, December 18, 2001 7:46 PM
To: Kireeti Kompella
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: GMPLS signaling documents updated per last calls

Kireeti,
The one outlyer is VT3 (3 Megabits). VC-3 is an extremely popular
rate in both SONET and SDH. I exchanged an email with Deborah Brungard
(T1X1.5 chair) on this one and I take the liberty of sharing her response:

Deborah Brungard wrote:
> The VT3 (3M) structure was defined - but no services (mappings) were ever
defined for it. So there are no services/equip
> with it. My take was if in the future it was ever defined (doubtful), we
would be adding it to g707 also. So then it
> would just be part of g707 too.

So basically, there are no mappings or equipment functions for this rate,
and as far as we know no network equipment or networks supporting it.
Deborah suggests that if we were ever to define such mappings, that this
would be proposed for addition to G.707 and hence be part of SDH.

I think our agreement had been to use the SDH label for all signals that
had the same multiplex structure in SONET and SDH. In Salt Lake City, we
thought
that this was everything except VT3. Given that VT3 seems not to be a "real"
signal at this point and will likely be added to SDH if it ever becomes
real, does our agreement then become that we use SDH labels for everything?

Regards,
Steve

Kireeti Kompella wrote:
> 
> Hi Deborah,
> 
> > I previously made the
> > comments to merge the (1) SDH and SONET values as one value
> 
> There was a meeting among Steve Trowbridge, Maarten Vissers,
> Eric Mannie, Dimitri Papadimitriou, the CCAMP ADs and chairs on
> several issues, among them this one.  The upshot was that whenever
> possible, the SDH label should be used, with the encoding type
> set to SDH (i.e., G.707); however, there are signals that have
> no SDH equivalent (if I remember right, VC-3 -- someone correct
> me!), so we will keep SONET labels and encoding types around
> for that case and for legacy equipment.
> 
> The revised SONET/SDH document will contain the exact wording.
> I will also be sending a reply to the ITU communication stating
> the agreement we came to.
> 
> Kireeti.

Delivery-date: Tue, 18 Dec 2001 11:04:30 -0800
Date: Tue, 18 Dec 2001 11:56:11 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: Zhi-Wei Lin <[email-masked]>
CC: Ben Mack-Crane <[email-masked]>, Maarten Vissers <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

Zhi,
We have been trying to work some consistency into this terminology over time.

Working and Protection are terms that we are trying to use only between the
ends of the protected domain.
Normal traffic is the traffic that is carried over Working (sections, trails,
whatever) in the absence of a failure or other switch cause.
Extra traffic may be carried over Protection (sections, trails, ...) when
they are not needed to carry Normal traffic.
Active and Standby have normally been used with respect to 1+1 arrangements,
although could make sense to use these terms in 1:n without extra traffic
as well. An active (trail, section,...) is the one from which a normal traffic
signal is currently selected, where a standby (trail, section) is one from
which normal traffic is not currently selected. I am not entirely happy
with use of the word "standby" to describe something that is currently
carrying extra traffic.
Regards,
Steve

Zhi-Wei Lin wrote:
> 
> Hi,
> 
> I think active/standby and extra-traffic/normal-traffic are also two
> separate descriptors. Extra traffic may be carried on a standby
> connection (but a standby connection does not necessarily have extra
> traffic on it).
> 
> How do we define normal traffic? Is this user traffic carried by working
> path (when working is active), or also carried by recovery path (when
> recovery is active)?
> 
> And once you defined these, I think you still may need to specify
> whether a connection is revertive or non-revertive.
> 
> For example, take the case of 1+1. One operator may decide to use
> non-revertive (because both paths are "equivalent") so avoid a switching
> hit on the traffic (order of milliseconds?), while another operator may
> decide to use revertive (because the recovery path is much longer/more
> hops). Could these decisions be made per protected LSP basis? If yes,
> then would tail-end need to know which mode it is operating/to use (the
> intermediate nodes don't need to know this)?
> 
> Zhi
> 
> Ben Mack-Crane wrote:
> 
> > Maarten,
> >
> > In the work on a recovery framework for mpls (draft-ietf-mpls-recovery-frmwrk-03.txt)
> > we chose "working path" and "recovery path."  We used "recovery" instead of "protection"
> > because it seemed a more neutral term given that we were including both protection
> > switching and reroute recovery mechanisms.
> >
> > We did not address the state (active/standby).  We use the terms "extra traffic" and
> > "working traffic" (perhaps the latter could be changed to "normal traffic").
> >
> > It would be useful in moving forward in CCAMP if we could try to adopt terms
> > that are consistent with those in current use elsewhere.
> >
> > Regards,
> > Ben
> >
> > Maarten Vissers wrote:
> >
> >>There exist well defined protection terminology in ITU-T for the transport
> >>plane. "Working" and "Protection" are being used and not primary/secondary. E.g.
> >>a 1+1 architecture has one working connection, one protection connection and a
> >>permanent bridge.
> >>
> >>Besides working/protection indication for the transport entity, there is
> >>- "active" and "standby" to indicate if the signal is selected from the working
> >>or protection transport entity; i.e. if selector selects from working, the
> >>working is active and protection is standby, if the selector selects from
> >>protection the working is standby and the protection is active.
> >>- "normal" and "extra traffic" signal. The normal signal is protected.
> >>
> >>Regards,
> >>
> >>Maarten
> >>
> >>[email-masked] wrote:
> >>
> >>>Jonathan....review the text below....I think the problem is 1:1.
> >>>
> >>>neil
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: Jonathan Lang [mailto:[email-masked]]
> >>>>Sent: 12 December 2001 17:46
> >>>>To: 'Ben Mack-Crane'; John Drake
> >>>>Cc: Lou Berger; Kireeti Kompella; [email-masked]
> >>>>Subject: RE: Moving right along ... generalized-signaling-06
> >>>>
> >>>>
> >>>>Ben,
> >>>>  Please see inline.
> >>>>
> >>>>Thanks,
> >>>>Jonathan
> >>>>
> >>>>
> >>>>>-----Original Message-----
> >>>>>From: Ben Mack-Crane [mailto:[email-masked]]
> >>>>>Sent: Wednesday, December 12, 2001 8:56 AM
> >>>>>To: John Drake
> >>>>>Cc: Lou Berger; Kireeti Kompella; [email-masked]
> >>>>>Subject: Re: Moving right along ... generalized-signaling-06
> >>>>>
> >>>>>
> >>>>>See comment below.
> >>>>>
> >>>>>Regards,
> >>>>>Ben
> >>>>>
> >>>>>John Drake wrote:
> >>>>>
> >>>>>>Snipped
> >>>>>>
> >>>>>>-----Original Message-----
> >>>>>>From: Ben Mack-Crane [mailto:[email-masked]]
> >>>>>>Sent: Tuesday, December 11, 2001 6:38 AM
> >>>>>>To: Lou Berger
> >>>>>>Cc: Kireeti Kompella; [email-masked]
> >>>>>>Subject: Re: Moving right along ... generalized-signaling-06
> >>>>>>
> >>>>>>
> >>>>>>>>7) In Protection Information it states "The resources
> >>>>>>>>
> >>>>>allocated for a
> >>>>>
> >>>>>>>>   secondary LSP MAY be used by other LSPs until the
> >>>>>>>>
> >>>>>primary LSP fails
> >>>>>
> >>>>>>>>   over to the secondary LSP."  This may not always be
> >>>>>>>>
> >>>>>the case.  An
> >>>>>
> >>>>>>>>   explicit flag indicating whether or not extra
> >>>>>>>>
> >>>>>traffic may use the
> >>>>>
> >>>>>>>>   secondary path resources is needed.
> >>>>>>>>
> >>>>>>>??? This is the purpose of this bit.
> >>>>>>>
> >>>>>>This is not clear from the definition.  The bit is defined
> >>>>>>
> >>>>>as indicating
> >>>>>
> >>>>>>the LSP is a secondary (or protecting) LSP and in 1+1
> >>>>>>
> >>>>protection the
> >>>>
> >>>>>>secondary LSP may not be used for extra traffic.
> >>>>>>
> >>>>>>Perhaps the problem here is that protection features are
> >>>>>>
> >>>>>being defined
> >>>>>
> >>>>>>before the protection framework and requirements are
> >>>>>>
> >>>>done.  Is this
> >>>>
> >>>>>>presupposing some particular outcome of the recovery work in CAMP?
> >>>>>>
> >>>>>>JD:  I think the definition of the bit is fine.  For both
> >>>>>>
> >>>>>1+1 and 1:1
> >>>>>
> >>>>>>protection, there would be a pair of Primary LSPs between
> >>>>>>
> >>>>the source
> >>>>
> >>>>>>and destination, rather than a Primary and a Secondary.
> >>>>>>
> >>>>>This is an unusual use of terms.  I have never encountered a case
> >>>>>where both the working and recovery paths are call "primary."
> >>>>>
> >>>>>This is not consistent with either draft-mpls-recovery-framework
> >>>>>or with draft-lang-ccamp-recovery.  I think this is a sign that the
> >>>>>protection work is immature and not ready for progressing to RFC.
> >>>>>
> >>>>>
> >>>>For 1+1 path protection, both working/recovery paths are
> >>>>carrying user data
> >>>>traffic and it is an endpoint decision as to which path is
> >>>>actually the
> >>>>working/recovery path.  At a transit node, both paths need to
> >>>>be treated as
> >>>>primary, as the resources are currently being used and
> >>>>obviously can't be
> >>>>used for Extra Traffic.
> >>>>
> >>>>
> >

Delivery-date: Tue, 18 Dec 2001 10:55:01 -0800
Date: Tue, 18 Dec 2001 11:46:07 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: Kireeti Kompella <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: GMPLS signaling documents updated per last calls

Kireeti,
The one outlyer is VT3 (3 Megabits). VC-3 is an extremely popular
rate in both SONET and SDH. I exchanged an email with Deborah Brungard
(T1X1.5 chair) on this one and I take the liberty of sharing her response:

Deborah Brungard wrote:
> The VT3 (3M) structure was defined - but no services (mappings) were ever defined for it. So there are no services/equip
> with it. My take was if in the future it was ever defined (doubtful), we would be adding it to g707 also. So then it
> would just be part of g707 too.

So basically, there are no mappings or equipment functions for this rate,
and as far as we know no network equipment or networks supporting it.
Deborah suggests that if we were ever to define such mappings, that this
would be proposed for addition to G.707 and hence be part of SDH.

I think our agreement had been to use the SDH label for all signals that
had the same multiplex structure in SONET and SDH. In Salt Lake City, we thought
that this was everything except VT3. Given that VT3 seems not to be a "real"
signal at this point and will likely be added to SDH if it ever becomes
real, does our agreement then become that we use SDH labels for everything?

Regards,
Steve

Kireeti Kompella wrote:
> 
> Hi Deborah,
> 
> > I previously made the
> > comments to merge the (1) SDH and SONET values as one value
> 
> There was a meeting among Steve Trowbridge, Maarten Vissers,
> Eric Mannie, Dimitri Papadimitriou, the CCAMP ADs and chairs on
> several issues, among them this one.  The upshot was that whenever
> possible, the SDH label should be used, with the encoding type
> set to SDH (i.e., G.707); however, there are signals that have
> no SDH equivalent (if I remember right, VC-3 -- someone correct
> me!), so we will keep SONET labels and encoding types around
> for that case and for legacy equipment.
> 
> The revised SONET/SDH document will contain the exact wording.
> I will also be sending a reply to the ITU communication stating
> the agreement we came to.
> 
> Kireeti.

Delivery-date: Tue, 18 Dec 2001 10:48:47 -0800
Date: Tue, 18 Dec 2001 11:38:02 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
CC: Maarten Vissers <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

John,
The problem here is that this is not compatible with transport plane protection.
Assume you do 1:n MSP protection according to ITU Rec. G.841. The operation of
the protection group is controlled by exchange of the K1, K2 bytes in the
MSOH of the PROTECTION MS. If the control plane reuses the protection MS at
for a different LSP at a time when the state of the protection group is
"No Request" (assuming no extra traffic carried on the protection section in the
transport plane), this disables the protection since the endpoints of the
protection group are no longer able to exchange K1, K2 over the protection
channel. Even though the payload is unused and irrelevant to the transport
plane at this point, the exchange of overhead is essential to proper operation
of the protection group.
Regards,
Steve

John Drake wrote:
> 
> Steven,
> 
> The basic idea is that if a connection is of type 'secondary', then other
> LSPs of type 'primary' between the same or different source/destination
> pairs MAY use its resources in intermediate nodes, until that LSP is
> converted into a 'primary' with a subsequent Path/Resv flow.  At this point,
> other LSPs that were using its resources may get pre-empted.  Think of the
> primary/secondary mechanism as a way to ensure temporal priority while
> allowing network resources to be re-used; i.e., an LSP of type 'secondary'
> is carrying no data.
> 
> So in the 1:1 case the protect LSP could be established either as a primary
> or secondary LSP, while in the 1:N case the protect LSP would be established
> as a secondary.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Thursday, December 13, 2001 12:15 PM
> To: John Drake
> Cc: Maarten Vissers; [email-masked]
> Subject: Re: Moving right along ... generalized-signaling-06
> 
> John,
> It would seem from this standpoint, ANY transport plane protection
> must use "primary" for all trails. You have already made this argument
> for the 1+1 case to carry the permanently bridged copy of the payload.
> 
> In 1:1 or 1:n, when protection is not being used to carry one/any of
> the normal traffic signals, it may either carry a null signal (no bridge)
> or transport plane extra traffic. Even if the transport plane has only
> a null signal on protection, the control plane cannot itself place extra
> traffic on any portion of the end-to-end protection channel as this is
> where the APS protocol is carried to coordinate the 1:1 or 1:n protection.
> The protection channel overhead is chosen to carry the APS since it is
> necessary to exchange APS bytes to complete a switch when working channels
> are failed. If the protection channel has failed and APS cannot be
> exchanged,
> normal traffic signals will not be selected from protection.
> Regards,
> Steve
> 
> John Drake wrote:
> >
> > Maarten,
> >
> > That's fine, however it's beside the point.  The semantics of
> > Primary/Secondary refer to the control plane and whether the node
> > establishing a given LSP is planning to use it at the time it's
> established
> > or at a later time.  As I indicated in an earlier note, 1+1 transport
> plane
> > protection would be accomplished in the control plane by establishing two
> > LSPs of type Primary.  The control plane really doesn't care which LSP the
> > transport plane is using as Working and which as Protect, although that
> > information is available to the control plane at the LSP endpoints.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Maarten Vissers [mailto:[email-masked]]
> > Sent: Thursday, December 13, 2001 12:15 AM
> > To: [email-masked]
> > Subject: Re: Moving right along ... generalized-signaling-06
> >
> > There exist well defined protection terminology in ITU-T for the transport
> > plane. "Working" and "Protection" are being used and not
> primary/secondary.
> > E.g.
> > a 1+1 architecture has one working connection, one protection connection
> and
> > a
> > permanent bridge.
> >
> > Besides working/protection indication for the transport entity, there is
> > - "active" and "standby" to indicate if the signal is selected from the
> > working
> > or protection transport entity; i.e. if selector selects from working, the
> > working is active and protection is standby, if the selector selects from
> > protection the working is standby and the protection is active.
> > - "normal" and "extra traffic" signal. The normal signal is protected.
> >
> > Regards,
> >
> > Maarten
> >
> > [email-masked] wrote:
> > >
> > > Jonathan....review the text below....I think the problem is 1:1.
> > >
> > > neil
> > >
> > > > -----Original Message-----
> > > > From: Jonathan Lang [mailto:[email-masked]]
> > > > Sent: 12 December 2001 17:46
> > > > To: 'Ben Mack-Crane'; John Drake
> > > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > > Subject: RE: Moving right along ... generalized-signaling-06
> > > >
> > > >
> > > > Ben,
> > > >   Please see inline.
> > > >
> > > > Thanks,
> > > > Jonathan
> > > >
> > > > > -----Original Message-----
> > > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > > Sent: Wednesday, December 12, 2001 8:56 AM
> > > > > To: John Drake
> > > > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > > >
> > > > >
> > > > > See comment below.
> > > > >
> > > > > Regards,
> > > > > Ben
> > > > >
> > > > > John Drake wrote:
> > > > > >
> > > > > > Snipped
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > > > Sent: Tuesday, December 11, 2001 6:38 AM
> > > > > > To: Lou Berger
> > > > > > Cc: Kireeti Kompella; [email-masked]
> > > > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >7) In Protection Information it states "The resources
> > > > > allocated for a
> > > > > > > >    secondary LSP MAY be used by other LSPs until the
> > > > > primary LSP fails
> > > > > > > >    over to the secondary LSP."  This may not always be
> > > > > the case.  An
> > > > > > > >    explicit flag indicating whether or not extra
> > > > > traffic may use the
> > > > > > > >    secondary path resources is needed.
> > > > > > >
> > > > > > > ??? This is the purpose of this bit.
> > > > > >
> > > > > > This is not clear from the definition.  The bit is defined
> > > > > as indicating
> > > > > > the LSP is a secondary (or protecting) LSP and in 1+1
> > > > protection the
> > > > > > secondary LSP may not be used for extra traffic.
> > > > > >
> > > > > > Perhaps the problem here is that protection features are
> > > > > being defined
> > > > > > before the protection framework and requirements are
> > > > done.  Is this
> > > > > > presupposing some particular outcome of the recovery work in CAMP?
> > > > > >
> > > > > > JD:  I think the definition of the bit is fine.  For both
> > > > > 1+1 and 1:1
> > > > > > protection, there would be a pair of Primary LSPs between
> > > > the source
> > > > > > and destination, rather than a Primary and a Secondary.
> > > > >
> > > > > This is an unusual use of terms.  I have never encountered a case
> > > > > where both the working and recovery paths are call "primary."
> > > > >
> > > > > This is not consistent with either draft-mpls-recovery-framework
> > > > > or with draft-lang-ccamp-recovery.  I think this is a sign that the
> > > > > protection work is immature and not ready for progressing to RFC.
> > > > >
> > > > For 1+1 path protection, both working/recovery paths are
> > > > carrying user data
> > > > traffic and it is an endpoint decision as to which path is
> > > > actually the
> > > > working/recovery path.  At a transit node, both paths need to
> > > > be treated as
> > > > primary, as the resources are currently being used and
> > > > obviously can't be
> > > > used for Extra Traffic.
> > > >

Delivery-date: Tue, 18 Dec 2001 10:40:30 -0800
Date: Tue, 18 Dec 2001 13:34:53 -0500
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Ben Mack-Crane <[email-masked]>
CC: Maarten Vissers <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

Hi,

I think active/standby and extra-traffic/normal-traffic are also two 
separate descriptors. Extra traffic may be carried on a standby 
connection (but a standby connection does not necessarily have extra 
traffic on it).

How do we define normal traffic? Is this user traffic carried by working 
path (when working is active), or also carried by recovery path (when 
recovery is active)?

And once you defined these, I think you still may need to specify 
whether a connection is revertive or non-revertive.

For example, take the case of 1+1. One operator may decide to use 
non-revertive (because both paths are "equivalent") so avoid a switching 
hit on the traffic (order of milliseconds?), while another operator may 
decide to use revertive (because the recovery path is much longer/more 
hops). Could these decisions be made per protected LSP basis? If yes, 
then would tail-end need to know which mode it is operating/to use (the 
intermediate nodes don't need to know this)?

Zhi

Ben Mack-Crane wrote:

> Maarten,
> 
> In the work on a recovery framework for mpls (draft-ietf-mpls-recovery-frmwrk-03.txt)
> we chose "working path" and "recovery path."  We used "recovery" instead of "protection" 
> because it seemed a more neutral term given that we were including both protection
> switching and reroute recovery mechanisms.
> 
> We did not address the state (active/standby).  We use the terms "extra traffic" and
> "working traffic" (perhaps the latter could be changed to "normal traffic").
> 
> It would be useful in moving forward in CCAMP if we could try to adopt terms
> that are consistent with those in current use elsewhere.
> 
> Regards,
> Ben
> 
> Maarten Vissers wrote:
> 
>>There exist well defined protection terminology in ITU-T for the transport
>>plane. "Working" and "Protection" are being used and not primary/secondary. E.g.
>>a 1+1 architecture has one working connection, one protection connection and a
>>permanent bridge.
>>
>>Besides working/protection indication for the transport entity, there is
>>- "active" and "standby" to indicate if the signal is selected from the working
>>or protection transport entity; i.e. if selector selects from working, the
>>working is active and protection is standby, if the selector selects from
>>protection the working is standby and the protection is active.
>>- "normal" and "extra traffic" signal. The normal signal is protected.
>>
>>Regards,
>>
>>Maarten
>>
>>[email-masked] wrote:
>>
>>>Jonathan....review the text below....I think the problem is 1:1.
>>>
>>>neil
>>>
>>>
>>>>-----Original Message-----
>>>>From: Jonathan Lang [mailto:[email-masked]]
>>>>Sent: 12 December 2001 17:46
>>>>To: 'Ben Mack-Crane'; John Drake
>>>>Cc: Lou Berger; Kireeti Kompella; [email-masked]
>>>>Subject: RE: Moving right along ... generalized-signaling-06
>>>>
>>>>
>>>>Ben,
>>>>  Please see inline.
>>>>
>>>>Thanks,
>>>>Jonathan
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Ben Mack-Crane [mailto:[email-masked]]
>>>>>Sent: Wednesday, December 12, 2001 8:56 AM
>>>>>To: John Drake
>>>>>Cc: Lou Berger; Kireeti Kompella; [email-masked]
>>>>>Subject: Re: Moving right along ... generalized-signaling-06
>>>>>
>>>>>
>>>>>See comment below.
>>>>>
>>>>>Regards,
>>>>>Ben
>>>>>
>>>>>John Drake wrote:
>>>>>
>>>>>>Snipped
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Ben Mack-Crane [mailto:[email-masked]]
>>>>>>Sent: Tuesday, December 11, 2001 6:38 AM
>>>>>>To: Lou Berger
>>>>>>Cc: Kireeti Kompella; [email-masked]
>>>>>>Subject: Re: Moving right along ... generalized-signaling-06
>>>>>>
>>>>>>
>>>>>>>>7) In Protection Information it states "The resources
>>>>>>>>
>>>>>allocated for a
>>>>>
>>>>>>>>   secondary LSP MAY be used by other LSPs until the
>>>>>>>>
>>>>>primary LSP fails
>>>>>
>>>>>>>>   over to the secondary LSP."  This may not always be
>>>>>>>>
>>>>>the case.  An
>>>>>
>>>>>>>>   explicit flag indicating whether or not extra
>>>>>>>>
>>>>>traffic may use the
>>>>>
>>>>>>>>   secondary path resources is needed.
>>>>>>>>
>>>>>>>??? This is the purpose of this bit.
>>>>>>>
>>>>>>This is not clear from the definition.  The bit is defined
>>>>>>
>>>>>as indicating
>>>>>
>>>>>>the LSP is a secondary (or protecting) LSP and in 1+1
>>>>>>
>>>>protection the
>>>>
>>>>>>secondary LSP may not be used for extra traffic.
>>>>>>
>>>>>>Perhaps the problem here is that protection features are
>>>>>>
>>>>>being defined
>>>>>
>>>>>>before the protection framework and requirements are
>>>>>>
>>>>done.  Is this
>>>>
>>>>>>presupposing some particular outcome of the recovery work in CAMP?
>>>>>>
>>>>>>JD:  I think the definition of the bit is fine.  For both
>>>>>>
>>>>>1+1 and 1:1
>>>>>
>>>>>>protection, there would be a pair of Primary LSPs between
>>>>>>
>>>>the source
>>>>
>>>>>>and destination, rather than a Primary and a Secondary.
>>>>>>
>>>>>This is an unusual use of terms.  I have never encountered a case
>>>>>where both the working and recovery paths are call "primary."
>>>>>
>>>>>This is not consistent with either draft-mpls-recovery-framework
>>>>>or with draft-lang-ccamp-recovery.  I think this is a sign that the
>>>>>protection work is immature and not ready for progressing to RFC.
>>>>>
>>>>>
>>>>For 1+1 path protection, both working/recovery paths are
>>>>carrying user data
>>>>traffic and it is an endpoint decision as to which path is
>>>>actually the
>>>>working/recovery path.  At a transit node, both paths need to
>>>>be treated as
>>>>primary, as the resources are currently being used and
>>>>obviously can't be
>>>>used for Extra Traffic.
>>>>
>>>>
> 

Delivery-date: Tue, 18 Dec 2001 09:53:58 -0800
From: John Drake <[email-masked]>
To: 'Markus Jork' <[email-masked]>, Lou Berger <[email-masked]>
Cc: [email-masked]
Subject: RE: Moving right along ... generalized-rsvp-te-05 
Date: Tue, 18 Dec 2001 09:50:31 -0800

Markus,

The router would specify LSC in the generalized label request.  The
Router/OXC links are PSC at the router end and LSC at the OXC end.

Thanks,

John

-----Original Message-----
From: Markus Jork [mailto:[email-masked]]
Sent: Monday, December 17, 2001 1:39 PM
To: Lou Berger
Cc: [email-masked]
Subject: Re: Moving right along ... generalized-rsvp-te-05 

Lou,

I think there is still some confusion in the draft regarding
the switching type. Of course it could also be that the draft
is perfectly clear and I'm confused...

Quoting a response you gave to Manoj/Ben:

> > >
> > > >A Tunnel (FA) is a type
> > > >    of link, not a class of switching.  This adds to the
> > > >    confusion I've noted about the need for and use of Switching
> > > >    Type.
> >
> >Switching Type continues to be ill-defined.  I have heard that the real
> >definition is different from that given in the current drafts.  If the
> >signaling information is not clearly defined and it's use described, we
> >can hardly expect interoperability.
> 
> I can't speak for others.  My belief is that there is a very concrete 
> definition.   I thought the text in the draft was clear as well, but let
me 
> try again:
> 
> 
>          Switching Type: 8 bits
> 
>          Indicates the type of switching that should be performed
>          on a particular link.  This field is needed for links that
>          advertise more than one type of switching capability.
>          This field contains one of the values advertised for the
>          corresponding link in the routing Switching Capability
>          field as defined in [GMPLS-RTG].
> 
> In other words, on links where one Switching Capability is advertised 
> (which will be all the time for most equipment) Switching Type is set to 
> the same value as advertised in routing.  On links where multiple
Switching 
> Capabilities are advertised, Switching Type is set to the value advertised

> in Switching Capability that matches the type of switching to be
performed.
> 
> [I'll put the revised text in the next rev...]
> 

Let's look at the example of two IP routers connected to a cloud of
opaque OXCs:

R1 ----- OXC1 ----- OXC2 ----- R2
    LSC        LSC        PSC

OXC1 and OXC2 switch the Sonet stream from an incoming interface to
some outgoing interface, that's why links R1-OXC1 and OXC1-OCX2
are advertised as LSC in the IGP. Link OXC2-R2 is PSC because R2 looks
at the incoming IP packets. The encoding on the links is OC192.

Now I want to setup an LSP between R1 and R2. (This LSP is essentially
a "lightpath" through the optical cloud and will be advertised as FA
so that PSC LSPs can be tunneled through it later.)
What is the switching type requested in the Generalized Label Request
object? I would expect LSC.
But section 2.1 of draft-ietf-mpls-generalized-rsvp-te-06 says:

   A Generalized Label Request object is set by the ingress node,
   transparently passed by transit nodes, and used by the egress node.

This would suggest the switching type needs to be PSC.
But then the text in 2.1.1 says:

   Nodes MUST verify that the type indicated in the Switching Type
   parameter is supported on the corresponding incoming interface.  If
   the type cannot be supported, the node MUST generate a PathErr
   message with a "Routing problem/Switching Type" indication.

So when the Path message requested PSC, it would be rejected by OXC1
and OXC2. When it requested LSC it would be rejected by R2.
The transit nodes can't modify the switching type in the Path message
because they don't have enough knowledge to pick the right one.
How is this supposed to work?

thanks for any clarification,
Markus 

Delivery-date: Tue, 18 Dec 2001 09:26:51 -0800
Date: Tue, 18 Dec 2001 11:22:07 -0600
From: Ben Mack-Crane <[email-masked]>
To: Maarten Vissers <[email-masked]>
CC: [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

Maarten,

In the work on a recovery framework for mpls (draft-ietf-mpls-recovery-frmwrk-03.txt)
we chose "working path" and "recovery path."  We used "recovery" instead of "protection" 
because it seemed a more neutral term given that we were including both protection
switching and reroute recovery mechanisms.

We did not address the state (active/standby).  We use the terms "extra traffic" and
"working traffic" (perhaps the latter could be changed to "normal traffic").

It would be useful in moving forward in CCAMP if we could try to adopt terms
that are consistent with those in current use elsewhere.

Regards,
Ben

Maarten Vissers wrote:
> 
> There exist well defined protection terminology in ITU-T for the transport
> plane. "Working" and "Protection" are being used and not primary/secondary. E.g.
> a 1+1 architecture has one working connection, one protection connection and a
> permanent bridge.
> 
> Besides working/protection indication for the transport entity, there is
> - "active" and "standby" to indicate if the signal is selected from the working
> or protection transport entity; i.e. if selector selects from working, the
> working is active and protection is standby, if the selector selects from
> protection the working is standby and the protection is active.
> - "normal" and "extra traffic" signal. The normal signal is protected.
> 
> Regards,
> 
> Maarten
> 
> [email-masked] wrote:
> >
> > Jonathan....review the text below....I think the problem is 1:1.
> >
> > neil
> >
> > > -----Original Message-----
> > > From: Jonathan Lang [mailto:[email-masked]]
> > > Sent: 12 December 2001 17:46
> > > To: 'Ben Mack-Crane'; John Drake
> > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > Subject: RE: Moving right along ... generalized-signaling-06
> > >
> > >
> > > Ben,
> > >   Please see inline.
> > >
> > > Thanks,
> > > Jonathan
> > >
> > > > -----Original Message-----
> > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > Sent: Wednesday, December 12, 2001 8:56 AM
> > > > To: John Drake
> > > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > >
> > > >
> > > > See comment below.
> > > >
> > > > Regards,
> > > > Ben
> > > >
> > > > John Drake wrote:
> > > > >
> > > > > Snipped
> > > > >
> > > > > -----Original Message-----
> > > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > > Sent: Tuesday, December 11, 2001 6:38 AM
> > > > > To: Lou Berger
> > > > > Cc: Kireeti Kompella; [email-masked]
> > > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > > >
> > > > > >
> > > > > > >
> > > > > > >7) In Protection Information it states "The resources
> > > > allocated for a
> > > > > > >    secondary LSP MAY be used by other LSPs until the
> > > > primary LSP fails
> > > > > > >    over to the secondary LSP."  This may not always be
> > > > the case.  An
> > > > > > >    explicit flag indicating whether or not extra
> > > > traffic may use the
> > > > > > >    secondary path resources is needed.
> > > > > >
> > > > > > ??? This is the purpose of this bit.
> > > > >
> > > > > This is not clear from the definition.  The bit is defined
> > > > as indicating
> > > > > the LSP is a secondary (or protecting) LSP and in 1+1
> > > protection the
> > > > > secondary LSP may not be used for extra traffic.
> > > > >
> > > > > Perhaps the problem here is that protection features are
> > > > being defined
> > > > > before the protection framework and requirements are
> > > done.  Is this
> > > > > presupposing some particular outcome of the recovery work in CAMP?
> > > > >
> > > > > JD:  I think the definition of the bit is fine.  For both
> > > > 1+1 and 1:1
> > > > > protection, there would be a pair of Primary LSPs between
> > > the source
> > > > > and destination, rather than a Primary and a Secondary.
> > > >
> > > > This is an unusual use of terms.  I have never encountered a case
> > > > where both the working and recovery paths are call "primary."
> > > >
> > > > This is not consistent with either draft-mpls-recovery-framework
> > > > or with draft-lang-ccamp-recovery.  I think this is a sign that the
> > > > protection work is immature and not ready for progressing to RFC.
> > > >
> > > For 1+1 path protection, both working/recovery paths are
> > > carrying user data
> > > traffic and it is an endpoint decision as to which path is
> > > actually the
> > > working/recovery path.  At a transit node, both paths need to
> > > be treated as
> > > primary, as the resources are currently being used and
> > > obviously can't be
> > > used for Extra Traffic.
> > >

Envelope-to: [email-masked]
Delivery-date: Tue, 18 Dec 2001 09:18:45 -0800
Date: Tue, 18 Dec 2001 09:12:28 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: GMPLS signaling documents updated per last calls
Cc: [email-masked], [email-masked]

Hi Deborah,

> I previously made the
> comments to merge the (1) SDH and SONET values as one value

There was a meeting among Steve Trowbridge, Maarten Vissers,
Eric Mannie, Dimitri Papadimitriou, the CCAMP ADs and chairs on
several issues, among them this one.  The upshot was that whenever
possible, the SDH label should be used, with the encoding type
set to SDH (i.e., G.707); however, there are signals that have
no SDH equivalent (if I remember right, VC-3 -- someone correct
me!), so we will keep SONET labels and encoding types around
for that case and for legacy equipment.

The revised SONET/SDH document will contain the exact wording.
I will also be sending a reply to the ITU communication stating
the agreement we came to.

Kireeti.

Delivery-date: Tue, 18 Dec 2001 09:04:47 -0800
Date: Tue, 18 Dec 2001 10:58:11 -0600
From: Ben Mack-Crane <[email-masked]>
To: John Drake <[email-masked]>
CC: "'Stephen Trowbridge'" <[email-masked]>, Maarten Vissers <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

John,

You describe a bit that indicates whether or not the path
should be connected.  Perhaps we could call such a bit the "reserve/connect"
bit.  Calling it Secondary is not in line with the normal use of that
term, and is thus misleading.

It is useful to have a bit which identifies whether the path
is the working or recovery path (thus the name "Secondary")
so I think we should keep that meaning for this bit.

Regards,
Ben

John Drake wrote:
> 
> Steven,
> 
> The basic idea is that if a connection is of type 'secondary', then other
> LSPs of type 'primary' between the same or different source/destination
> pairs MAY use its resources in intermediate nodes, until that LSP is
> converted into a 'primary' with a subsequent Path/Resv flow.  At this point,
> other LSPs that were using its resources may get pre-empted.  Think of the
> primary/secondary mechanism as a way to ensure temporal priority while
> allowing network resources to be re-used; i.e., an LSP of type 'secondary'
> is carrying no data.
> 
> So in the 1:1 case the protect LSP could be established either as a primary
> or secondary LSP, while in the 1:N case the protect LSP would be established
> as a secondary.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Thursday, December 13, 2001 12:15 PM
> To: John Drake
> Cc: Maarten Vissers; [email-masked]
> Subject: Re: Moving right along ... generalized-signaling-06
> 
> John,
> It would seem from this standpoint, ANY transport plane protection
> must use "primary" for all trails. You have already made this argument
> for the 1+1 case to carry the permanently bridged copy of the payload.
> 
> In 1:1 or 1:n, when protection is not being used to carry one/any of
> the normal traffic signals, it may either carry a null signal (no bridge)
> or transport plane extra traffic. Even if the transport plane has only
> a null signal on protection, the control plane cannot itself place extra
> traffic on any portion of the end-to-end protection channel as this is
> where the APS protocol is carried to coordinate the 1:1 or 1:n protection.
> The protection channel overhead is chosen to carry the APS since it is
> necessary to exchange APS bytes to complete a switch when working channels
> are failed. If the protection channel has failed and APS cannot be
> exchanged,
> normal traffic signals will not be selected from protection.
> Regards,
> Steve
> 
> John Drake wrote:
> >
> > Maarten,
> >
> > That's fine, however it's beside the point.  The semantics of
> > Primary/Secondary refer to the control plane and whether the node
> > establishing a given LSP is planning to use it at the time it's
> established
> > or at a later time.  As I indicated in an earlier note, 1+1 transport
> plane
> > protection would be accomplished in the control plane by establishing two
> > LSPs of type Primary.  The control plane really doesn't care which LSP the
> > transport plane is using as Working and which as Protect, although that
> > information is available to the control plane at the LSP endpoints.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Maarten Vissers [mailto:[email-masked]]
> > Sent: Thursday, December 13, 2001 12:15 AM
> > To: [email-masked]
> > Subject: Re: Moving right along ... generalized-signaling-06
> >
> > There exist well defined protection terminology in ITU-T for the transport
> > plane. "Working" and "Protection" are being used and not
> primary/secondary.
> > E.g.
> > a 1+1 architecture has one working connection, one protection connection
> and
> > a
> > permanent bridge.
> >
> > Besides working/protection indication for the transport entity, there is
> > - "active" and "standby" to indicate if the signal is selected from the
> > working
> > or protection transport entity; i.e. if selector selects from working, the
> > working is active and protection is standby, if the selector selects from
> > protection the working is standby and the protection is active.
> > - "normal" and "extra traffic" signal. The normal signal is protected.
> >
> > Regards,
> >
> > Maarten
> >
> > [email-masked] wrote:
> > >
> > > Jonathan....review the text below....I think the problem is 1:1.
> > >
> > > neil
> > >
> > > > -----Original Message-----
> > > > From: Jonathan Lang [mailto:[email-masked]]
> > > > Sent: 12 December 2001 17:46
> > > > To: 'Ben Mack-Crane'; John Drake
> > > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > > Subject: RE: Moving right along ... generalized-signaling-06
> > > >
> > > >
> > > > Ben,
> > > >   Please see inline.
> > > >
> > > > Thanks,
> > > > Jonathan
> > > >
> > > > > -----Original Message-----
> > > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > > Sent: Wednesday, December 12, 2001 8:56 AM
> > > > > To: John Drake
> > > > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > > >
> > > > >
> > > > > See comment below.
> > > > >
> > > > > Regards,
> > > > > Ben
> > > > >
> > > > > John Drake wrote:
> > > > > >
> > > > > > Snipped
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > > > Sent: Tuesday, December 11, 2001 6:38 AM
> > > > > > To: Lou Berger
> > > > > > Cc: Kireeti Kompella; [email-masked]
> > > > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >7) In Protection Information it states "The resources
> > > > > allocated for a
> > > > > > > >    secondary LSP MAY be used by other LSPs until the
> > > > > primary LSP fails
> > > > > > > >    over to the secondary LSP."  This may not always be
> > > > > the case.  An
> > > > > > > >    explicit flag indicating whether or not extra
> > > > > traffic may use the
> > > > > > > >    secondary path resources is needed.
> > > > > > >
> > > > > > > ??? This is the purpose of this bit.
> > > > > >
> > > > > > This is not clear from the definition.  The bit is defined
> > > > > as indicating
> > > > > > the LSP is a secondary (or protecting) LSP and in 1+1
> > > > protection the
> > > > > > secondary LSP may not be used for extra traffic.
> > > > > >
> > > > > > Perhaps the problem here is that protection features are
> > > > > being defined
> > > > > > before the protection framework and requirements are
> > > > done.  Is this
> > > > > > presupposing some particular outcome of the recovery work in CAMP?
> > > > > >
> > > > > > JD:  I think the definition of the bit is fine.  For both
> > > > > 1+1 and 1:1
> > > > > > protection, there would be a pair of Primary LSPs between
> > > > the source
> > > > > > and destination, rather than a Primary and a Secondary.
> > > > >
> > > > > This is an unusual use of terms.  I have never encountered a case
> > > > > where both the working and recovery paths are call "primary."
> > > > >
> > > > > This is not consistent with either draft-mpls-recovery-framework
> > > > > or with draft-lang-ccamp-recovery.  I think this is a sign that the
> > > > > protection work is immature and not ready for progressing to RFC.
> > > > >
> > > > For 1+1 path protection, both working/recovery paths are
> > > > carrying user data
> > > > traffic and it is an endpoint decision as to which path is
> > > > actually the
> > > > working/recovery path.  At a transit node, both paths need to
> > > > be treated as
> > > > primary, as the resources are currently being used and
> > > > obviously can't be
> > > > used for Extra Traffic.
> > > >

Delivery-date: Tue, 18 Dec 2001 08:51:58 -0800
Date: Tue, 18 Dec 2001 10:45:19 -0600
From: Ben Mack-Crane <[email-masked]>
To: John Drake <[email-masked]>
CC: [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

See in-line.

Regards,
Ben

John Drake wrote:
> 
> -----Original Message-----
> From: Ben Mack-Crane [mailto:[email-masked]]
> Sent: Wednesday, December 12, 2001 10:10 AM
> To: Jonathan Lang
> Cc: John Drake; Lou Berger; Kireeti Kompella; [email-masked]
> Subject: Re: Moving right along ... generalized-signaling-06
> 
> Jonathan,
> 
> I agree that both the working and recovery paths must be connected
> and carrying traffic (except at the egress).  It is a problem that
> the term "primary" is being overloaded to indicate both "working"
> and "connected in transit nodes".
> 
> JD:  The fact that you don't understand the semantics of the
> Primary/Secondary
> bit doesn't necessarily mean that they're incorrect

The fact that the semantics are unclear, and in fact misleading,
is a problem.

> 
> If it is an endpoint decision as to which is the working and which
> is the recovery path, this seems to add more complexity to the
> operator's job in setting up protected paths.
> 
> JD:  Assertion

What do operator's think about having provision the signaled path
AND separately configure the protection in the endpoints?  What if
only a part of the path needs protection?

> 
> It would seem quite
> reasonable to signal which path is which.
> 
> JD:  And why would the intermediate nodes care?

The same could be said for G-PID!

> 
> Regards,
> Ben
> 
> Jonathan Lang wrote:
> >
> > Ben,
> >   Please see inline.
> >
> > Thanks,
> > Jonathan
> >
> > > -----Original Message-----
> > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > Sent: Wednesday, December 12, 2001 8:56 AM
> > > To: John Drake
> > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > Subject: Re: Moving right along ... generalized-signaling-06
> > >
> > >
> > > See comment below.
> > >
> > > Regards,
> > > Ben
> > >
> > > John Drake wrote:
> > > >
> > > > Snipped
> > > >
> > > > -----Original Message-----
> > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > Sent: Tuesday, December 11, 2001 6:38 AM
> > > > To: Lou Berger
> > > > Cc: Kireeti Kompella; [email-masked]
> > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > >
> > > > >
> > > > > >
> > > > > >7) In Protection Information it states "The resources
> > > allocated for a
> > > > > >    secondary LSP MAY be used by other LSPs until the
> > > primary LSP fails
> > > > > >    over to the secondary LSP."  This may not always be
> > > the case.  An
> > > > > >    explicit flag indicating whether or not extra
> > > traffic may use the
> > > > > >    secondary path resources is needed.
> > > > >
> > > > > ??? This is the purpose of this bit.
> > > >
> > > > This is not clear from the definition.  The bit is defined
> > > as indicating
> > > > the LSP is a secondary (or protecting) LSP and in 1+1 protection the
> > > > secondary LSP may not be used for extra traffic.
> > > >
> > > > Perhaps the problem here is that protection features are
> > > being defined
> > > > before the protection framework and requirements are done.  Is this
> > > > presupposing some particular outcome of the recovery work in CAMP?
> > > >
> > > > JD:  I think the definition of the bit is fine.  For both
> > > 1+1 and 1:1
> > > > protection, there would be a pair of Primary LSPs between the source
> > > > and destination, rather than a Primary and a Secondary.
> > >
> > > This is an unusual use of terms.  I have never encountered a case
> > > where both the working and recovery paths are call "primary."
> > >
> > > This is not consistent with either draft-mpls-recovery-framework
> > > or with draft-lang-ccamp-recovery.  I think this is a sign that the
> > > protection work is immature and not ready for progressing to RFC.
> > >
> > For 1+1 path protection, both working/recovery paths are carrying user
> data
> > traffic and it is an endpoint decision as to which path is actually the
> > working/recovery path.  At a transit node, both paths need to be treated
> as
> > primary, as the resources are currently being used and obviously can't be
> > used for Extra Traffic.

Delivery-date: Tue, 18 Dec 2001 08:32:54 -0800
Date: Tue, 18 Dec 2001 11:33:48 -0500
From: Srinivasa Datari <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Question on LMP Link Summary Nack msg

Hi,

If a TE link correlation fails (while processing a Link Summary msg), the Link
Summary Nack msg only provides an error code (bit value 0x04 - Bad Received
Remote_Link_Id) to indicate this failure. To help determine which TE link
failed, would it be useful to include the failed TE link object as part of the
Link Summary Nack msg ?

The new Link Summary Nack msg can be of the form:

<LinkSummaryNack Message> ::= <Common Header> <MESSAGE_ID_ACK> <ERROR_CODE>
				[<TE_LINK>] [<DATA_LINK>...]

Thanks,
Srini Datari.

Delivery-date: Tue, 18 Dec 2001 08:26:00 -0800
Date: Tue, 18 Dec 2001 10:16:53 -0600
From: Ben Mack-Crane <[email-masked]>
To: CCAMP <[email-masked]>
Subject: GMPLS Issue - Notify Message

The following issue raised 10/29/01 has not been addressed:

> > >7) The Notify message is intended to "enable expedited notification of
> > >    failures," but it relies on the IP layer which may be affected by the
> > >    failure that the Notify is reporting.  This could defeat the goal
> > >    of rapid notification.  Without some means of guaranteeing the Notify
> > >    doesn't have to wait for IP routing convergence to be delivered,
> > >    it isn't a satisfactory solution.
> > >

Delivery-date: Tue, 18 Dec 2001 08:19:42 -0800
Date: Tue, 18 Dec 2001 10:15:12 -0600
From: Ben Mack-Crane <[email-masked]>
To: CCAMP <[email-masked]>
Subject: GMPLS Issue - Switching Type

In a brief discussion at the IETF meeting I was told that
Switching Type really is Multiplexing Type, that is, HOW the 
LSP is to be carried over a link (not what is switched or 
how it is switched).

This raises a set of issues that have not yet been discussed.
The first of these is: What problem is this solving?

Regards,
Ben Mack-Crane

The following issue raised 10/29/01 has not been addressed:

>Switching Type continues to be ill-defined.  I have heard that the real
>definition is different from that given in the current drafts.  If the
>signaling information is not clearly defined and it's use described, we
>can hardly expect interoperability.

I can't speak for others.  My belief is that there is a very concrete 
definition.   I thought the text in the draft was clear as well, but let me 
try again:

         Switching Type: 8 bits

         Indicates the type of switching that should be performed
         on a particular link.  This field is needed for links that
         advertise more than one type of switching capability.
         This field contains one of the values advertised for the
         corresponding link in the routing Switching Capability
         field as defined in [GMPLS-RTG].

In other words, on links where one Switching Capability is advertised 
(which will be all the time for most equipment) Switching Type is set to 
the same value as advertised in routing.  On links where multiple Switching 
Capabilities are advertised, Switching Type is set to the value advertised 
in Switching Capability that matches the type of switching to be performed.

[I'll put the revised text in the next rev...]

Delivery-date: Tue, 18 Dec 2001 08:09:55 -0800
Date: Tue, 18 Dec 2001 10:04:40 -0600
From: Ben Mack-Crane <[email-masked]>
To: CCAMP <[email-masked]>
Subject: GMPLS Issue - Protection Information

The following issue raised 10/29/01 has not been addressed:
(There are other active threads on this.)

> >7) In Protection Information it states "The resources allocated for a
> >    secondary LSP MAY be used by other LSPs until the primary LSP fails
> >    over to the secondary LSP."  This may not always be the case.  An
> >    explicit flag indicating whether or not extra traffic may use the
> >    secondary path resources is needed.
> 
> ??? This is the purpose of this bit.

This is not clear from the definition.  The bit is defined as indicating
the LSP is a secondary (or protecting) LSP and in 1+1 protection the
secondary LSP may not be used for extra traffic.

Perhaps the problem here is that protection features are being defined
before the protection framework and requirements are done.  Is this
presupposing some particular outcome of the recovery work in CAMP?

Delivery-date: Tue, 18 Dec 2001 08:06:22 -0800
Date: Tue, 18 Dec 2001 09:59:13 -0600
From: Ben Mack-Crane <[email-masked]>
To: CCAMP <[email-masked]>
Subject: GMPLS Issue - Bandwidth Encoding

The following issue raised 10/29/01 has not been addressed:

> >4) In the "Bandwidth Encoding" section it states "For non-packet LSPs, it
> >    is useful to define discrete values to identify the bandwidth of the
> >    LSP."  For SONET/SDH this is unnecessary given the Signal Type is
> >    provided.  For the other non-packet LSP types (Lambda and Fiber)
> >    it is not clear that all the values cited in the example are relevant
> >    (for example, a DS0 lambda would seem wasteful...).
> 
> >    This is confusing, and should be clarified.  In fact, a description of
> >    exactly why this field is required is needed.
> 
> We've gone over this text multiple times.  Do you have any suggested wording.
> 

I would gladly suggest wording if I understood the use for this.  It has no use
for Packet, PDH, SDH/SONET, or "Digital Wrapper," so I assume it is for Lambda
or Fiber.  However, several of the examples are not appropriate for this.
Perhaps this should be moved to a technology specific document since it is
not really general anyway.

Delivery-date: Tue, 18 Dec 2001 08:05:43 -0800
Date: Tue, 18 Dec 2001 10:00:53 -0600
From: Ben Mack-Crane <[email-masked]>
To: CCAMP <[email-masked]>
Subject: GMPLS Issue - Waveband

The following issue raised 10/29/01 has not been addressed:

> >6) The definition of Start Label and End Label in waveband switching seems
> >    inconsistent with the behavior described in generalized-rsvp-te-05.
> 
> I don't see this.  Feel free to suggest wording.

Does anyone else see an inconsistency here?  I would be interested in hearing
from someone who understands the waveband content.

I am concerned that the waveband proposal is speculative and not ready to
progress toward RFC status.  Perhaps the waveband content should be removed
and the sections marked FFS.

Delivery-date: Tue, 18 Dec 2001 08:00:14 -0800
Date: Tue, 18 Dec 2001 09:55:56 -0600
From: Ben Mack-Crane <[email-masked]>
To: CCAMP <[email-masked]>
Subject: GMPLS Issue - Ethernet LSP Enc Type

The following issue raised 10/29/01 has not been addressed.

> >1) There seems to be no difference as far as label allocation
> >    is concerned between LSP Encoding Types Ethernet V2/DIX (2)
> >    and Ethernet 802.3 (10).  One Encoding type would seem to
> >    be sufficient.
> 
> I agree, but some feel that this is needed to properly establish LSPs in
> systems what would terminate each type differently.

I don't recall seeing anything on the list about the reasoning about this.
can someone provide a pointer to where this was described?

Since LSP Encoding type is intended to describe the LSP for transit nodes
and G-PID is intended to describe the LSP contents for the purpose of
terminating it at the ends, information relevant only to termination
should be conveyed in G-PID.

Perhaps changing the name of this LSP Encoding Type to "Ethernet Phy"
would make this clearer.

Delivery-date: Tue, 18 Dec 2001 07:15:46 -0800
Cc: Lou Berger <[email-masked]>, [email-masked]
Date: Tue, 18 Dec 2001 16:12:53 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Markus Jork <[email-masked]>
Original-CC: Lou Berger <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... generalized-rsvp-te-05

This is a multi-part message in MIME format.
--------------A86F327437182D66D2D265AD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Markus, John, Lou, Manoj,

I also still have a major issue to understand the switching type... or more
precise I have the feeling it is too coarse and ill defined. Let me provide some
more examples to evaluate:

Frist Markus' network example... it will look like the following in reality

 R1 ------ OXC1 ------ OXC2 ------ R2
     OC-N        OC-N        OC-N

              OC-N trail
  |<------------------------------>|

             STS-Nc trail
 |<-------------------------------->|

              IP Link
|<---------------------------------->|

I assume that OXC1/2 are all optical cross connects which pass through the
complete OC-N signals.

In order to route IP packets between R1 and R2, you need to set up an OC-N trail
between R1 and R2. Once this is done, you need to set up a STS-Nc trail between
R1 and R2. Once this is done you have an IP link with a bandwidth of 9 584 640
kbit/s established between R1 and R2. Now IP signals can flow between R1 and R2.

Now make the example a bit more complex and let me add a SONET cross connect in
the chain.

 R1 ------ OXC1 ------ OXC2 ------ DXC1 ------ R2
     OC-N        OC-N        OC-N        OC-N

              OC-N trail              OC-N trail
  |<------------------------------>|  |<------>|

                  STS-Nc trail
 |<-------------------------------------------->|

                      IP Link
|<---------------------------------------------->|

The physical interface in each case is an OC-N. The DXC1 is a SONET cross
connect, which terminates the OC-N Section and Line layers and forwards the
STS-Nc signal.

What would the switching types be in this case when an LSP is requested between
R1 and R2?

Now assume that the transport network contains some OTN OXCs interconnected via
40G wavelengths. The Routers are having STM-16 physical interfaces with VC-4-16c
path signal carrying IP traffic. The DXC1 is a SDH cross connect with an OTN
OTM-0.3 (i.e. 40G) interface, which is carrying ODU1 (2G5) signals with STM-16
inside.

 R1 -------- OXC1 ---------- OXC2 ---------- OXC3 --------- DXC1 -------- R2
     STM-16        OTM-64.3        OTM-40.3        OTM-0.3        STM-16

                           OCh trail
                |<-------------------------->|

                              ODU3 trail
               |<----------------------------------------->|

                                 ODU1 trail
             |<-------------------------------------------->|  
               
                          STM-16 trail                        STM-16 trail
  |<-------------------------------------------------------->||<-------->|

                             VC-4-16c trail
 |<---------------------------------------------------------------------->|

                                 IP Link
|<------------------------------------------------------------------------>|

What would the switching types be in this case when an LSP is requested between
R1 and R2?

But a router may also connect via a GE interface. The ethernet frames are then
forwarded in OXC1 via a virtual concatenated VC-4-Xv to R2 (which has a STM-16
interface supporting VC-4-Xv). As VC-4-Xv signals can only be carried in sTM-N
signals, there is an STM-16 trail between OXC1 and DXC1. There is another STM-16
trail between DXC1 and R2.
The OXCs are part of an OTN network, so the STM-16 that is created in the OXC1
is mapped into an ODU1 and this ODU1 is switched to an OTM-64.3 port. In this
port the ODU1 signal is TDM multiplexed into an ODU3 and this ODU3 is put onto a
wavelenght (via OTU3V and OCh). OXC2 is an OCh (all optical) switch, capable to
forward the true wavelenght signal between the two OTM-64.3 and OTM-40.3 line
ports. The OCh signal is terminated in the OTM-40.3 line port in OXC3 and the
ODU3 is switched to the egress OTM-0.3 interface port. Arriving at DXC1, the
ODu3 is terminated, the ODU1 is demultiplexed from the ODU3, the ODU1 is
terminated and the STM-16 is extracted. Then the sTM-16 is terminated and the X
VC-4 signals are switched to the egress STM-16 signal. At R2 the STM-16 signal
is terminated, the X-VC-4 signals are connected to the VC-4-Xv port and
terminated making the  ethernet frames available. The ehternet frames are
terminated and the IP packets are now accessible.

 R1 ------ OXC1 ---------- OXC2 ---------- OXC3 --------- DXC1 -------- R2
     1 GE        OTM-64.3        OTM-40.3        OTM-0.3        STM-16

                           OCh trail
              |<-------------------------->|

                              ODU3 trail
             |<----------------------------------------->|

                                 ODU1 trail
            |<-------------------------------------------->|  
               
   GE trail                   STM-16 trail                    STM-16 trail
  |<----->||<---------------------------------------------->||<-------->|

                             VC-4-Xv (X=1..7) trail
          |<------------------------------------------------------------>|

                             Ethernet MAC link
 |<---------------------------------------------------------------------->|

                                 IP Link
|<------------------------------------------------------------------------>|

Question is again the switching types you will see when requesting a LSP between
R1 and R2.

Regards,

Maarten

Markus Jork wrote:
> Let's look at the example of two IP routers connected to a cloud of
> opaque OXCs:
> 
> R1 ----- OXC1 ----- OXC2 ----- R2
>     LSC        LSC        PSC
> 
> OXC1 and OXC2 switch the Sonet stream from an incoming interface to
> some outgoing interface, that's why links R1-OXC1 and OXC1-OCX2
> are advertised as LSC in the IGP. Link OXC2-R2 is PSC because R2 looks
> at the incoming IP packets. The encoding on the links is OC192.
> 
> Now I want to setup an LSP between R1 and R2. (This LSP is essentially
> a "lightpath" through the optical cloud and will be advertised as FA
> so that PSC LSPs can be tunneled through it later.)
> What is the switching type requested in the Generalized Label Request
> object? I would expect LSC.
> But section 2.1 of draft-ietf-mpls-generalized-rsvp-te-06 says:
> 
>    A Generalized Label Request object is set by the ingress node,
>    transparently passed by transit nodes, and used by the egress node.
> 
> This would suggest the switching type needs to be PSC.
> But then the text in 2.1.1 says:
> 
>    Nodes MUST verify that the type indicated in the Switching Type
>    parameter is supported on the corresponding incoming interface.  If
>    the type cannot be supported, the node MUST generate a PathErr
>    message with a "Routing problem/Switching Type" indication.
> 
> So when the Path message requested PSC, it would be rejected by OXC1
> and OXC2. When it requested LSC it would be rejected by R2.
> The transit nodes can't modify the switching type in the Path message
> because they don't have enough knowledge to pick the right one.
> How is this supposed to work?
> 
> thanks for any clarification,
> Markus
--------------A86F327437182D66D2D265AD
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------A86F327437182D66D2D265AD--

Delivery-date: Mon, 17 Dec 2001 19:14:10 -0800
From: John Drake <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>
Cc: Maarten Vissers <[email-masked]>, [email-masked]
Subject: RE: Moving right along ... generalized-signaling-06
Date: Mon, 17 Dec 2001 19:11:47 -0800

Steven,

The basic idea is that if a connection is of type 'secondary', then other
LSPs of type 'primary' between the same or different source/destination
pairs MAY use its resources in intermediate nodes, until that LSP is
converted into a 'primary' with a subsequent Path/Resv flow.  At this point,
other LSPs that were using its resources may get pre-empted.  Think of the
primary/secondary mechanism as a way to ensure temporal priority while
allowing network resources to be re-used; i.e., an LSP of type 'secondary'
is carrying no data.

So in the 1:1 case the protect LSP could be established either as a primary
or secondary LSP, while in the 1:N case the protect LSP would be established
as a secondary.

Thanks,

John 

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Thursday, December 13, 2001 12:15 PM
To: John Drake
Cc: Maarten Vissers; [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

John,
It would seem from this standpoint, ANY transport plane protection
must use "primary" for all trails. You have already made this argument
for the 1+1 case to carry the permanently bridged copy of the payload.

In 1:1 or 1:n, when protection is not being used to carry one/any of
the normal traffic signals, it may either carry a null signal (no bridge)
or transport plane extra traffic. Even if the transport plane has only
a null signal on protection, the control plane cannot itself place extra
traffic on any portion of the end-to-end protection channel as this is
where the APS protocol is carried to coordinate the 1:1 or 1:n protection.
The protection channel overhead is chosen to carry the APS since it is
necessary to exchange APS bytes to complete a switch when working channels
are failed. If the protection channel has failed and APS cannot be
exchanged,
normal traffic signals will not be selected from protection.
Regards,
Steve

John Drake wrote:
> 
> Maarten,
> 
> That's fine, however it's beside the point.  The semantics of
> Primary/Secondary refer to the control plane and whether the node
> establishing a given LSP is planning to use it at the time it's
established
> or at a later time.  As I indicated in an earlier note, 1+1 transport
plane
> protection would be accomplished in the control plane by establishing two
> LSPs of type Primary.  The control plane really doesn't care which LSP the
> transport plane is using as Working and which as Protect, although that
> information is available to the control plane at the LSP endpoints.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Thursday, December 13, 2001 12:15 AM
> To: [email-masked]
> Subject: Re: Moving right along ... generalized-signaling-06
> 
> There exist well defined protection terminology in ITU-T for the transport
> plane. "Working" and "Protection" are being used and not
primary/secondary.
> E.g.
> a 1+1 architecture has one working connection, one protection connection
and
> a
> permanent bridge.
> 
> Besides working/protection indication for the transport entity, there is
> - "active" and "standby" to indicate if the signal is selected from the
> working
> or protection transport entity; i.e. if selector selects from working, the
> working is active and protection is standby, if the selector selects from
> protection the working is standby and the protection is active.
> - "normal" and "extra traffic" signal. The normal signal is protected.
> 
> Regards,
> 
> Maarten
> 
> [email-masked] wrote:
> >
> > Jonathan....review the text below....I think the problem is 1:1.
> >
> > neil
> >
> > > -----Original Message-----
> > > From: Jonathan Lang [mailto:[email-masked]]
> > > Sent: 12 December 2001 17:46
> > > To: 'Ben Mack-Crane'; John Drake
> > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > Subject: RE: Moving right along ... generalized-signaling-06
> > >
> > >
> > > Ben,
> > >   Please see inline.
> > >
> > > Thanks,
> > > Jonathan
> > >
> > > > -----Original Message-----
> > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > Sent: Wednesday, December 12, 2001 8:56 AM
> > > > To: John Drake
> > > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > >
> > > >
> > > > See comment below.
> > > >
> > > > Regards,
> > > > Ben
> > > >
> > > > John Drake wrote:
> > > > >
> > > > > Snipped
> > > > >
> > > > > -----Original Message-----
> > > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > > Sent: Tuesday, December 11, 2001 6:38 AM
> > > > > To: Lou Berger
> > > > > Cc: Kireeti Kompella; [email-masked]
> > > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > > >
> > > > > >
> > > > > > >
> > > > > > >7) In Protection Information it states "The resources
> > > > allocated for a
> > > > > > >    secondary LSP MAY be used by other LSPs until the
> > > > primary LSP fails
> > > > > > >    over to the secondary LSP."  This may not always be
> > > > the case.  An
> > > > > > >    explicit flag indicating whether or not extra
> > > > traffic may use the
> > > > > > >    secondary path resources is needed.
> > > > > >
> > > > > > ??? This is the purpose of this bit.
> > > > >
> > > > > This is not clear from the definition.  The bit is defined
> > > > as indicating
> > > > > the LSP is a secondary (or protecting) LSP and in 1+1
> > > protection the
> > > > > secondary LSP may not be used for extra traffic.
> > > > >
> > > > > Perhaps the problem here is that protection features are
> > > > being defined
> > > > > before the protection framework and requirements are
> > > done.  Is this
> > > > > presupposing some particular outcome of the recovery work in CAMP?
> > > > >
> > > > > JD:  I think the definition of the bit is fine.  For both
> > > > 1+1 and 1:1
> > > > > protection, there would be a pair of Primary LSPs between
> > > the source
> > > > > and destination, rather than a Primary and a Secondary.
> > > >
> > > > This is an unusual use of terms.  I have never encountered a case
> > > > where both the working and recovery paths are call "primary."
> > > >
> > > > This is not consistent with either draft-mpls-recovery-framework
> > > > or with draft-lang-ccamp-recovery.  I think this is a sign that the
> > > > protection work is immature and not ready for progressing to RFC.
> > > >
> > > For 1+1 path protection, both working/recovery paths are
> > > carrying user data
> > > traffic and it is an endpoint decision as to which path is
> > > actually the
> > > working/recovery path.  At a transit node, both paths need to
> > > be treated as
> > > primary, as the resources are currently being used and
> > > obviously can't be
> > > used for Extra Traffic.
> > >

Delivery-date: Mon, 17 Dec 2001 15:04:09 -0800
From: Joe Dumont <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Addition to Deletion Proc for GMPLS RSVP
Date: Mon, 17 Dec 2001 17:03:29 -0600

Hello,

Section 7.2.2 of generalized-rsvp-te-06 does not appear cover the case of an Egress initiated deletion where the ingress node does not support admin status. 

I suggest the following additional wording to be added to the end of section 7.2.2 to clarify this additional error procedure:

"In the case of a non-supporting ingress node, a PathTear may not be returned when an egress node sends a Resv with D and R bits set. To support the case of non-supporting ingress node, the egress SHOULD only wait a configurable period of time for the PathTear message to be returned. Once the period of time has elapsed, the egress node sends a ResvTear message or a PathErr message with Path_state_removed flag set, and normal RSVP takes place. By default for this period SHOULD be 30 seconds."

Regards,

Joe

Delivery-date: Mon, 17 Dec 2001 14:38:04 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: RE: Fwd: Comments on GMPLS signalling drafts
Date: Mon, 17 Dec 2001 15:37:09 -0700

Hi Vishal,
           Thanks a lot for the clarifications. John Drake mentioned in one 
of his responses that a LSC FA-LSP can be advertised in routing
with different switching type (i.e. TDM). It means an FA can be
advertised using switching type that is different from the switching
type of the LSP that created the FA. I don't think this is mentioned
in any of the drafts. Please let me know if I m missing something.

Following was my main concern :

A LSP that is established with switching type say X (X=PSC/LSC/FSC/TDM)
and advertised as a FA with different switching type say Y (X != Y)
then what all the possible combinatios of X and Y ?

Regards,
manoj.

>From: "Vishal Sharma" <[email-masked]>
>Reply-To: <[email-masked]>
>To: "manoj juneja" <[email-masked]>, <[email-masked]>
>CC: <[email-masked]>, <[email-masked]>, 
><[email-masked]>
>Subject: RE: Fwd: Comments on GMPLS signalling drafts
>Date: Mon, 17 Dec 2001 10:10:55 -0800
>
>Manoj,
>
>I just got to my email after a hiatus, and saw your question on
>tunnelling at the end of this email (I've deleted all the rest).
>Since there seems to have been much debate on this, and you
>brought it up yet again, I thought it appropriate to answer.
>
>Actually, I don't understand where the confusion is. I think John Drake
>already answered this question, both in his reply directly to you,
>and again, in his observations on Juergen's email (the one where
>Juergen tried to explain his understanding of FA's etc.).
>
>The basic answer is that the lambda LSP will be advertised in routing,
>and stored in the TED at A and D, as a TDM-capable FA LSP.
>From that point forward, nodes A and D will exchange TDM labels for
>any TDM LSP being setup over this FA LSP(those labels will of course
>follow all the layering rules that Maarten and Juergen have been
>talking about, and the label requests themselves will be tunnelled
>directly from A to D; for example, over the SONET/SDH section or line
>DCC). In fact, one could view this FA LSP as a "one-hop"
>TDM link, with all the properties of a TDM link.
>
>More specifically, all TDM LSPs tunneled through the
>FA LSP will *not* be allocated the same label (this is a physical
>impossibility in a circuit switched network in any case). Rather,
>they will each be allocated a label that denotes the time slots
>on the FA LSP (now viewed as TDM capable) that each TDM LSP will
>use.
>
>(BTW, you might also find a presentation
>I gave at MPLSCon'01 in March this year on this very subject useful to
>clarify some of your doubts (there are some pictures there that
>are useful for visualizing these scenarios).)
>
>Finally, I saw in one of your earlier emails on this subject a request,
>which seemed to boil down to asking that every possible scenario
>be outlined in some document or the other. While, in general, I am
>supportive of making things clear (and I've expressed that viewpoint
>several times on this list and the MPLS list over the past couple years),
>in this particular case, I think you might be asking for too much!
>Doing that is practically impossible.
>
>Once the building blocks are specified (and I support that they be
>specified as clearly as possible), the compositions of these blocks
>is something that has to be done depending on the specific applications
>that one intends to use these blocks for.
>
>-Vishal
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On
>Behalf Of manoj juneja
>Sent: Friday, December 14, 2001 3:33 PM
>To: [email-masked]
>Cc: [email-masked]; [email-masked];
>[email-masked]
>Subject: Re: Fwd: Comments on GMPLS signalling drafts
>
>
>Hi Lou/Eric/Dimitri,
>
>   Please see the following para from gmpls-architecture draft :
>
><snip>
>
> >From: Lou Berger <[email-masked]>
> >To: "manoj juneja" <[email-masked]>
> >CC: <[email-masked]>,<[email-masked]>,
> ><[email-masked]>
> >Subject: Re: Fwd: Comments on GMPLS signalling drafts
> >Date: Fri, 14 Dec 2001 15:18:34 -0500
> >
> >see comments inline.
> >
> >At 09:10 PM 12/13/2001, manoj juneja wrote:
> >
> >
> >
> >> >From: "manoj juneja" <[email-masked]>
> >> >To: [email-masked]
> >> >Subject: Comments on GMPLS signalling drafts
> >> >Date: Tue, 11 Dec 2001 16:15:10 -0700
> >> >
> >> >Hi All,
> >> >
> >> >1. SE-style supported by GMPLS or not ?
> >> >
>
><<snip>>
>
> >> >8. The LSP hierarchy concept is still not clear. Some days back I 
>posted
> >> >one
> >> >doubt related to tunneling of TDM LSP over Lambda LSP using the 
>concept
> >>of
> >> >forwarding adjacency and different people replied with different
> >>thoughts.
> >> >Does this mean this concept is not standardized in GMPLS ?
> >> >My question was :
> >> >
> >> >"If there are 4 nodes say A, B, C and D. There is a Lambda FA
> >> >established from A to D and if a new TDM LSP request comes to node A
> >> >which is to be tunneled through the already established lambda FA-LSP
> >> >then the node A sends the Path/label request message directly to node
> >> >D. What label the node D will send back to node A in the RESV/label
> >> >mapping message since the FA-LSP is just one label (lambda) ? Does it
> >> >mean that all the LSPs which are tunneled through the lambda FA-LSP
> >> >will be allocated the same label by node D to node A ? If this type of
> >> >scenario can't exist in GMPLS then please let me know that too."
> >
> >I believe this topic is being covered in other threads.
> >
>
>

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

Delivery-date: Mon, 17 Dec 2001 14:20:43 -0800
content-class: urn:content-classes:message
Subject: RE: GMPLS signaling documents updated per last calls
Date: Mon, 17 Dec 2001 17:20:10 -0500
From: "Brungard, Deborah A, ALCTA" <[email-masked]>
To: "Lou Berger" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

On the mpls-generalized-signaling draft, can someone please summarize =
the agreements regarding the LSP encoding types? I previously made the =
comments to merge the (1) SDH and SONET values as one value (i.e. ITU-T =
G.707)and (2) ANSI PDH and ETSI PDH values as one value (i.e. ITU-T =
PDH)? The latest draft does not show any changes on the LSP encoding =
types.

Deborah Brungard
AT&T

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Monday, December 10, 2001 4:05 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: GMPLS signaling documents updated per last calls

All,
	As was discussed in this morning's SUB-IP session, the GMPLS signaling=20
documents have been updated to reflect comments received during the=20
extended last call.  If you believe an issue that you have previously=20
raised has not been addressed in the drafts, please send a message to =
the=20
list.  (We'll respond with either how the issue was addressed or if it =
was=20
missed.)

Here's a summary of changes:

draft-ietf-mpls-generalized-signaling-07.txt
see http://www.labn.net/docs/diff-sig-06-07.txt for change bar version.
o changes were primarily in the area of GPID values.
	(Juergen has a couple of additions that we'll incorporate in next rev.)

draft-ietf-mpls-generalized-rsvp-te-06.txt
see http://www.labn.net/docs/diff-rsvp-05-06.txt
o Minor editorial changes and clarifications based on comments from list

draft-ietf-mpls-generalized-cr-ldp-05.txt
http://www.labn.net/docs/diff-ldp-04-05.txt
o Brings cr-ldp functionally in line with rsvp-te
o Revised Admin Status Usage (per comments and also removed potential =
race=20
condition)
o Clarified text related to interface bundling (To be consistent with=20
updated bundling draft.)
o Added IANA Considerations
o Minor editorial changes and clarifications

Lou

Delivery-date: Mon, 17 Dec 2001 14:17:13 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Moving right along ... generalized-rsvp-te-05
Date: Mon, 17 Dec 2001 15:15:40 -0700

Markus,
        I think first u have to create an FA between R1-OXC1-OXC2 with
switching type LSC. If u want to tunnel the packet traffic over this FA
-LSC LSP then u need to send another LSP request (Path message) with
switching type as PSC from R1 to OXC2. The path message will directly
be sent by R1 to OXC-2 (as R1 and OXC-2 are the end-points of the FA).
The OXC-2 will have to trigger new LSP from OXC-2 to R2 with switching
type PSC.

Lou, please correct me if I am wrong.

Regards,
manoj.

>From: Markus Jork <[email-masked]>
>To: Lou Berger <[email-masked]>
>CC: [email-masked]
>Subject: Re: Moving right along ... generalized-rsvp-te-05
>Date: Mon, 17 Dec 2001 16:39:18 -0500
>
>Lou,
>
>I think there is still some confusion in the draft regarding
>the switching type. Of course it could also be that the draft
>is perfectly clear and I'm confused...
>
>Quoting a response you gave to Manoj/Ben:
>
> > > >
> > > > >A Tunnel (FA) is a type
> > > > >    of link, not a class of switching.  This adds to the
> > > > >    confusion I've noted about the need for and use of Switching
> > > > >    Type.
> > >
> > >Switching Type continues to be ill-defined.  I have heard that the real
> > >definition is different from that given in the current drafts.  If the
> > >signaling information is not clearly defined and it's use described, we
> > >can hardly expect interoperability.
> >
> > I can't speak for others.  My belief is that there is a very concrete
> > definition.   I thought the text in the draft was clear as well, but let 
>me
> > try again:
> >
> >
> >          Switching Type: 8 bits
> >
> >          Indicates the type of switching that should be performed
> >          on a particular link.  This field is needed for links that
> >          advertise more than one type of switching capability.
> >          This field contains one of the values advertised for the
> >          corresponding link in the routing Switching Capability
> >          field as defined in [GMPLS-RTG].
> >
> > In other words, on links where one Switching Capability is advertised
> > (which will be all the time for most equipment) Switching Type is set to
> > the same value as advertised in routing.  On links where multiple 
>Switching
> > Capabilities are advertised, Switching Type is set to the value 
>advertised
> > in Switching Capability that matches the type of switching to be 
>performed.
> >
> > [I'll put the revised text in the next rev...]
> >
>
>Let's look at the example of two IP routers connected to a cloud of
>opaque OXCs:
>
>R1 ----- OXC1 ----- OXC2 ----- R2
>     LSC        LSC        PSC
>
>OXC1 and OXC2 switch the Sonet stream from an incoming interface to
>some outgoing interface, that's why links R1-OXC1 and OXC1-OCX2
>are advertised as LSC in the IGP. Link OXC2-R2 is PSC because R2 looks
>at the incoming IP packets. The encoding on the links is OC192.
>
>Now I want to setup an LSP between R1 and R2. (This LSP is essentially
>a "lightpath" through the optical cloud and will be advertised as FA
>so that PSC LSPs can be tunneled through it later.)
>What is the switching type requested in the Generalized Label Request
>object? I would expect LSC.
>But section 2.1 of draft-ietf-mpls-generalized-rsvp-te-06 says:
>
>    A Generalized Label Request object is set by the ingress node,
>    transparently passed by transit nodes, and used by the egress node.
>
>This would suggest the switching type needs to be PSC.
>But then the text in 2.1.1 says:
>
>    Nodes MUST verify that the type indicated in the Switching Type
>    parameter is supported on the corresponding incoming interface.  If
>    the type cannot be supported, the node MUST generate a PathErr
>    message with a "Routing problem/Switching Type" indication.
>
>So when the Path message requested PSC, it would be rejected by OXC1
>and OXC2. When it requested LSC it would be rejected by R2.
>The transit nodes can't modify the switching type in the Path message
>because they don't have enough knowledge to pick the right one.
>How is this supposed to work?
>
>thanks for any clarification,
>Markus
>
>
>

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

Delivery-date: Mon, 17 Dec 2001 13:44:11 -0800
From: Markus Jork <[email-masked]>
To: Lou Berger <[email-masked]>
cc: [email-masked]
Subject: Re: Moving right along ... generalized-rsvp-te-05 
Date: Mon, 17 Dec 2001 16:39:18 -0500

Lou,

I think there is still some confusion in the draft regarding
the switching type. Of course it could also be that the draft
is perfectly clear and I'm confused...

Quoting a response you gave to Manoj/Ben:

> > >
> > > >A Tunnel (FA) is a type
> > > >    of link, not a class of switching.  This adds to the
> > > >    confusion I've noted about the need for and use of Switching
> > > >    Type.
> >
> >Switching Type continues to be ill-defined.  I have heard that the real
> >definition is different from that given in the current drafts.  If the
> >signaling information is not clearly defined and it's use described, we
> >can hardly expect interoperability.
> 
> I can't speak for others.  My belief is that there is a very concrete 
> definition.   I thought the text in the draft was clear as well, but let me 
> try again:
> 
> 
>          Switching Type: 8 bits
> 
>          Indicates the type of switching that should be performed
>          on a particular link.  This field is needed for links that
>          advertise more than one type of switching capability.
>          This field contains one of the values advertised for the
>          corresponding link in the routing Switching Capability
>          field as defined in [GMPLS-RTG].
> 
> In other words, on links where one Switching Capability is advertised 
> (which will be all the time for most equipment) Switching Type is set to 
> the same value as advertised in routing.  On links where multiple Switching 
> Capabilities are advertised, Switching Type is set to the value advertised 
> in Switching Capability that matches the type of switching to be performed.
> 
> [I'll put the revised text in the next rev...]
> 

Let's look at the example of two IP routers connected to a cloud of
opaque OXCs:

R1 ----- OXC1 ----- OXC2 ----- R2
    LSC        LSC        PSC

OXC1 and OXC2 switch the Sonet stream from an incoming interface to
some outgoing interface, that's why links R1-OXC1 and OXC1-OCX2
are advertised as LSC in the IGP. Link OXC2-R2 is PSC because R2 looks
at the incoming IP packets. The encoding on the links is OC192.

Now I want to setup an LSP between R1 and R2. (This LSP is essentially
a "lightpath" through the optical cloud and will be advertised as FA
so that PSC LSPs can be tunneled through it later.)
What is the switching type requested in the Generalized Label Request
object? I would expect LSC.
But section 2.1 of draft-ietf-mpls-generalized-rsvp-te-06 says:

   A Generalized Label Request object is set by the ingress node,
   transparently passed by transit nodes, and used by the egress node.

This would suggest the switching type needs to be PSC.
But then the text in 2.1.1 says:

   Nodes MUST verify that the type indicated in the Switching Type
   parameter is supported on the corresponding incoming interface.  If
   the type cannot be supported, the node MUST generate a PathErr
   message with a "Routing problem/Switching Type" indication.

So when the Path message requested PSC, it would be rejected by OXC1
and OXC2. When it requested LSC it would be rejected by R2.
The transit nodes can't modify the switching type in the Path message
because they don't have enough knowledge to pick the right one.
How is this supposed to work?

thanks for any clarification,
Markus 

Delivery-date: Mon, 17 Dec 2001 10:22:54 -0800
Date: Mon, 17 Dec 2001 13:19:33 -0500
To: "Kullberg, Alan" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: RE: Fwd: Comments on GMPLS signalling drafts
Cc: <[email-masked]>

At 12:57 PM 12/17/2001, Kullberg, Alan wrote:

>Lou,
>
>See comments below.
>
>Alan
>
> > -----Original Message-----
> > From: Lou Berger [<mailto:[email-masked]>mailto:[email-masked]]
> > Sent: Friday, December 14, 2001 3:19 PM
> > To: manoj juneja
> > Cc: [email-masked]; [email-masked];
> > [email-masked]
> > Subject: Re: Fwd: Comments on GMPLS signalling drafts
> >
> >
> > see comments inline.
> >
> > At 09:10 PM 12/13/2001, manoj juneja wrote:
> >
> >
> >
> > > >From: "manoj juneja" <[email-masked]>
> > > >To: [email-masked]
> > > >Subject: Comments on GMPLS signalling drafts
> > > >Date: Tue, 11 Dec 2001 16:15:10 -0700
> > > >
>
>[snip, snip]
>
> > > >4. For IF_ID_RSVP_HOP object, there are couple of TLVs
> > defined. What
> > > >about the Component_If_Id_Downstream/Upstream TLV ? The revised
> > > >bundling draft has removed these 2 TLVs. What about the
> > GMPLS signalling
> > > >drafts ?
> > > >
> >
> > It's still in, see the drafts for explanations.
>
> From section 8.1 of draft-ietf-mpls-generalized-rsvp-te-06.txt,
>
>    In all cases but bundling, see [MPLS-BUNDLE], the
>    upstream interface is implied by the downstream interface.  For
>    bundling, the path sender explicitly identifies the component
>    interface used in each direction.
>
>The latest bundling draft (draft-ietf-mpls-bundle-01.txt) doesn't
>support this statement as far as I can tell.  The bundling draft
>now specifies to use type 1, 2, or 3 in the IF_ID TLV, but never
>type 4 or 5.  This is in conflict with generalized-rsvp-te-06.
>I don't think the bundle draft can be used as the reference here
>or in generalized-signaling-07, section 9.1.1, since there is a
>contradicion between the 2 drafts.

The reference is to provide context on bundling, not operation.  The 
reference will be dropped.

Lou

Delivery-date: Mon, 17 Dec 2001 10:13:37 -0800
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "manoj juneja" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Fwd: Comments on GMPLS signalling drafts
Date: Mon, 17 Dec 2001 10:10:55 -0800

Manoj,

I just got to my email after a hiatus, and saw your question on
tunnelling at the end of this email (I've deleted all the rest).
Since there seems to have been much debate on this, and you
brought it up yet again, I thought it appropriate to answer.

Actually, I don't understand where the confusion is. I think John Drake
already answered this question, both in his reply directly to you,
and again, in his observations on Juergen's email (the one where
Juergen tried to explain his understanding of FA's etc.).

The basic answer is that the lambda LSP will be advertised in routing,
and stored in the TED at A and D, as a TDM-capable FA LSP.
>From that point forward, nodes A and D will exchange TDM labels for
any TDM LSP being setup over this FA LSP(those labels will of course
follow all the layering rules that Maarten and Juergen have been
talking about, and the label requests themselves will be tunnelled
directly from A to D; for example, over the SONET/SDH section or line
DCC). In fact, one could view this FA LSP as a "one-hop"
TDM link, with all the properties of a TDM link.

More specifically, all TDM LSPs tunneled through the
FA LSP will *not* be allocated the same label (this is a physical
impossibility in a circuit switched network in any case). Rather,
they will each be allocated a label that denotes the time slots
on the FA LSP (now viewed as TDM capable) that each TDM LSP will
use.

(BTW, you might also find a presentation
I gave at MPLSCon'01 in March this year on this very subject useful to
clarify some of your doubts (there are some pictures there that
are useful for visualizing these scenarios).)

Finally, I saw in one of your earlier emails on this subject a request,
which seemed to boil down to asking that every possible scenario
be outlined in some document or the other. While, in general, I am
supportive of making things clear (and I've expressed that viewpoint
several times on this list and the MPLS list over the past couple years),
in this particular case, I think you might be asking for too much!
Doing that is practically impossible.

Once the building blocks are specified (and I support that they be
specified as clearly as possible), the compositions of these blocks
is something that has to be done depending on the specific applications
that one intends to use these blocks for.

-Vishal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of manoj juneja
Sent: Friday, December 14, 2001 3:33 PM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: Fwd: Comments on GMPLS signalling drafts

Hi Lou/Eric/Dimitri,

  Please see the following para from gmpls-architecture draft :

<snip>

>From: Lou Berger <[email-masked]>
>To: "manoj juneja" <[email-masked]>
>CC: <[email-masked]>,<[email-masked]>,
><[email-masked]>
>Subject: Re: Fwd: Comments on GMPLS signalling drafts
>Date: Fri, 14 Dec 2001 15:18:34 -0500
>
>see comments inline.
>
>At 09:10 PM 12/13/2001, manoj juneja wrote:
>
>
>
>> >From: "manoj juneja" <[email-masked]>
>> >To: [email-masked]
>> >Subject: Comments on GMPLS signalling drafts
>> >Date: Tue, 11 Dec 2001 16:15:10 -0700
>> >
>> >Hi All,
>> >
>> >1. SE-style supported by GMPLS or not ?
>> >

<<snip>>

>> >8. The LSP hierarchy concept is still not clear. Some days back I posted
>> >one
>> >doubt related to tunneling of TDM LSP over Lambda LSP using the concept
>>of
>> >forwarding adjacency and different people replied with different
>>thoughts.
>> >Does this mean this concept is not standardized in GMPLS ?
>> >My question was :
>> >
>> >"If there are 4 nodes say A, B, C and D. There is a Lambda FA
>> >established from A to D and if a new TDM LSP request comes to node A
>> >which is to be tunneled through the already established lambda FA-LSP
>> >then the node A sends the Path/label request message directly to node
>> >D. What label the node D will send back to node A in the RESV/label
>> >mapping message since the FA-LSP is just one label (lambda) ? Does it
>> >mean that all the LSPs which are tunneled through the lambda FA-LSP
>> >will be allocated the same label by node D to node A ? If this type of
>> >scenario can't exist in GMPLS then please let me know that too."
>
>I believe this topic is being covered in other threads.
>

Delivery-date: Mon, 17 Dec 2001 09:59:13 -0800
From: "Kullberg, Alan" <[email-masked]>
To: [email-masked]
Subject: RE: Fwd: Comments on GMPLS signalling drafts
Date: Mon, 17 Dec 2001 12:57:55 -0500

Lou,

See comments below.

Alan

> -----Original Message-----
> From: Lou Berger [mailto:[email-masked]]
> Sent: Friday, December 14, 2001 3:19 PM
> To: manoj juneja
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: Fwd: Comments on GMPLS signalling drafts
> 
> 
> see comments inline.
> 
> At 09:10 PM 12/13/2001, manoj juneja wrote:
> 
> 
> 
> > >From: "manoj juneja" <[email-masked]>
> > >To: [email-masked]
> > >Subject: Comments on GMPLS signalling drafts
> > >Date: Tue, 11 Dec 2001 16:15:10 -0700
> > >

[snip, snip]

> > >4. For IF_ID_RSVP_HOP object, there are couple of TLVs 
> defined. What
> > >about the Component_If_Id_Downstream/Upstream TLV ? The revised
> > >bundling draft has removed these 2 TLVs. What about the 
> GMPLS signalling
> > >drafts ?
> > >
> 
> It's still in, see the drafts for explanations.

>From section 8.1 of draft-ietf-mpls-generalized-rsvp-te-06.txt,

   In all cases but bundling, see [MPLS-BUNDLE], the
   upstream interface is implied by the downstream interface.  For
   bundling, the path sender explicitly identifies the component
   interface used in each direction.

The latest bundling draft (draft-ietf-mpls-bundle-01.txt) doesn't
support this statement as far as I can tell.  The bundling draft
now specifies to use type 1, 2, or 3 in the IF_ID TLV, but never
type 4 or 5.  This is in conflict with generalized-rsvp-te-06.
I don't think the bundle draft can be used as the reference here
or in generalized-signaling-07, section 9.1.1, since there is a
contradicion between the 2 drafts.

Delivery-date: Mon, 17 Dec 2001 09:19:35 -0800
content-class: urn:content-classes:message
Subject: RE: Intra-area Crankback
Date: Mon, 17 Dec 2001 12:16:33 -0500
From: "Ash, Gerald R (Jerry), ALCTA" <[email-masked]>
To: "Don Fedyk" <[email-masked]>
Cc: "Ash, Gerald R (Jerry), ALCTA" <[email-masked]>, "Adrian Farrel" <[email-masked]>, "Atsushi Iwata" <[email-masked]>, "Norihito Fujita" <[email-masked]>, "Simon Marshall-Unitt" <[email-masked]>, "ccamp" <[email-masked]>

Hi Don,

don> The feedback draft is intended for this type of operation.=20
don> Feedback is best within the area crank back is best outside=20
don> the area. We discussed all of this with the original authors=20
don> many many times.=20
don> Crankback is a primitive from of feedback.=20

I recall perhaps one or two 'hallway discussions' along this line.  =
Personally I think that feedback and crankback do different things, one =
is not a replacement for the other.  Feedback feeds information to the =
TED, crankback is a reroute-notify to the head-end or border LSR.  One =
can emulate a 'crankback' with a failure-notify, just as well as =
interpreting a feedback TLV as a 'crankback'.  It is not the same as =
crankback nor a replacement for it.

Both can provide needed functionality.

Regards,
Jerry

Delivery-date: Mon, 17 Dec 2001 01:30:50 -0800
Date: Mon, 17 Dec 2001 10:25:41 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

This is a multi-part message in MIME format.
--------------A81E68D66DFC5BFCA0B54BC3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

All,

I agree with John that the set up of the working and protection connections will
be done by means of the set up of two normal connections with the constraint
that those have to be diverse routed. 
The role these two diverse routed connections play has only relevance at the
head and tail ends of the protected domain; not at any intermediate point along
the connections.

As I indicated in my presentation on Wednesday evening, connection set up has
multiple phases:
- connection bearer set up
- connection monitoring set up
- connection protection set up.

The latter one refers to the set up of the head/tail end connection functions
which include the bridges and selectors. 
	Note that I ignore for this moment the Dual Node Interconnect (DNI) 
	cases (see G.842) in which some intermediate nodes do have to know 
	about protection.
In section 3.2 of SG15 contribution D.301
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICATIONS/ccamp/301_ww2.pdf
you find a high level overview of linear protection switching related management
parameters:
- Architecture Type (1+1, 1:n, ..)
- Switching Type (uni-directional, bi-directional)
- Operation Type (revertive, non-revertive)
- Protection Type (trail, SNC/I, SNC/N, SNC/S)
- Extra Traffic
- SFPriority, SDPriority
- Wait To Restore time
- Hold Off time

	Note - the shared protection ring (MS Spring/BLSR and in future 
	OCH SPRing and ODUk SPRing) (will) have their own set of parameters.

When a call controller receives a request for a connection, it may decide that
it must create a protected connection to compy with the QoS parameters
associated with the call. The call controller then issues two connection
requests to a connection controller, with the constraint to diverse route the
two connections between the head end and tail end of the protected domain.

At this point we have to differentiate between native connection requests and
client connection requests. For the case there is a native connection request,
the protection will be of the SubNetwork Connection (SNC) type. For the case
there is a client connection request, the protection type may be of the SNC
type, or may be of the trail protection type.

	Example 1: If a VC-4 call is to be supported by means of a protected
	VC-4 connection, then VC-4 SNC protection will have to be deployed.

	Example 2: If a STM-16 call is to be supported by means of a 
	protected ODU1 connection then there is a choice to use either ODU1
	trail protection or ODU1 SNC protection.

Instead that the network call controller decides that a call is to be supported
by a protected connection, the user may decide such and request for two diverse
routed connections. The head/tail ends are then within the user domain.

	Example 3: If a user wants a protected STM-16 connection between 
	e.g. two of its SDH equipment, it will set up a STM-16 MS trail
	protected port in its own equipment and request two diverse routed 
	connections from the network.

In addition to the above two cases, there can be a 3rd hybrid case; i.e. one
bridge/seelctor pair is in the user domain and the other bridge/selector pair is
in the network domain.

When SNC protection is applicable, the fabrics will contain the protection
switch processes. Two (case of 1+1, 1:1) regular connections between the
first/last fabric in the protected domain are to be set up. Depending on the
protection type, either no monitors have to be activated (SNC/I), or non
intrusive monitors (SNC/N) have to be activated, or tandem connection monitoring
functions have to be activated (SNC/S).

When trail protection is applicable, the ports (not the fabrics) will contain
the protection switch processes. Two (case of 1+1, 1:1) regular connections have
to be set up between the working interface points of the protected ports and
between the protection interface points of the protected ports. The ports
include already the monitoring functionalities, so no specific action for
monitoring selection is required in this case.

The connection set up process must take care to provide the monitors in either
case with the correct parameter values. Parameters are associated with the
following monitoring processes: trace identifier, error detection, alarm
reporting modes (TPmode, ARCmode), TCM level.

With the connection and monitoring functions being set up, the protection
processes at each endpoint can now be configured. I.e. the set of protection
parameters listed at the begin of this email have to get values assigned.

	Note - As the connection protection set up hasn't been architected 
	yet in ASON, it is undecided if the call controller or the 
	connection controllers will be responsible for the head/tail end 
	set up.

For the case the connections have to pass multiple subnetworks or routing
domains, the first and last subnetwork/routing domain may have a hybrid casen
(including one portected domain end point), whereas any intermediate
subnetwork/routing area has the case of two diverse routed connections (and no
protected domain endpoints).

Up to so far.

Regards,

Maarten
PS. I hadn't seen "primary" before as an indication of connection set up. It
seems unnecessary to add this adjective if it isn't used when setting up an
unprotected connection.

John Drake wrote:
> 
> Maarten,
> 
> That's fine, however it's beside the point.  The semantics of
> Primary/Secondary refer to the control plane and whether the node
> establishing a given LSP is planning to use it at the time it's established
> or at a later time.  As I indicated in an earlier note, 1+1 transport plane
> protection would be accomplished in the control plane by establishing two
> LSPs of type Primary.  The control plane really doesn't care which LSP the
> transport plane is using as Working and which as Protect, although that
> information is available to the control plane at the LSP endpoints.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Thursday, December 13, 2001 12:15 AM
> To: [email-masked]
> Subject: Re: Moving right along ... generalized-signaling-06
> 
> There exist well defined protection terminology in ITU-T for the transport
> plane. "Working" and "Protection" are being used and not primary/secondary.
> E.g.
> a 1+1 architecture has one working connection, one protection connection and
> a
> permanent bridge.
> 
> Besides working/protection indication for the transport entity, there is
> - "active" and "standby" to indicate if the signal is selected from the
> working
> or protection transport entity; i.e. if selector selects from working, the
> working is active and protection is standby, if the selector selects from
> protection the working is standby and the protection is active.
> - "normal" and "extra traffic" signal. The normal signal is protected.
> 
> Regards,
> 
> Maarten
> 
> [email-masked] wrote:
> >
> > Jonathan....review the text below....I think the problem is 1:1.
> >
> > neil
> >
> > > -----Original Message-----
> > > From: Jonathan Lang [mailto:[email-masked]]
> > > Sent: 12 December 2001 17:46
> > > To: 'Ben Mack-Crane'; John Drake
> > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > Subject: RE: Moving right along ... generalized-signaling-06
> > >
> > >
> > > Ben,
> > >   Please see inline.
> > >
> > > Thanks,
> > > Jonathan
> > >
> > > > -----Original Message-----
> > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > Sent: Wednesday, December 12, 2001 8:56 AM
> > > > To: John Drake
> > > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > >
> > > >
> > > > See comment below.
> > > >
> > > > Regards,
> > > > Ben
> > > >
> > > > John Drake wrote:
> > > > >
> > > > > Snipped
> > > > >
> > > > > -----Original Message-----
> > > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > > Sent: Tuesday, December 11, 2001 6:38 AM
> > > > > To: Lou Berger
> > > > > Cc: Kireeti Kompella; [email-masked]
> > > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > > >
> > > > > >
> > > > > > >
> > > > > > >7) In Protection Information it states "The resources
> > > > allocated for a
> > > > > > >    secondary LSP MAY be used by other LSPs until the
> > > > primary LSP fails
> > > > > > >    over to the secondary LSP."  This may not always be
> > > > the case.  An
> > > > > > >    explicit flag indicating whether or not extra
> > > > traffic may use the
> > > > > > >    secondary path resources is needed.
> > > > > >
> > > > > > ??? This is the purpose of this bit.
> > > > >
> > > > > This is not clear from the definition.  The bit is defined
> > > > as indicating
> > > > > the LSP is a secondary (or protecting) LSP and in 1+1
> > > protection the
> > > > > secondary LSP may not be used for extra traffic.
> > > > >
> > > > > Perhaps the problem here is that protection features are
> > > > being defined
> > > > > before the protection framework and requirements are
> > > done.  Is this
> > > > > presupposing some particular outcome of the recovery work in CAMP?
> > > > >
> > > > > JD:  I think the definition of the bit is fine.  For both
> > > > 1+1 and 1:1
> > > > > protection, there would be a pair of Primary LSPs between
> > > the source
> > > > > and destination, rather than a Primary and a Secondary.
> > > >
> > > > This is an unusual use of terms.  I have never encountered a case
> > > > where both the working and recovery paths are call "primary."
> > > >
> > > > This is not consistent with either draft-mpls-recovery-framework
> > > > or with draft-lang-ccamp-recovery.  I think this is a sign that the
> > > > protection work is immature and not ready for progressing to RFC.
> > > >
> > > For 1+1 path protection, both working/recovery paths are
> > > carrying user data
> > > traffic and it is an endpoint decision as to which path is
> > > actually the
> > > working/recovery path.  At a transit node, both paths need to
> > > be treated as
> > > primary, as the resources are currently being used and
> > > obviously can't be
> > > used for Extra Traffic.
> > >
--------------A81E68D66DFC5BFCA0B54BC3
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------A81E68D66DFC5BFCA0B54BC3--

Delivery-date: Sun, 16 Dec 2001 11:45:38 -0800
Date: Sun, 16 Dec 2001 14:18:47 -0500
To: "Adrian Farrel" <[email-masked]>
From: Thomas Nadeau <[email-masked]>
Subject: Re: MIBs for GMPLS
Cc: "Joan Cucchiara" <[email-masked]>, <[email-masked]>, "Tim Hall" <[email-masked]>, "Edward Harrison" <[email-masked]>, "Cheenu Srinivasan" <[email-masked]>

At 11:51 PM 12/14/2001 -0500, Adrian Farrel wrote:
> > > We considered several approaches to producing GMPLS MIBs and 
> presented these
>in
> > > London (if the slides are not still on the Web site I can mail them to
>anyone
> > > interested).
> >
> > Which web site?
>
>IETF.
>I'll mail you under separate cover.
>
> > > The options were...
> > > 1. Recycle the existing MIBs
> > > 2. Add extensions to the existing MIBs as new tables and AUGMENTS
> > > 3. Completely rewrite the MIBs
> > > 4. Make version 2 MIBs
>
>[SNIP]
> > So the decision was for #4 Make Version 2 of the MIBs.
> >
> > Why then are you not calling these LSRv2-MIB and MPLS-TEv2-MIB, etc. ?
> > That is what is typically done.
>
>SNaFU.

         They are not called LSRv2 etc... because they support enhanced
functionality for GMPLS that "classic" MPLS cannot handle.  They are
intended to represent a superset of functions -- classic MPLS being
a superset.  Our thinking was that calling them v2 would just confuse
things. Perhaps we have done this anyway.

> > Further, if these are supposed to eventuall replace documents in the
> > MPLS working group, then isn't it appropriate to let that be known?
> > I have seen no such postings to that working group.
>
>Replace may be too strong a word.  Does the v1 MIB actually need to be 
>retired?
>
>You're correct that we haven't posted widely on the these MIBs yet.  They
>haven't existed long.
>
>I did send a note to the MPLS mailing list when we published the MIBs and
>invited the discussion to be joined on the ccamp list.  It is a good idea to
>send a reminder - I will.
>
> > I do think this is probably a good way to go (although it was not
> > clear from anything that I've read that that was the intent
> > until you explained it here.  Thanks for the explanation.
>
>Good, I'm glad you support the approach,
>
> > > > Also the Labels MIB is glumping everything into
> > > > a single table.  Was the use of separate tables (similar
> > > > to what LDP did for ATM and FR specific objects)
> > > > considered?
> > >
> > > Good choice of word, "glumping".  I confess that I was never a fan of the
> > > multiple table approach!
> > >
> > > >From an implementation point of view there is need be no impact 
> (although I
>can
> > > conceive of implementations where this is not the case :-).  The 
> conformance
> > > statement (of course, should make it clear that implementations can 
> support
> > > whatever set of label-types they like.  Note that an important 
> consideration
>is
> > > the type of labels reported from the network which may not match those
>supported
> > > locally.
> > >
> > > Hope this answers you.
> >
> > Not really.  This is not an implementation issue, it is a MIB design
> > issue.  I think it is sloppy (another highly technical term like
> > glumping ;) to have MIBs look like C union structures. Sorry to be
> > so terse, but I would *hope* the IETF would raise the bar on MIB
> > quality just a tad.  You have no idea if the way the MIB is currently
> > written would be less difficult to implement for most folks.
> > In fact, I would argue just the opposite; based on my experience
> > a poorly designed MIB is far more difficult to implement because
> > it is difficult to understand and it becomes difficult to maintain and
> > scale over time as deprecations/extentions are needed.
>
>OK. Probably bringing implementation into it is not going to help us much.  I
>have plenty of experience of MIB implementation and would not propose 
>anything I
>considered hard to implement, but as you say that is not the issue.

         The idea was not to discuss implementations, but to use existing ones
as a measure of how difficult it would be to support the new ones. Thus
far, it does not seem like it is that difficult to support the new functions
and the old ones on boxes that support both.

>The issue is doing the correct MIB-like thing.
>
>You are suggesting a label table for each type of label.  Presumably the
>referencing object still contains a simple index, and the table to index is
>deduced from the label type.

         We had thought of using this approach, but in the end it seemed like
having one table for all labels (with a label type) was the simplest approach.

>Note that we did not want to use rowPointer because we wanted to facilitate
>non-use of the Label Table in 32 bit label systems by direct inclusion of the
>label (as in the current MIBs).

         Yes.

         --Tom

>We'll think about this a bit.
>
>Thanks,
>Adrian
>--
>Adrian Farrel
>Movaz Networks Inc.
>Tel: 703-847-1867
>[email-masked]

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 

Delivery-date: Sun, 16 Dec 2001 06:09:17 -0800
Date: Sun, 16 Dec 2001 09:03:39 -0500
To: Joan Cucchiara <[email-masked]>
From: Thomas Nadeau <[email-masked]>
Subject: Re: MIBs for GMPLS
Cc: Adrian Farrel <[email-masked]>, [email-masked], Tim Hall <[email-masked]>, Edward Harrison <[email-masked]>, Cheenu Srinivasan <[email-masked]>

         Hi Joan,

>Why is there so much overlap between these
>MIBs and the MIBs in MPLS?
>It seems that the MPLS MIBs could be extended
>for GMPLS specific info and thus avoid so much
>overlap.  Could you shed some light on this?

         The idea was to leverage as much of the "classic"
MIBs as possible.  We originally tried extending the
"classic" MIBs, but it turned out to be quite a problem
and made the MIBs resemble a pile of bailing wire
and bubble gum, especially for those tables which were indexed
by labels (LSR and TE hop tables, for example).

>Also the Labels MIB is glumping everything into
>a single table.  Was the use of separate tables (similar
>to what LDP did for ATM and FR specific objects)
>considered?

         The motivation here was to be able to implement
the GMPLS TE MIB without the GMPLS LSR MIB.
The dependency from the TE MIB is really on the label
table, so pulling this out seemed to make sense for those
only wishing to implement the GMPLS TE MIB first.

         --Tom

>   Thanks, Joan
>
> > Adrian Farrel wrote:
> >
> > At the CCAMP meeting in SLC Tom introduced the set of MIBs for GMPLS
> > that we have produced.
> >
> > Kireeti asked that we take the MIBs to the list to ensure that the big
> > issues have been addressed, that everyone is comfortable with the
> > approach and there really is a need for the MIBs.
> >
> > Requirements are handled by...
> >
> > - protocols within the IETF need MIBs, further
> >   draft-ietf-ccamp-gmpls-architecture-01.txt
> >   explicitly requires MIBs for GMPLS
> >
> > The biggest issue outstanding was whether the Labels MIB should be
> > included within the LSR MIB.  The authors currently feel that it
> > should remain as a separate MIB
> >
> > - to allow people to implement only the TE MIB
> >   without putting complex conformance statements
> >   in the LSR MIB
> > - to allow people to clearly not implement the
> >   Labels MIB at all.
> > We would welcome input on this.
> >
> >
> > Please take this opportunity to give us your input and help shape the
> > MIBs.
> >
> > We hope to respin the drafts in a compilable form in the next few
> > days.
> >
> >
> > The MIBs are...
> >
> > 
> http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-tc-mib-00.txt
> > 
> http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-label-mib-00.txt
> > 
> http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-te-mib-00.txt
> > 
> http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-lsr-mib-00.txt
> >
> >
> > Regards,
> > Adrian
> >
> > --
> > Adrian Farrel
> > Movaz Networks Inc.
> > Tel: 703-847-1867
> > [email-masked]

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 

Envelope-to: [email-masked]
Delivery-date: Fri, 14 Dec 2001 20:54:37 -0800
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Joan Cucchiara" <[email-masked]>
Cc: <[email-masked]>, "Tim Hall" <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>, "Edward Harrison" <[email-masked]>, "Cheenu Srinivasan" <[email-masked]>
Subject: Re: MIBs for GMPLS
Date: Fri, 14 Dec 2001 23:51:34 -0500

> > We considered several approaches to producing GMPLS MIBs and presented these
in
> > London (if the slides are not still on the Web site I can mail them to
anyone
> > interested).
>
> Which web site?

IETF.
I'll mail you under separate cover.

> > The options were...
> > 1. Recycle the existing MIBs
> > 2. Add extensions to the existing MIBs as new tables and AUGMENTS
> > 3. Completely rewrite the MIBs
> > 4. Make version 2 MIBs

[SNIP]
> So the decision was for #4 Make Version 2 of the MIBs.
>
> Why then are you not calling these LSRv2-MIB and MPLS-TEv2-MIB, etc. ?
> That is what is typically done.

SNaFU.

> Further, if these are supposed to eventuall replace documents in the
> MPLS working group, then isn't it appropriate to let that be known?
> I have seen no such postings to that working group.

Replace may be too strong a word.  Does the v1 MIB actually need to be retired?

You're correct that we haven't posted widely on the these MIBs yet.  They
haven't existed long.

I did send a note to the MPLS mailing list when we published the MIBs and
invited the discussion to be joined on the ccamp list.  It is a good idea to
send a reminder - I will.

> I do think this is probably a good way to go (although it was not
> clear from anything that I've read that that was the intent
> until you explained it here.  Thanks for the explanation.

Good, I'm glad you support the approach,

> > > Also the Labels MIB is glumping everything into
> > > a single table.  Was the use of separate tables (similar
> > > to what LDP did for ATM and FR specific objects)
> > > considered?
> >
> > Good choice of word, "glumping".  I confess that I was never a fan of the
> > multiple table approach!
> >
> > >From an implementation point of view there is need be no impact (although I
can
> > conceive of implementations where this is not the case :-).  The conformance
> > statement (of course, should make it clear that implementations can support
> > whatever set of label-types they like.  Note that an important consideration
is
> > the type of labels reported from the network which may not match those
supported
> > locally.
> >
> > Hope this answers you.
>
> Not really.  This is not an implementation issue, it is a MIB design
> issue.  I think it is sloppy (another highly technical term like
> glumping ;) to have MIBs look like C union structures. Sorry to be
> so terse, but I would *hope* the IETF would raise the bar on MIB
> quality just a tad.  You have no idea if the way the MIB is currently
> written would be less difficult to implement for most folks.
> In fact, I would argue just the opposite; based on my experience
> a poorly designed MIB is far more difficult to implement because
> it is difficult to understand and it becomes difficult to maintain and
> scale over time as deprecations/extentions are needed.

OK. Probably bringing implementation into it is not going to help us much.  I
have plenty of experience of MIB implementation and would not propose anything I
considered hard to implement, but as you say that is not the issue.

The issue is doing the correct MIB-like thing.

You are suggesting a label table for each type of label.  Presumably the
referencing object still contains a simple index, and the table to index is
deduced from the label type.

Note that we did not want to use rowPointer because we wanted to facilitate
non-use of the Label Table in 32 bit label systems by direct inclusion of the
label (as in the current MIBs).

We'll think about this a bit.

Thanks,
Adrian
--
Adrian Farrel
Movaz Networks Inc.
Tel: 703-847-1867
[email-masked]

Delivery-date: Fri, 14 Dec 2001 15:36:03 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: Re: Fwd: Comments on GMPLS signalling drafts
Date: Fri, 14 Dec 2001 16:32:41 -0700

Hi Lou/Eric/Dimitri,

  Please see the following para from gmpls-architecture draft :

   "LSP modification consists in changing some LSP parameters, but
   normally without changing the route. It is supported using the
   same mechanism as re-routing. However, the semantic of LSP
   modification will differ from one technology to the other. For
   instance, further studies are required to understand the impact
   of dynamically changing some SDH/SONET circuit characteristics such
   as the bandwidth, the protection type, the transparency, the
   concatenation etc."

If u say that SE style of reservation is supported then how are u going to 
share the bandwidth of SDH/SONET, Lambda or Fiber LSPs ? How can one assign 
diferent labels (labels are the physical resources on the link) to different 
senders that belong to the same RSVP session. Is it  that the SE style of 
reservation only supported to modify the bandwidth of LSP ? Can I modify the 
bandwidth of LSC/FSC LSP ? If yes then how ?

Do u people think that waveband section is compelte in the drafts ?

Please see other comments inline.

Regards,
manoj.

>From: Lou Berger <[email-masked]>
>To: "manoj juneja" <[email-masked]>
>CC: <[email-masked]>,<[email-masked]>, 
><[email-masked]>
>Subject: Re: Fwd: Comments on GMPLS signalling drafts
>Date: Fri, 14 Dec 2001 15:18:34 -0500
>
>see comments inline.
>
>At 09:10 PM 12/13/2001, manoj juneja wrote:
>
>
>
>> >From: "manoj juneja" <[email-masked]>
>> >To: [email-masked]
>> >Subject: Comments on GMPLS signalling drafts
>> >Date: Tue, 11 Dec 2001 16:15:10 -0700
>> >
>> >Hi All,
>> >
>> >1. SE-style supported by GMPLS or not ?
>> >
>
>GMPLS doesn't modify this.  See the appropriate base protocol docs.
>
>>As labels are the resources on the link, one can't allocate different
>> >label to different senders in the same RSVP session.
>> >
>
>I don't think you fully understand SE.  I suggest you read the base
>documents. (2205 and RSVP-TE)
>
>>
>> >2. Bandwidth modification for TDM, LSC and FSC LSPs. There is a
>> >separate draft for TDM LSP bandwidth modification but what about the
>> >bandwidth modification for other types of LSPs ? There is no mention of
>> >these in any of the GMPLS drafts.
>> >
>
>GMPLS doesn't modify this.  See the appropriate base protocol docs.
>
>>
>> >3. It should be mentioned clearly that waveband section is still not
>> >complete in the drafts.
>> >

>> >4. For IF_ID_RSVP_HOP object, there are couple of TLVs defined. What
>> >about the Component_If_Id_Downstream/Upstream TLV ? The revised
>> >bundling draft has removed these 2 TLVs. What about the GMPLS signalling
>> >drafts ?
>> >
>
>It's still in, see the drafts for explanations.
>
[Manoj]: What I want to say is that Component_If_Id_Downstream and Upstream 
TLVs of IF_ID_RSVP_HOP object have been removed from the bundling draft. Do 
u still want to keep these TLVs in GMPLS drafts ? If yes then is there any 
reason for keeping these ?

>> >5. STM-0 label representation using {SUKLM} should be mentioned in the
>> >drafts (because it is a special case).
>> >
>
>the sonet draft is the right place for this.  I defer to Eric on this.
>
[Manoj]: Thanks for putting this info in the new version of the draft.
>>
>> >6. It should be mentioned that bandwidth encoding parameter is useful
>> >for what all type of LSPs i.e. TDM, LSC, FSC, PSC etc.
>> >
[Manoj]: I think u should include what all technologies will make use of 
this parameter.

>> >7. There is an example scenario for contention resolution in case of bi-
>> >directional LSPs. It should be mentioned that  :
>> >
>> >"contention resolution is an optimization, not a correctness issue ...
>> >and no procedure can provide optimal resolution in all cases. An
>> >implementor
>> >may do differently to provide better resolution."
>> >
>> >The above quotes are extracted from one of the mails from Fong Liaw.
>> >
>> >If this is the case then this should be mentioned in the drafts.
>> >
>
>Read the Acknowledgments section of the draft.  (I'm sure Fong will be
>happy to see you protecting her interests!)
>
>>
>> >8. The LSP hierarchy concept is still not clear. Some days back I posted
>> >one
>> >doubt related to tunneling of TDM LSP over Lambda LSP using the concept 
>>of
>> >forwarding adjacency and different people replied with different 
>>thoughts.
>> >Does this mean this concept is not standardized in GMPLS ?
>> >My question was :
>> >
>> >"If there are 4 nodes say A, B, C and D. There is a Lambda FA
>> >established from A to D and if a new TDM LSP request comes to node A
>> >which is to be tunneled through the already established lambda FA-LSP
>> >then the node A sends the Path/label request message directly to node
>> >D. What label the node D will send back to node A in the RESV/label
>> >mapping message since the FA-LSP is just one label (lambda) ? Does it
>> >mean that all the LSPs which are tunneled through the lambda FA-LSP
>> >will be allocated the same label by node D to node A ? If this type of
>> >scenario can't exist in GMPLS then please let me know that too."
>
>I believe this topic is being covered in other threads.
>
>> >
>> >
>> >Regards,
>> >manoj.
>> >
>> >
>> >
>> >
>> >_________________________________________________________________
>> >Join the world s largest e-mail service with MSN Hotmail.
>> ><http://www.hotmail.com>http://www.hotmail.com
>> >
>> >
>>
>>_________________________________________________________________
>>Get your FREE download of MSN Explorer at
>><http://explorer.msn.com/intl.asp>http://explorer.msn.com/intl.asp.
>
>

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

Delivery-date: Fri, 14 Dec 2001 13:37:04 -0800
Date: Fri, 14 Dec 2001 13:33:21 -0800 (PST)
From: Fong Liaw <[email-masked]>
Subject: Re: Fwd: Comments on GMPLS signalling drafts
To: Lou Berger <[email-masked]>, manoj juneja <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]

Lou

I am happy to see my interest protected, however
I think manoj is asking to insert the "optimization
vs. correctness" text into the draft. Right now,
-07 text says a node with higher node id MUST send
a PathErr etc. this does not allow for different
behavior.

I would suggest to change the text slightly as
following:

"To resolve contention, the node with the higher node
ID will
   win the contention and it MUST issue a 
   ^^^ resolve 
PathErr/NOTIFICATION message
^^^^^^^PathErr/Path/Notification         
   with a "Routing problem/Label allocation failure"
indication.  " 
               ^ for the LSP that loses in the
resolution.

We can also specify the default behavior is that
"the LSP requested by a higher node id wins the 
resolution."

Regards,
-Fong

> > >
> > >7. There is an example scenario for contention
> resolution in case of bi-
> > >directional LSPs. It should be mentioned that  :
> > >
> > >"contention resolution is an optimization, not a
> correctness issue ...
> > >and no procedure can provide optimal resolution
> in all cases. An
> > >implementor
> > >may do differently to provide better resolution."
> > >
> > >The above quotes are extracted from one of the
> mails from Fong Liaw.
> > >
> > >If this is the case then this should be mentioned
> in the drafts.
> > >
> 
> Read the Acknowledgments section of the draft.  (I'm
> sure Fong will be 
> happy to see you protecting her interests!)
> 

__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com

Delivery-date: Fri, 14 Dec 2001 13:11:26 -0800
Date: Fri, 14 Dec 2001 16:04:33 -0500
From: Joan Cucchiara <[email-masked]>
Organization: Crescent Networks
To: Adrian Farrel <[email-masked]>
CC: [email-masked], Tim Hall <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>, Edward Harrison <[email-masked]>, Cheenu Srinivasan <[email-masked]>
Subject: Re: MIBs for GMPLS

Adrian Farrel wrote:
> 
> Hi Joan.
> 
> > Why is there so much overlap between these
> > MIBs and the MIBs in MPLS?
> >
> > It seems that the MPLS MIBs could be extended
> > for GMPLS specific info and thus avoid so much
> > overlap.  Could you shed some light on this?
> 
> Certainly.
> We considered several approaches to producing GMPLS MIBs and presented these in
> London (if the slides are not still on the Web site I can mail them to anyone
> interested).

Which web site?

> 
> The options were...
> 1. Recycle the existing MIBs
> 2. Add extensions to the existing MIBs as new tables and AUGMENTS
> 3. Completely rewrite the MIBs
> 4. Make version 2 MIBs
> 
> Now, the feeling (amongst the authors and the implementors that gave us
> feedback) was that there were two prime objectives:
> a. support 'classic' MPLS and GMPLS with the same set of MIBs
> b. cause minimal disruption to people who have implemented the existing MIBs and
> want to move forward to GMPLS.
> 
> This ruled out option 3 (for which we were all hugely greatful!)
> 
> Options 1 and 4 differ only in timing.  When we looked at the timescales to
> produce the GMPLS MIBs we realized that it was likely to take another few months
> before the MIBs were close to being last-callable.  On the other hand, the
> existing MIBs are through WG last call and undergoing final markups for the
> IESG.  The demand for the existing MIBs to reach a stable form is immense and so
> we decided to rule out option 1.
> 
> This leaves option 2 or option 4.
> 
> Although using augmentation seems attractive (it was my first attempt at doing
> this work) when you push into the corners you find that it gets very messy.
> This is not to say it isn't possible, but every table takes a hit.  Other issues
> were
> - new values for existing fields
> - the desirability of a change to indexing in the LSR MIB.
> 
> It was decided that the solution we were most comfortable with was producing a
> version 2 of the MIBs.  This is sufficiently close to version 1 to be
> - understandable by the same group of people
> - easy to modify implementations to support version 2 (or both versions)
> 
> We are, of course, open to persuasive discussion on this point
> 

So the decision was for #4 Make Version 2 of the MIBs.

Why then are you not calling these LSRv2-MIB and MPLS-TEv2-MIB, etc. ?
That is what is typically done.  Further, if these are supposed to
eventuall
replace documents in the MPLS working group, then isn't it appropriate
to let
that be known?  I have seen no such postings to that working group.

I do think this is probably a good way to go (although it was not 
clear from anything that I've read that that was the intent
until you explained it here.  Thanks for the explanation.

> > Also the Labels MIB is glumping everything into
> > a single table.  Was the use of separate tables (similar
> > to what LDP did for ATM and FR specific objects)
> > considered?
> 
> Good choice of word, "glumping".  I confess that I was never a fan of the
> multiple table approach!
> 
> >From an implementation point of view there is need be no impact (although I can
> conceive of implementations where this is not the case :-).  The conformance
> statement (of course, should make it clear that implementations can support
> whatever set of label-types they like.  Note that an important consideration is
> the type of labels reported from the network which may not match those supported
> locally.
> 
> Hope this answers you.

Not really.  This is not an implementation issue, it is a MIB design
issue.  I think it is sloppy (another highly technical term like
glumping ;) 
to have MIBs look like C union structures. Sorry to be
so terse, but I would *hope* the IETF would raise the bar on MIB 
quality just a tad.  You have no idea if the way the MIB is currently 
written would be less difficult to implement for most folks. 
In fact, I would argue just the opposite; based on my experience 
a poorly designed MIB is far more difficult to implement because
it is difficult to understand and it becomes difficult to maintain and
scale over time as deprecations/extentions are needed.  

  thanks, Joan

> 
> Regards,
> Adrian
> --
> Adrian Farrel
> Movaz Networks Inc.
> Tel: 703-847-1867
> [email-masked]

Delivery-date: Fri, 14 Dec 2001 12:40:17 -0800
Date: Fri, 14 Dec 2001 21:30:28 +0100
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: Lou Berger <[email-masked]>
CC: manoj juneja <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Fwd: Comments on GMPLS signalling drafts

This is a multi-part message in MIME format.
--------------1B4A3768514DBCD2DA4CC857
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all,

> > >5. STM-0 label representation using {SUKLM} should be mentioned in the
> > >drafts (because it is a special case).
> > >
> 
> the sonet draft is the right place for this.  I defer to Eric on this.

I refer Manoj to the latest versions of the Sonet/SDH I-Ds posted
on the CCAMP mailing list on Thursday.

Cheers,
- dimitri.

Lou Berger wrote:
> 
> see comments inline.
> 
> At 09:10 PM 12/13/2001, manoj juneja wrote:
> 
> > >From: "manoj juneja" <[email-masked]>
> > >To: [email-masked]
> > >Subject: Comments on GMPLS signalling drafts
> > >Date: Tue, 11 Dec 2001 16:15:10 -0700
> > >
> > >Hi All,
> > >
> > >1. SE-style supported by GMPLS or not ?
> > >
> 
> GMPLS doesn't modify this.  See the appropriate base protocol docs.
> 
> >As labels are the resources on the link, one can't allocate different
> > >label to different senders in the same RSVP session.
> > >
> 
> I don't think you fully understand SE.  I suggest you read the base
> documents. (2205 and RSVP-TE)
> 
> >
> > >2. Bandwidth modification for TDM, LSC and FSC LSPs. There is a
> > >separate draft for TDM LSP bandwidth modification but what about the
> > >bandwidth modification for other types of LSPs ? There is no mention of
> > >these in any of the GMPLS drafts.
> > >
> 
> GMPLS doesn't modify this.  See the appropriate base protocol docs.
> 
> >
> > >3. It should be mentioned clearly that waveband section is still not
> > >complete in the drafts.
> > >
> > >4. For IF_ID_RSVP_HOP object, there are couple of TLVs defined. What
> > >about the Component_If_Id_Downstream/Upstream TLV ? The revised
> > >bundling draft has removed these 2 TLVs. What about the GMPLS signalling
> > >drafts ?
> > >
> 
> It's still in, see the drafts for explanations.
> 
> > >5. STM-0 label representation using {SUKLM} should be mentioned in the
> > >drafts (because it is a special case).
> > >
> 
> the sonet draft is the right place for this.  I defer to Eric on this.
> 
> >
> > >6. It should be mentioned that bandwidth encoding parameter is useful
> > >for what all type of LSPs i.e. TDM, LSC, FSC, PSC etc.
> > >
> > >7. There is an example scenario for contention resolution in case of bi-
> > >directional LSPs. It should be mentioned that  :
> > >
> > >"contention resolution is an optimization, not a correctness issue ...
> > >and no procedure can provide optimal resolution in all cases. An
> > >implementor
> > >may do differently to provide better resolution."
> > >
> > >The above quotes are extracted from one of the mails from Fong Liaw.
> > >
> > >If this is the case then this should be mentioned in the drafts.
> > >
> 
> Read the Acknowledgments section of the draft.  (I'm sure Fong will be
> happy to see you protecting her interests!)
> 
> >
> > >8. The LSP hierarchy concept is still not clear. Some days back I posted
> > >one
> > >doubt related to tunneling of TDM LSP over Lambda LSP using the concept of
> > >forwarding adjacency and different people replied with different thoughts.
> > >Does this mean this concept is not standardized in GMPLS ?
> > >My question was :
> > >
> > >"If there are 4 nodes say A, B, C and D. There is a Lambda FA
> > >established from A to D and if a new TDM LSP request comes to node A
> > >which is to be tunneled through the already established lambda FA-LSP
> > >then the node A sends the Path/label request message directly to node
> > >D. What label the node D will send back to node A in the RESV/label
> > >mapping message since the FA-LSP is just one label (lambda) ? Does it
> > >mean that all the LSPs which are tunneled through the lambda FA-LSP
> > >will be allocated the same label by node D to node A ? If this type of
> > >scenario can't exist in GMPLS then please let me know that too."
> 
> I believe this topic is being covered in other threads.
> 
> > >
> > >
> > >Regards,
> > >manoj.
> > >
> > >
> > >
> > >
> > >_________________________________________________________________
> > >Join the world s largest e-mail service with MSN Hotmail.
> > ><http://www.hotmail.com>http://www.hotmail.com
> > >
> > >
> >
> >_________________________________________________________________
> >Get your FREE download of MSN Explorer at
> ><http://explorer.msn.com/intl.asp>http://explorer.msn.com/intl.asp.
--------------1B4A3768514DBCD2DA4CC857
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------1B4A3768514DBCD2DA4CC857--

Delivery-date: Fri, 14 Dec 2001 12:22:37 -0800
Date: Fri, 14 Dec 2001 15:18:34 -0500
To: "manoj juneja" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: Fwd: Comments on GMPLS signalling drafts
Cc: <[email-masked]>,<[email-masked]>, <[email-masked]>

see comments inline.

At 09:10 PM 12/13/2001, manoj juneja wrote:

> >From: "manoj juneja" <[email-masked]>
> >To: [email-masked]
> >Subject: Comments on GMPLS signalling drafts
> >Date: Tue, 11 Dec 2001 16:15:10 -0700
> >
> >Hi All,
> >
> >1. SE-style supported by GMPLS or not ?
> >

GMPLS doesn't modify this.  See the appropriate base protocol docs.

>As labels are the resources on the link, one can't allocate different
> >label to different senders in the same RSVP session.
> >

I don't think you fully understand SE.  I suggest you read the base 
documents. (2205 and RSVP-TE)

>
> >2. Bandwidth modification for TDM, LSC and FSC LSPs. There is a
> >separate draft for TDM LSP bandwidth modification but what about the
> >bandwidth modification for other types of LSPs ? There is no mention of
> >these in any of the GMPLS drafts.
> >

GMPLS doesn't modify this.  See the appropriate base protocol docs.

>
> >3. It should be mentioned clearly that waveband section is still not
> >complete in the drafts.
> >
> >4. For IF_ID_RSVP_HOP object, there are couple of TLVs defined. What
> >about the Component_If_Id_Downstream/Upstream TLV ? The revised
> >bundling draft has removed these 2 TLVs. What about the GMPLS signalling
> >drafts ?
> >

It's still in, see the drafts for explanations.

> >5. STM-0 label representation using {SUKLM} should be mentioned in the
> >drafts (because it is a special case).
> >

the sonet draft is the right place for this.  I defer to Eric on this.

>
> >6. It should be mentioned that bandwidth encoding parameter is useful
> >for what all type of LSPs i.e. TDM, LSC, FSC, PSC etc.
> >
> >7. There is an example scenario for contention resolution in case of bi-
> >directional LSPs. It should be mentioned that  :
> >
> >"contention resolution is an optimization, not a correctness issue ...
> >and no procedure can provide optimal resolution in all cases. An
> >implementor
> >may do differently to provide better resolution."
> >
> >The above quotes are extracted from one of the mails from Fong Liaw.
> >
> >If this is the case then this should be mentioned in the drafts.
> >

Read the Acknowledgments section of the draft.  (I'm sure Fong will be 
happy to see you protecting her interests!)

>
> >8. The LSP hierarchy concept is still not clear. Some days back I posted
> >one
> >doubt related to tunneling of TDM LSP over Lambda LSP using the concept of
> >forwarding adjacency and different people replied with different thoughts.
> >Does this mean this concept is not standardized in GMPLS ?
> >My question was :
> >
> >"If there are 4 nodes say A, B, C and D. There is a Lambda FA
> >established from A to D and if a new TDM LSP request comes to node A
> >which is to be tunneled through the already established lambda FA-LSP
> >then the node A sends the Path/label request message directly to node
> >D. What label the node D will send back to node A in the RESV/label
> >mapping message since the FA-LSP is just one label (lambda) ? Does it
> >mean that all the LSPs which are tunneled through the lambda FA-LSP
> >will be allocated the same label by node D to node A ? If this type of
> >scenario can't exist in GMPLS then please let me know that too."

I believe this topic is being covered in other threads.

> >
> >
> >Regards,
> >manoj.
> >
> >
> >
> >
> >_________________________________________________________________
> >Join the world s largest e-mail service with MSN Hotmail.
> ><http://www.hotmail.com>http://www.hotmail.com
> >
> >
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at 
><http://explorer.msn.com/intl.asp>http://explorer.msn.com/intl.asp.

Envelope-to: [email-masked]
Delivery-date: Fri, 14 Dec 2001 10:44:44 -0800
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Joan Cucchiara" <[email-masked]>
Cc: <[email-masked]>, "Tim Hall" <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>, "Edward Harrison" <[email-masked]>, "Cheenu Srinivasan" <[email-masked]>
Subject: Re: MIBs for GMPLS
Date: Fri, 14 Dec 2001 13:41:33 -0500

Hi Joan.

> Why is there so much overlap between these
> MIBs and the MIBs in MPLS?
>
> It seems that the MPLS MIBs could be extended
> for GMPLS specific info and thus avoid so much
> overlap.  Could you shed some light on this?

Certainly.
We considered several approaches to producing GMPLS MIBs and presented these in
London (if the slides are not still on the Web site I can mail them to anyone
interested).

The options were...
1. Recycle the existing MIBs
2. Add extensions to the existing MIBs as new tables and AUGMENTS
3. Completely rewrite the MIBs
4. Make version 2 MIBs

Now, the feeling (amongst the authors and the implementors that gave us
feedback) was that there were two prime objectives:
a. support 'classic' MPLS and GMPLS with the same set of MIBs
b. cause minimal disruption to people who have implemented the existing MIBs and
want to move forward to GMPLS.

This ruled out option 3 (for which we were all hugely greatful!)

Options 1 and 4 differ only in timing.  When we looked at the timescales to
produce the GMPLS MIBs we realized that it was likely to take another few months
before the MIBs were close to being last-callable.  On the other hand, the
existing MIBs are through WG last call and undergoing final markups for the
IESG.  The demand for the existing MIBs to reach a stable form is immense and so
we decided to rule out option 1.

This leaves option 2 or option 4.

Although using augmentation seems attractive (it was my first attempt at doing
this work) when you push into the corners you find that it gets very messy.
This is not to say it isn't possible, but every table takes a hit.  Other issues
were
- new values for existing fields
- the desirability of a change to indexing in the LSR MIB.

It was decided that the solution we were most comfortable with was producing a
version 2 of the MIBs.  This is sufficiently close to version 1 to be
- understandable by the same group of people
- easy to modify implementations to support version 2 (or both versions)

We are, of course, open to persuasive discussion on this point

> Also the Labels MIB is glumping everything into
> a single table.  Was the use of separate tables (similar
> to what LDP did for ATM and FR specific objects)
> considered?

Good choice of word, "glumping".  I confess that I was never a fan of the
multiple table approach!

>From an implementation point of view there is need be no impact (although I can
conceive of implementations where this is not the case :-).  The conformance
statement (of course, should make it clear that implementations can support
whatever set of label-types they like.  Note that an important consideration is
the type of labels reported from the network which may not match those supported
locally.

Hope this answers you.

Regards,
Adrian
--
Adrian Farrel
Movaz Networks Inc.
Tel: 703-847-1867
[email-masked]

Delivery-date: Fri, 14 Dec 2001 07:04:31 -0800
Date: Fri, 14 Dec 2001 10:01:55 -0500
From: Joan Cucchiara <[email-masked]>
Organization: Crescent Networks
To: Adrian Farrel <[email-masked]>
CC: [email-masked], Tim Hall <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>, Edward Harrison <[email-masked]>, Cheenu Srinivasan <[email-masked]>
Subject: Re: MIBs for GMPLS

Hi Adrian,

Why is there so much overlap between these
MIBs and the MIBs in MPLS?

It seems that the MPLS MIBs could be extended
for GMPLS specific info and thus avoid so much
overlap.  Could you shed some light on this?

Also the Labels MIB is glumping everything into
a single table.  Was the use of separate tables (similar
to what LDP did for ATM and FR specific objects)
considered?

  Thanks, Joan

> Adrian Farrel wrote:
> 
> At the CCAMP meeting in SLC Tom introduced the set of MIBs for GMPLS
> that we have produced.
> 
> Kireeti asked that we take the MIBs to the list to ensure that the big
> issues have been addressed, that everyone is comfortable with the
> approach and there really is a need for the MIBs.
> 
> Requirements are handled by...
> 
> - protocols within the IETF need MIBs, further
>   draft-ietf-ccamp-gmpls-architecture-01.txt
>   explicitly requires MIBs for GMPLS
> 
> The biggest issue outstanding was whether the Labels MIB should be
> included within the LSR MIB.  The authors currently feel that it
> should remain as a separate MIB
> 
> - to allow people to implement only the TE MIB
>   without putting complex conformance statements
>   in the LSR MIB
> - to allow people to clearly not implement the
>   Labels MIB at all.
> We would welcome input on this.
> 
> 
> Please take this opportunity to give us your input and help shape the
> MIBs.
> 
> We hope to respin the drafts in a compilable form in the next few
> days.
> 
> 
> The MIBs are...
> 
> http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-tc-mib-00.txt
> http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-label-mib-00.txt
> http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-te-mib-00.txt
> http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-lsr-mib-00.txt
> 
> 
> Regards,
> Adrian
> 
> --
> Adrian Farrel
> Movaz Networks Inc.
> Tel: 703-847-1867
> [email-masked]

Delivery-date: Thu, 13 Dec 2001 18:13:08 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Fwd: Comments on GMPLS signalling drafts
Date: Thu, 13 Dec 2001 19:10:12 -0700

>From: "manoj juneja" <[email-masked]>
>To: [email-masked]
>Subject: Comments on GMPLS signalling drafts
>Date: Tue, 11 Dec 2001 16:15:10 -0700
>
>Hi All,
>
>1. SE-style supported by GMPLS or not ?
>As labels are the resources on the link, one can't allocate different
>label to different senders in the same RSVP session.
>
>2. Bandwidth modification for TDM, LSC and FSC LSPs. There is a
>separate draft for TDM LSP bandwidth modification but what about the
>bandwidth modification for other types of LSPs ? There is no mention of
>these in any of the GMPLS drafts.
>
>3. It should be mentioned clearly that waveband section is still not
>complete in the drafts.
>
>4. For IF_ID_RSVP_HOP object, there are couple of TLVs defined. What
>about the Component_If_Id_Downstream/Upstream TLV ? The revised
>bundling draft has removed these 2 TLVs. What about the GMPLS signalling
>drafts ?
>
>5. STM-0 label representation using {SUKLM} should be mentioned in the
>drafts (because it is a special case).
>
>6. It should be mentioned that bandwidth encoding parameter is useful
>for what all type of LSPs i.e. TDM, LSC, FSC, PSC etc.
>
>7. There is an example scenario for contention resolution in case of bi-
>directional LSPs. It should be mentioned that  :
>
>"contention resolution is an optimization, not a correctness issue ...
>and no procedure can provide optimal resolution in all cases. An 
>implementor
>may do differently to provide better resolution."
>
>The above quotes are extracted from one of the mails from Fong Liaw.
>
>If this is the case then this should be mentioned in the drafts.
>
>8. The LSP hierarchy concept is still not clear. Some days back I posted 
>one
>doubt related to tunneling of TDM LSP over Lambda LSP using the concept of
>forwarding adjacency and different people replied with different thoughts.
>Does this mean this concept is not standardized in GMPLS ?
>My question was :
>
>"If there are 4 nodes say A, B, C and D. There is a Lambda FA
>established from A to D and if a new TDM LSP request comes to node A
>which is to be tunneled through the already established lambda FA-LSP
>then the node A sends the Path/label request message directly to node
>D. What label the node D will send back to node A in the RESV/label
>mapping message since the FA-LSP is just one label (lambda) ? Does it
>mean that all the LSPs which are tunneled through the lambda FA-LSP
>will be allocated the same label by node D to node A ? If this type of
>scenario can't exist in GMPLS then please let me know that too."
>
>
>Regards,
>manoj.
>
>
>
>
>_________________________________________________________________
>Join the world’s largest e-mail service with MSN Hotmail.
>http://www.hotmail.com
>
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

Delivery-date: Thu, 13 Dec 2001 18:09:58 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: ´ð¸´: Lambda LSP establishment
Date: Thu, 13 Dec 2001 19:09:20 -0700

Rick,
        What happens if the node or interface supports multiple 
switching/multiplexing capabilities ?

>From: "rick king" <[email-masked]>
>To: "manoj juneja" <[email-masked]>
>CC: <[email-masked]>
>Subject: ´ð¸´: Lambda LSP establishment
>Date: Fri, 14 Dec 2001 09:54:51 +0800
>
>I think the multiplexing capabilities of the FA is decided  by the 
>multiplexing/switching capabilities
>of the two LSRs connected by this FA. right?
>
>rick
>----------------------------------------------------------
>·¢ËÍÊ±¼ä: 2001Äê12ÔÂ14ÈÕ 2:45
>ÊÕ¼þÈË: [email-masked]; [email-masked];
>[email-masked]; [email-masked].
>³ËÍ: [email-masked]
>Ö÷Ìâ: RE: Lambda LSP establishment
>
>
>Hi Eric,
>           I fully support ur idea of having an informational draft
>explaining different scenarios of SDH/SONET LSP establishment. The
>concept of hierarchy is clear in case of SDH/SONET. What about the LSC
>or FSC interfaces ?
>2-3 days back john responded to my question on lambda hierarchy that a
>lambda LSP can be advertised as a FA with different switching type (say
>TDM) and then a TDM LSP can be tunneled over a lambda LSP. I am
>interested in knowing the list of such scenarios in case of LSC or FSC
>LSP advertised as a FA and its different combinations of switching
>capabilities as these things are not expalined anywhere.
>When a head or tail end of LSP advertises it as a FA then how the
>multiplexing capabilities (like can switch VC-4 but not VC-3 etc.) of
>the FA are decided ?
>
>Regards,
>manoj.
>
> >From: "Mannie, Eric" <[email-masked]>
> >To: 'Heiles Juergen ' <[email-masked]>, ''John Drake' '
> ><[email-masked]>, 'Maarten Vissers ' <[email-masked]>, 'manoj
> >juneja ' <[email-masked]>
> >CC: "[email-masked] '" <[email-masked]>
> >Subject: RE: Lambda LSP establishment
> >Date: Thu, 13 Dec 2001 18:56:31 +0100
> >
> >Hi All,
> >
> >A few comments,
> >
> > >In MPLS the FA establishes "virtual" layer networks. In GMPLS the layer
> >networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, OCh, OMS, 
>OTS).
> >A
> >FA basically corresponds to a real trail in a circuit switched network.
> >
> >Eric: ...and this trail is setup dynamically using GMPLS. That's the
> >interest. One can think of SDH/SONET FAs as shortcuts or express-routes.
> >
> > >One special thing about the SDH label is, that it includes a hierarchy 
>as
> >it identifies the lower order VC in a higher order VC in a STM-N signal.
> >Note that this is somehow in contradiction with a statement in the GMPLS
> >signaling document which says
> >
> > >"A Generalized Label only carries a single level of label, i.e., it is
> >    non-hierarchical.  When multiple levels of label (LSPs within LSPs)
> >    are required, each LSP must be established separately, see [MPLS-
> >    HIERARCHY]."
> >
> >No, hierarchy of labels is not hierarchy of layers. And even one should
> >have
> >a common definition of what means a "layer". This text says that we 
>cannot
> >have multiple embedded labels, e.g. one label containting a label stack.
> >This is a signaling stuff that doesn't imply anything on the transport
> >plane.
> >
> >Now, a label identifies ONE LSP at an interface. This LSP can be HO or LO
> >in
> >SDH. The label can be fully specified or partially specified, depending 
>on
> >the context where the LSP is established.
> >
> >E.g. when an LSP is established over a FA, the highest part of the LSP
> >label
> >is not relevant. When the FA LSP is established the lowest part of the FA
> >LSP label is not relevant.
> >
> >If a low order LSP is established without any higher order FA, the label 
>is
> >fully specified. As you said the link is indeed the "ultimate FA" in that
> >case. Except that from the routing point of view a link and an FA are two
> >different things. There is a routing adjacency "over" a link but not over 
>a
> >FA.
> >
> >The SDH/SONET label just includes what you need to include in each
> >scenario.
> >
> >Moreover, the label MUST be interpreted according to the type of 
>interface
> >for which it is used. It is possible to code two labels having the same
> >value but a complete different meaning. Labels are context sensitive of
> >course.
> >
> >For instance, an LSP over an STM-0 interface or over a FA will have the
> >highest part set to zero, and could possibly have the same lowest part. 
>You
> >cannot understand what means the label without knowning the detail of the
> >interface. In that case, the interface is either an STM-0 interface or a
> >VC-3 FA. And of course that FA and STM-0 interface are two different
> >things,
> >but from the LSP point of view, in both cases what it wants is a VC-3 in
> >which it can be multiplexed.
> >
> >Hope this helps.
> >
> >I start to wonder if we should have an informational draft describing
> >different scenarios of SDH/SONET LSP establishment. That could complement
> >the SDH/SONET signaling drafts and the GMPLS architecture. That could 
>solve
> >many terminology and modeling issues.
> >
> >Kind regards,
> >
> >Eric
> >
> >-----Original Message-----
> >From: Heiles Juergen
> >To: 'John Drake'; Maarten Vissers; manoj juneja
> >Cc: [email-masked]
> >Sent: 12/13/01 11:15 AM
> >Subject: RE: Lambda LSP establishment
> >
> >Let me express my understanding of FAs in MPLS/GMPLS, please correct me
> >if I am wrong. I have also some questions related to the label
> >generation and interactions between layer networks.
> >
> >The label in MPLS is local to the link between two adjacent MPLS
> >switches, it indicates a LSP in this link. This link is therefore the
> >ultimate FA. An already established LSP between two MPLS switches, which
> >don't have to be adjacent, can be used to transport/tunnel other LSPs
> >between this two nodes. This already established LSP generates a virtual
> >adjacency between the two nodes, the FA. As several LSPs can use this FA
> >it is also a kind of virtual multiplexing.
> >If you compare it with a circuit switched network the FA is a server
> >layer trail that provides transport (a link connection) for one or more
> >client layer signals.
> >In MPLS the FA establishes "virtual" layer networks. In GMPLS the layer
> >networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, OCh, OMS,
> >OTS). A FA basically corresponds to a real trail in a circuit switched
> >network.
> >In GMPLS the label is also local to the link between the two devices
> >that perform the switching. For example for SDH the VC-N is identified
> >by the STM-N link/port and the SUKLM number according to
> >draft-ietf-ccamp-gmpls-sonet-sdh-02.txt. The STM-N port is identified by
> >the interface ID (I am not sure on this) and SUKLM is the SDH label that
> >locates the VC within the STM-N.
> >From just the SDH viewpoint the STM-N connection is the ultimate server
> >trail/FA. However the STM-N signal could be transported over a Optical
> >Channel or G.709 ODU. The OCh or ODU can already start in the equipment
> >that performs the VC-N switching. So the STM-N signal is not the port,
> >but the WDM signal is the port and the STM-N signal makes use of a OCh
> >or ODU server layer trail. This server layer trail can be established
> >via management or using GMPLS.
> >Can someone explain how a label for a VC-4 is generated in this case
> >(pre-established OCh or ODU trail via management or setup using GMPLS).
> >This interaction between the different technologies/labels need in my
> >view some further explanation.
> >
> >One special thing about the SDH label is, that it includes a hierarchy
> >as it identifies the lower order VC in a higher order VC in a STM-N
> >signal. Note that this is somehow in contradiction with a statement in
> >the GMPLS signaling document which says
> >"A Generalized Label only carries a single level of label, i.e., it is
> >    non-hierarchical.  When multiple levels of label (LSPs within LSPs)
> >    are required, each LSP must be established separately, see [MPLS-
> >    HIERARCHY]."
> >Following this statement each layer should have its own label
> >independent of server layers.
> >The combination of hierarchies in labels is based on technology (e.g.
> >SDH, Sonet, G.709 ODU) but has in my view no real technical reason. The
> >SDH label for example fits to standard STM-N signals, but not to sub-STM
> >signals.
> >For the SDH the full SUKLM number is used if a e.g. VC-12 is located in
> >relation to a STM-N interface. If it is located in relation to a VC-4
> >(the VC-4 is in this case a FA) SUK are set to 0. For me it is not clear
> >in which case I use the first and in which case I use the second case as
> >a VC-4 trail is always needed for a VC-12 connection. This VC-4 could be
> >established using management or GMPLS. However it should have no
> >influence on the label.
> >Some more information is needed in my view in this area.
> >
> >
> >Juergen
> >
> >
> > > -----Original Message-----
> > > From: John Drake [mailto:[email-masked]]
> > > Sent: Wednesday, December 12, 2001 6:54 AM
> > > To: Maarten Vissers; manoj juneja
> > > Cc: [email-masked]
> > > Subject: RE: Lambda LSP establishment
> > >
> > >
> > > fortunately, this is just your opinion
> > >
> > > -----Original Message-----
> > > From: Maarten Vissers [mailto:[email-masked]]
> > > Sent: Tuesday, December 11, 2001 9:31 PM
> > > To: manoj juneja
> > > Cc: [email-masked]
> > > Subject: Re: Lambda LSP establishment
> > >
> > >
> > > Manoj,
> > >
> > > Forget the FA stuff, it is not appropriate in circuit
> > > networks. It only
> > > applies
> > > to MPLS. We should remove it when it is used in relation with PDH,
> > > SDH/SONET,
> > > OTN and pre-OTN. The text in sdh-sonet draft should state
> > > that if there is a
> > > LOVC link (IETF: link bundle/TE link) then the LOVC signals
> > > use a label with
> > > "00KLM".
> > >
> > > Regards,
> > >
> > > Maarten
> > >
> > > manoj juneja wrote:
> > > >
> > > > Hi Marteen,
> > > >             The concept of FA is mentioned for SDH/SONET in
> > > gmpls-sdh
> > > > -sonet draft. It says that if u have a HOVC trail as a FA
> > > (advertized
> > > > as a link) then u can allocate the lower level signals in
> > > it by making
> > > > the higher bits of label as 0s (i.e. S and U}. This is fine
> > > for the same
> > > > technology. What about the case where the TDM LSP has to be tunneled
> > > through
> > > > the Lambda LSP ? What will be the form of label (i.e.
> > > {SUKLM} or lambda
> > > > etc.) ?
> > > >
> > > > Regards,
> > > > manoj.
> > > >
> > > > >From: Maarten Vissers <[email-masked]>
> > > > >To: manoj juneja <[email-masked]>
> > > > >CC: [email-masked]
> > > > >Subject: Re: Lambda LSP establishment
> > > > >Date: Tue, 11 Dec 2001 15:56:41 +0100
> > > > >
> > > > >Manoj,
> > > > >
> > > > >You refer to one wavelength to be available between A-E without
> > > wavelength
> > > > >conversion capability. This suggests that you operate at
> > > the OCh layer
> > > > >network.
> > > > >Then you specify the capacity of the 4 OCh link
> > > connections (A-B, B-C,
> > > C-D,
> > > > >D-E)
> > > > >to be "C". Say that C is about 10 Gbit/s. You then assume
> > > that there is a
> > > > >request for an OCh signal with capacity C/4 (e.g. 2.5
> > > Gbit/s) between C
> > > and
> > > > >E.
> > > > >The result is that the OCh link connections C-D and D-E
> > > are transporting
> > > > >the OCh
> > > > >signal (of e.g. 2.5G). These OCh link connections are now
> > > in service and
> > > > >not
> > > > >longer available to an other OCh connection request. I.e.
> > > a request for
> > > an
> > > > >OCh
> > > > >connection between A and E will be rejected.
> > > > >
> > > > >FAs are not applicable in the circuit layers. IF there is
> > > a trail in
> > > server
> > > > >layer X, then there is a link in its client layer Y. X and
> > > Y are thus
> > > > >different
> > > > >layer networks and signals.
> > > > >
> > > > >If C-E is a "FA", then in an OTN the C-E connection would
> > > be an OCh trail
> > > > >supporting an ODUk (k=1 if OCh is 2G5) link with a single link
> > > connection.
> > > > >
> > > > >Note a FA in MPLS creates essentially a MPLS sublayer
> > > network. Such is
> > > not
> > > > >possible in the SDH/SONET, OTN, PDH or ATM technologies.
> > > > >
> > > > >Regards,
> > > > >
> > > > >Maarten
> > > > >
> > > > >OCh link connections
> > > > >
> > > > >manoj juneja wrote:
> > > > > >
> > > > > > Hi All,
> > > > > >         If I have 5 nodes A, B, C, D and E connected as
> > > shown. Assume
> > > > > > that only one wavelength is available on the path A to E (no
> > > wavelength
> > > > > > conversion capability is there on the complete path).
> > > Let the capacity
> > > > > > of the wavelength be C. Further assume a request arrives for
> > > connection
> > > > > > from node C to E for a line capacity of C/4. This
> > > request will be
> > > > > > successful as we have available wavelength. Now If
> > > another request
> > > > > > comes at node A to establish another connection from
> > > node A to node E
> > > > > > via nodes {A,B,C,D,E} for a line capacity of C/4.
> > > Should this request
> > > > > > be successful as we have already allocated the wavelength ?
> > > > > >
> > > > > > If the previous connection from C to E of capacity C/4 had been
> > > > > > advertised as a FA, in that case will the IInd request succeed ?
> > > > > >
> > > > > > If the previous connection from C to E of capacity C/4
> > > had not been
> > > > > > advertised as FA then what will be the fate of IInd connection ?
> > > > > >
> > > > > >        A <--> B <---> C <----> D <---> <----> E
> > > > > >
> > > > > > Regards,
> > > > > > manoj.
> > > > > >
> > > > > >
> > > _________________________________________________________________
> > > > > > Get your FREE download of MSN Explorer at
> > > > >http://explorer.msn.com/intl.asp
> > > > ><< mvissers.vcf >>
> > > >
> > > > _________________________________________________________________
> > > > Send and receive Hotmail on your mobile device:
> >http://mobile.msn.com
>
>
>_________________________________________________________________
>Send and receive Hotmail on your mobile device: http://mobile.msn.com
>
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

Delivery-date: Thu, 13 Dec 2001 17:57:06 -0800
From: "rick king" <[email-masked]>
To: "manoj juneja" <[email-masked]>
Cc: <[email-masked]>
Subject: =?gb2312?B?tPC4tDogTGFtYmRhIExTUCBlc3RhYmxpc2htZW50?=
Date: Fri, 14 Dec 2001 09:54:51 +0800

Delivery-date: Thu, 13 Dec 2001 16:03:24 -0800
From: "Mannie, Eric" <[email-masked]>
To: "[email-masked] '" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>
Subject: Revised GMPLS SONET/SDH drafts
Date: Fri, 14 Dec 2001 00:59:42 +0100

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C18432.3B958350
Content-Type: text/plain

Dear All,

Please find attached the two GMPLS SDH/SONET drafts revised according to the
comments received during the last period of comments, and during the Salt
Lake City meeting:

- draft-ietf-ccamp-gmpls-sonet-sdh-03.txt
- draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt

Please, send your comments to the mailing list AND to us.

Kind regards,

Eric and Dimitri

------_=_NextPart_000_01C18432.3B958350
Content-Type: application/octet-stream;
	name="draft-ietf-ccamp-gmpls-sonet-sdh-03.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-ccamp-gmpls-sonet-sdh-03.txt"

   CCAMP Working Group                   Eric Mannie (Ebone) - Editor=20
   Internet Draft                            =20
   Expiration Date: June 2002                Stefan Ansorge (Alcatel)=20
                                         Peter Ashwood-Smith (Nortel)=20
                                              Ayan Banerjee (Calient)=20
                                                   Lou Berger (Movaz)=20
                                               Greg Bernstein (Ciena)=20
                                                 Angela Chiu (Celion)=20
                                                 John Drake (Calient)=20
                                                 Yanhe Fan (Axiowave)=20
                                            Michele Fontana (Alcatel)=20
                                               Gert Grammel (Alcatel)=20
                                              Juergen Heiles(Siemens)=20
                                               Suresh Katukam (Cisco)=20
                                           Kireeti Kompella (Juniper)=20
                                           Jonathan P. Lang (Calient)=20
                                                  Fong Liaw (Zaffire)=20
                                                 Zhi-Wei Lin (Lucent)=20
                                             Ben Mack-Crane (Tellabs)=20
                                      Dimitri Papadimitriou (Alcatel)=20
                                       Dimitrios Pendarakis (Tellium)=20
                                           Mike Raftelis (White Rock)=20
                                           Bala Rajagopalan (Tellium)=20
                                              Yakov Rekhter (Juniper)=20
                                              Debanjan Saha (Tellium)=20
                                             Vishal Sharma (Metanoia)=20
                                               George Swallow (Cisco)=20
                                                 Z. Bo Tang (Tellium)=20
                                                   Eve Varma (Lucent)=20
                                             Maarten Vissers (Lucent)=20
                                                Yangguang Xu (Lucent)=20
   =20
                                                        December 2001=20
   =20
   =20
               GMPLS Extensions for SONET and SDH Control=20
   =20
   =20
                 draft-ietf-ccamp-gmpls-sonet-sdh-03.txt=20
   =20
Status of this Memo=20
   =20
   This document is an Internet-Draft and is in full conformance with=20
   all provisions of Section 10 of RFC2026.  Internet-Drafts are=20
   working documents of the Internet Engineering Task Force (IETF),=20
   its areas, and its working groups.  Note that other groups may=20
   also distribute working documents as Internet-Drafts.=20
   =20
   Internet-Drafts are draft documents valid for a maximum of six=20
   months and may be updated, replaced, or obsoleted by other=20
   documents at any time. It is inappropriate to use Internet-Drafts=20
   as reference material or to cite them other than as "work in=20
   progress."=20
   =20
=20
E. Mannie Editor                                                     1=20
=0C
               draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20

   To view the current status of any Internet-Draft, please check the=20
   "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow=20
   Directory, see http://www.ietf.org/shadow.html.=20
=20
=20
Abstract=20
   =20
   This document is a companion to the Generalized MPLS signaling=20
   documents, [GMPLS-SIG], [GMPLS-RSVP] and [GMPLS-LDP].  It defines=20
   the SONET/SDH technology specific information needed when using=20
   GMPLS signaling.=20
   =20
   =20
1. Introduction=20
   =20
   Generalized MPLS (GMPLS) extends MPLS from supporting packet=20
   (Packet Switching Capable - PSC) interfaces and switching to=20
   include support of four new classes of interfaces and switching:=20
   Layer-2 Switch Capable (L2SC), Time-Division Multiplex (TDM),=20
   Lambda Switch Capable (LSC) and Fiber-Switch Capable (FSC). A=20
   functional description of the extensions to MPLS signaling needed=20
   to support the new classes of interfaces and switching is provided=20
   in [GMPLS-SIG]. [GMPLS-RSVP] describes RSVP-TE specific formats=20
   and mechanisms needed to support all five classes of interfaces,=20
   and CR-LDP extensions can be found in [GMPLS-LDP]. This document=20
   presents details that are specific to SONET/SDH. Per [GMPLS-SIG],=20
   SONET/SDH specific parameters are carried in the signaling=20
   protocol in traffic parameter specific objects.=20
   =20
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL=20
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"=20
   in this document are to be interpreted as described in [RFC2119].=20
   =20
   =20
2. SDH and SONET Traffic Parameters=20
   =20
   This section defines the GMPLS traffic parameters for SONET/SDH.=20
   The protocol specific formats, for the SDH/SONET-specific RSVP-TE=20
   objects and CR-LDP TLVs are described in sections 2.2 and 2.3=20
   respectively.=20
   =20
   These traffic parameters specify indeed a base set of capabilities=20
   for SONET (ANSI T1.105) and SDH (ITU-T G.707) such as=20
   concatenation and transparency. Some extra non-standard=20
   capabilities are defined in [GMPLS-SONET-SDH-EXT]. Other documents=20
   could further enhance this set of capabilities in the future. For=20
   instance, signaling for SDH over PDH (ITU-T G.832), or sub-STM-0=20
   (ITU-T G.708) interfaces could be defined.=20
   =20
   The traffic parameters defined hereafter MUST be used when=20
   SONET/SDH is specified in the LSP Encoding Type field of a=20
   Generalized Label Request [GMPLS-SIG].=20
   =20

=20
E. Mannie Editor       Internet-Draft June 2002                      2=20
=0C
               draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20

   A SONET signal which has an identical SDH signal SHOULD be=20
   requested using the same traffic parameters as for the equivalent=20
   SDH signal, and will consequently use the SDH label.=20
=20
=20
2.1. SONET/SDH Traffic Parameters=20
   =20
   The traffic parameters for SONET/SDH is organized as follows:=20
   =20
    0                   1                   2                   3=20
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |  Signal Type  |      RCC      |              NCC              |=20
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |              NVC              |        Multiplier (MT)        |=20
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |                       Transparency (T)                        |=20
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   =20
   Annex 1 defines examples of SONET and SDH signal coding.=20
   =20
   Signal Type (ST): 8 bits=20
   =20
     This field indicates the type of Elementary Signal that=20
     comprises the requested LSP. Several transforms can be applied=20
     successively on the Elementary Signal to build the Final Signal=20
     being actually requested for the LSP.=20
     =20
     Each transform is optional and must be ignored if zero, except=20
     MT that cannot be zero and is ignored if equal to one.=20
     =20
     Transforms must be applied strictly in the following order:=20
   =20
      - First, contiguous concatenation (by using the RCC and NCC=20
        fields) can be optionally applied on the Elementary Signal,=20
        resulting in a contiguously concatenated signal.=20
      - Second, virtual concatenation (by using the NVC field) can=20
        be optionally applied either directly on the Elementary=20
        Signal, or on the contiguously concatenated signal obtained=20
        from the previous phase (see [GMPLS-SONET-SDH-EXT]).=20
      - Third, some transparency can be optionally specified when=20
        requesting a frame as signal rather than an SPE or VC based=20
        signal (by using the Transparency field).=20
      - Fourth, a multiplication (by using the Multiplier field) can be =

        optionally applied either directly on the Elementary Signal, or =

        on the contiguously concatenated signal obtained from the first =

        phase, or on the virtually concatenated signal obtained from=20
        the second phase, or on these signals combined with some=20
        transparency.=20
=20
=20
=20
=20
=20
=20
E. Mannie Editor       Internet-Draft June 2002                      3=20
=0C
               draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20

   Permitted Signal Type values for SONET/SDH are:=20
   =20
       Value      Type=20
       -----  -----------------=20
        1    VT1.5  SPE / VC-11=20
        2    VT2    SPE / VC-12=20
        3    VT3    SPE=20
        4    VT6    SPE / VC-2=20
        5    STS-1  SPE / VC-3=20
        6    STS-3c SPE / VC-4=20
        7    STS-1      / STM-0   (only when requesting transparency)=20
        8    STS-3      / STM-1   (only when requesting transparency)=20
        9    STS-12     / STM-4   (only when requesting transparency)=20
        10   STS-48     / STM-16  (only when requesting transparency)=20
        11   STS-192    / STM-64  (only when requesting transparency)=20
        12   STS-768    / STM-256 (only when requesting transparency)=20
     =20
     A dedicated signal type is assigned to a SONET STS-3c SPE instead=20
     of coding it as a contiguous concatenation of three STS-1 SPEs.=20
     This is done in order to provide easy interworking between SONET=20
     and SDH signaling.=20
     =20
     Appendix 1 adds one more signal type (optional). Refer to [GMPLS-
     SDH-SONET-EXT] for an extended set of signal type values beyond=20
     the signal types as defined in T1.105/G.707. =20
=20
   Requested Contiguous Concatenation (RCC): 8 bits=20
   =20
     This field is used to request and sometimes negotiate (see=20
     [GMPLS-SDH-SONET-EXT]) the optional SONET/SDH contiguous=20
     concatenation of the Elementary Signal.=20
     =20
     This field is a vector of flags. Each flag indicates the=20
     support of a particular type of contiguous concatenation.=20
     Several flags can be set at the same time to indicate a choice. =20
     =20
     These flags allow an upstream node to indicate to a downstream=20
     node the different types of contiguous concatenation that it=20
     supports. However, the downstream node decides which one to use=20
     according to its own rules.=20
     =20
     A downstream node receiving simultaneously more than one flag=20
     chooses a particular type of contiguous concatenation, if any=20
     supported, and based on criteria that are out of this document=20
     scope. A downstream node that doesn=92t support any of the=20
     concatenation types indicated by the field must refuse the LSP=20
     request. In particular, it must refuse the LSP request if it=20
     doesn=92t support contiguous concatenation at all.=20
     =20
     The upstream node knows which type of contiguous concatenation=20
     the downstream node chosen by looking at the position indicated=20
     by the first label and the number of label(s) as returned by=20
     the downstream node.=20
=20
=20
E. Mannie Editor       Internet-Draft June 2002                      4=20
=0C
               draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20

     The entire field is set to zero to indicate that no contiguous=20
     concatenation is requested at all (default value). A non-zero=20
     field indicates that some contiguous concatenation is=20
     requested.=20
     =20
     The following flag is defined:=20
     =20
         Flag 1 (bit 1): Standard contiguous concatenation.=20
     =20
     Flag 1 indicates that only the standard SONET/SDH contiguous=20
     concatenation as defined in T1.105/G.707 is supported. Note=20
     that bit 1 is the low order bit. Other flags are reserved for=20
     extensions, if not used they must be set to zero when sent, and=20
     should be ignored when received.=20
     =20
     See note 1 hereafter in the section on the NCC about the SONET=20
     contiguous concatenation of STS-1 SPEs when the number of=20
     components is a multiple of three.=20
     =20
     Refer to [GMPLS-SONET-SDH-EXT] for an extended set of contiguous=20
     concatenation types beyond the contiguous concatenation types as=20
     defined in T1.105/G.707.=20
=20
   Number of Contiguous Components (NCC): 16 bits=20
   =20
     This field indicates the number of identical SONET/SDH SPEs/VCs=20
     that are requested to be concatenated, as specified in the RCC=20
     field.=20
     =20
     Note 1: when requesting a SONET STS-Nc SPE with N=3D3*X, the=20
     elementary signal to use must always be an STS-3c SPE signal=20
     type and the value of NCC must always be equal to X. This=20
     allows also facilitating the interworking between SONET and=20
     SDH. In particular, it means that the contiguous concatenation=20
     of three STS-1 SPEs cannot not be requested because according=20
     to this specification, this type of signal must be coded using=20
     the STS-3c SPE signal type.=20
     =20
     Note 2: when requesting a transparent STM-N/STS-N signal=20
     limited to a single contiguously concatenated VC-4-Nc/STS-Nc-
     SPE, the signal type must be STM-N/STS-N, RCC with flag 1 and=20
     NCC set to 1.=20
     =20
     This field is irrelevant if no contiguous concatenation is=20
     requested (RCC =3D 0), in that case it must be set to zero when=20
     send, and should be ignored when received. A RCC value=20
     different from 0 must imply a number of components greater than=20
     1. The NCC value must be consistent with the type of contiguous=20
     concatenation being requested in the RCC field.=20
=20
=20
=20
=20
=20
=20
E. Mannie Editor       Internet-Draft June 2002                      5=20
=0C
               draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20

   Number of Virtual Components (NVC): 16 bits=20
     =20
     This field indicates the number of signals that are requested=20
     to be virtually concatenated. These signals are all of the same=20
     type by definition. They are Elementary Signal SPEs/VCs for=20
     which signal types are defined in this document, i.e. VT1.5=20
     SPE, VT2 SPE, VT3 SPE, VT6 SPE, STS-1 SPE, STS-3c SPE, VC-11,=20
     VC-12, VC-2, VC-3 or VC-4.=20
     =20
     This field is set to 0 (default value) to indicate that no=20
     virtual concatenation is requested.=20
     =20
     Refer to [GMPLS-SONET-SDH-EXT] for an extended set of signals that =

     can be virtually concatenated beyond the virtual concatenation as=20
     defined in T1.105/G.707.=20
     =20
   Multiplier (MT): 16 bits=20
     =20
     This field indicates the number of identical signals that are=20
     requested for the LSP, i.e. that form the Final Signal. These=20
     signals can be either identical Elementary Signals, or=20
     identical contiguously concatenated signals, or identical=20
     virtually concatenated signals. Note that all these signals=20
     belongs thus to the same LSP.=20
     =20
     The distinction between the components of multiple virtually=20
     concatenated signals is done via the order of the labels that=20
     are specified in the signaling. The first set of labels must=20
     describe the first component (set of individual signals=20
     belonging to the first virtual concatenated signal), the second=20
     set must describe the second component (set of individual=20
     signals belonging to the second virtual concatenated signal)=20
     and so on.=20
     =20
     This field is set to one (default value) to indicate that=20
     exactly one instance of a signal is being requested. Zero is an=20
     invalid value.=20
     =20
   Transparency (T): 32 bits=20
   =20
     This field is a vector of flags that indicates the type of=20
     transparency being requested. Several flags can be combined to=20
     provide different types of transparency. Not all combinations=20
     are necessarily valid. The default value for this field is=20
     zero, i.e. no transparency requested.=20
     =20
     Transparency, as defined from the point of view of this=20
     signaling specification, is only applicable to the fields in=20
     the SONET/SDH frame overheads. In the SONET case, these are the=20
     fields in the Section Overhead (SOH), and the Line Overhead=20
     (LOH). In the SDH case, these are the fields in the Regenerator=20
     Section Overhead (RSOH), the Multiplex Section overhead (MSOH),=20
     and the pointer fields between the two. With SONET, the pointer=20
     fields are part of the LOH.=20
=20
E. Mannie Editor       Internet-Draft June 2002                      6=20
=0C
               draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20

     =20
     Note as well that transparency is only applicable when using=20
     the following Signal Types: STM-0, STM-1, STM-4, STM-16, STM-
     64, STM-256, STS-1, STS-3, STS-12, STS-48, STS-192, and STS-
     768. At least one transparency type must be specified when=20
     requesting such a signal type.=20
     =20
     Transparency indicates precisely which fields in these=20
     overheads must be delivered unmodified at the other end of the=20
     LSP. An ingress LSR requesting transparency will pass these=20
     overhead fields that must be delivered to the egress LSR=20
     without any change. From the ingress and egress LSRs point of=20
     views, these fields must be seen as unmodified.=20
     =20
     Transparency is not applied at the interfaces with the=20
     initiating and terminating LSRs, but is only applied between=20
     intermediate LSRs. =20
     =20
     The transparency field is used to request an LSP that supports=20
     the requested transparency type; it may also be used to setup=20
     the transparency process to be applied in each intermediate=20
     LSR.=20
     =20
     The different transparency flags are the following:=20
     =20
        Flag 1 (bit 1): Section/Regenerator Section layer.=20
        Flag 2 (bit 2): Line/Multiplex Section layer.=20
     =20
     Where bit 1 is the low order bit. Others flags are reserved,=20
     they should be set to zero when sent, and should be ignored=20
     when received. A flag is set to one to indicate that the=20
     corresponding transparency is requested.=20
     =20
     Section/Regenerator Section layer transparency means that the=20
     entire frames must be delivered unmodified. This implies that=20
     pointers cannot be adjusted. When using Section/Regenerator=20
     Section layer transparency all other flags must be ignored.=20
     =20
     Line/Multiplex Section layer transparency means that the=20
     LOH/MSOH must be delivered unmodified. This implies that=20
     pointers cannot be adjusted. =20
     =20
     Refer to [GMPLS-SONET-SDH-EXT] for an extended set of transparency =

     types beyond the transparency types as defined in T1.105/G.707.=20
     =20
     =20
2.2. RSVP-TE Details=20
   =20
   For RSVP-TE, the SONET/SDH traffic parameters are carried in the=20
   SONET/SDH SENDER_TSPEC and FLOWSPEC objects.  The same format is=20
   used both for SENDER_TSPEC object and FLOWSPEC objects. The=20
   contents of the objects is defined above in Section 2.1. The=20
   objects have the following class and type:=20
=20
=20
E. Mannie Editor       Internet-Draft June 2002                      7=20
=0C
               draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20

     For SONET ANSI T1.105 and SDH ITU-T G.707:=20
   =20
       SONET/SDH SENDER_TSPEC object: Class =3D 12, C-Type =3D 4 (TBA)=20
       SONET/SDH FLOWSPEC object: Class =3D 9, C-Type =3D 4 (TBA)=20
   =20
   There is no Adspec associated with the SONET/SDH SENDER_TSPEC.=20
   Either the Adspec is omitted or an int-serv Adspec with the=20
   Default General Characterization Parameters and Guaranteed Service=20
   fragment is used, see [RFC2210].=20
   =20
   For a particular sender in a session the contents of the FLOWSPEC=20
   object received in a Resv message SHOULD be identical to the=20
   contents of the SENDER_TSPEC object received in the corresponding=20
   Path message. If the objects do not match, a ResvErr message with=20
   a "Traffic Control Error/Bad Flowspec value" error SHOULD be=20
   generated.=20
=20
=20
2.3. CR-LDP Details=20
   =20
   For CR-LDP, the SONET/SDH traffic parameters are carried in the=20
   SONET/SDH Traffic Parameters TLV.  The contents of the TLV is=20
   defined above in Section 2.1. The header of the TLV has the=20
   following format:=20
   =20
    0                   1                   2                   3=20
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |U|F|          Type             |      Length                   |=20
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   =20
   The type field for the SONET/SDH Traffic Parameters TLV is: 0xTBA.=20
=20
=20
3. SDH and SONET Labels=20
   =20
   SDH and SONET each define a multiplexing structure, with the SONET=20
   multiplex structure being a subset of the SDH multiplex structure.=20
   These two structures are trees whose roots are respectively an=20
   STM-N or an STS-N; and whose leaves are the signals that can be=20
   transported via the time-slots and switched between time-slots,=20
   i.e. a VC-x, a VT-x SPE or an STS SPE. An SDH/SONET label will=20
   identify the exact position of a particular signal in a=20
   multiplexing structure. SDH and SONET labels are carried in the=20
   Generalized Label per [GMPLS-RSVP] and [GMPLS-LDP].=20
   =20
   These multiplexing structures will be used as naming trees to=20
   create unique multiplex entry names or labels. Since the SONET=20
   multiplexing structure may be seen as a subset of the SDH=20
   multiplexing structure, the same format of label is used for SDH=20
   and SONET. As explained in [GMPLS-SIG], a label does not identify=20
   the "class" to which the label belongs. This is implicitly=20
   determined by the link on which the label is used.=20
   =20
=20
E. Mannie Editor       Internet-Draft June 2002                      8=20
=0C
               draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20

   In case of signal concatenation or multiplication, a list of=20
   labels can appear in the Label field of a Generalized Label.=20
   =20
   In case of contiguous concatenation, only one label appears in the=20
   Label field. This label is the lowest signal of the contiguously=20
   concatenated signal. By lowest signal we mean the one having the=20
   lowest label when compared as integer values, i.e. the first=20
   component signal of the concatenated signal encountered when=20
   descending the tree.=20
   =20
   In case of virtual concatenation, the explicit ordered list of all=20
   labels in the concatenation is given. Each label indicates a=20
   component of the virtually concatenated signal. The order of the=20
   labels must reflect the order of the payloads to concatenate (not=20
   the physical order of time-slots). The above representation limits=20
   virtual concatenation to remain within a single (component) link;=20
   it imposes as such a restriction compared to the G.707/T1.105=20
   recommendations.=20
   =20
   In case of multiplication (i.e. using the multiplier transform),=20
   the explicit ordered list of all labels that take part in the=20
   Final Signal is given. In case of multiplication of virtually=20
   concatenated signals, the first set of labels indicates the first=20
   virtually concatenated signal, the second set of labels indicates=20
   the second virtually concatenated signal, and so on. The above=20
   representation limits multiplication to remain within a single=20
   (component) link.=20
   =20
   The format of the label for SDH and/or SONET TDM-LSR link is:=20
=20
    0                   1                   2                   3=20
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |               S               |   U   |   K   |   L   |   M   |=20
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   =20
   For SDH, this is an extension of the numbering scheme defined in=20
   G.707 section 7.3, i.e. the (K, L, M) numbering. For SONET, the U=20
   and K fields are not significant and must be set to zero. Only the=20
   S, L and M fields are significant for SONET and have a similar=20
   semantic as for SDH.=20
=20
   Each letter indicates a possible branch number starting at the=20
   parent node in the multiplex structure. Branches are considered as=20
   numbered in increasing order, starting from the top of the=20
   multiplexing structure. The numbering starts at 1, zero is used to=20
   indicate a non-significant or ignored field.=20
   =20
   When a field is not significant or ignored in a particular context=20
   it MUST be set to zero when transmitted, and MUST be ignored when=20
   received.=20
   =20
   When hierarchical SDH/SONET LSPs are used, an LSP with a given=20
   bandwidth can be used to tunnel lower order LSPs.  The higher=20
=20
E. Mannie Editor       Internet-Draft June 2002                      9=20
=0C
               draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20

   order SDH/SONET LSP behaves as a virtual link with a given=20
   bandwidth (e.g. VC-3), it may also be used as a Forwarding=20
   Adjacency. A lower order SDH/SONET LSP can be established through=20
   that higher order LSP. Since a label is local to a (virtual) link,=20
   the highest part of that label is non-significant and is set to=20
   zero.=20
   =20
   For instance, a VC-3 LSP can be advertised as a forwarding=20
   adjacency. In that case the labels allocated between the two ends=20
   of that LSP (i.e. for that "link") will have S, U and K set to=20
   zero, i.e., non-significant, while L and M will be used to=20
   indicate the signal allocated in that VC-3.=20
   =20
   The possible values of S, U, K, L and M are defined as it follows:=20
   =20
     1. S is only significant for SDH STM-N (N>0) and SONET. It must=20
     be ignored for STM-0. S is the index of a particular AUG-1/STS-
     1. S=3D1->N indicates a specific AUG-1/STS-1 inside an STM-N/STS-N =

     multiplex. For example, S=3D1 indicates the first AUG-1/STS-1, and =

     S=3DN indicates the last AUG-1/STS-1 of this multiplex.=20
   =20
     2. U is only significant for SDH STM-N (N>0) and must be ignored=20
     for STM-0 and SONET. It indicates a specific VC inside a given=20
     AUG-1. U=3D1 indicates a single VC-4, while U=3D2->4 indicates a=20
     specific VC-3 inside the given AUG-1.=20
   =20
     3. K is only significant for SDH VC-4 and must be ignored in all=20
     other cases. It indicates a specific branch of a VC-4. K=3D1=20
     indicates that the VC-4 is not further subdivided and contains a=20
     C-4. K=3D2->4 indicates a specific TUG-3 inside the VC-4. K is not =

     significant when the AUG-1 is divided into AU-3s.=20
   =20
     4. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE.=20
     It is not significant for an unstructured VC-4 (L=3D0). L=3D1=20
     indicates that the TUG-3/VC-3/STS-1 SPE is not further=20
     subdivided and contains a VC-3/C-3 in SDH or the equivalent in=20
     SONET. L=3D2->8 indicates a specific TUG-2/VT Group inside the=20
     corresponding higher order signal.=20
   =20
     5. M indicates a specific branch of a TUG-2/VT Group. It is not=20
     significant for an unstructured VC-4, TUG-3, VC-3 or STS-1 SPE.=20
     M=3D1 indicates that the TUG-2/VT Group is not further subdivided=20
     and contains a VC-2/VT-6 SPE. M=3D2->3 indicates a specific VT-3=20
     inside the corresponding VT Group, these values MUST NOT be used=20
     for SDH since there is no equivalent of VT-3 with SDH. M=3D4->6=20
     indicates a specific VC-12/VT-2 SPE inside the corresponding=20
     TUG-2/VT Group. M=3D7->10 indicates a specific VC-11/VT-1.5 SPE=20
     inside the corresponding TUG-2/VT Group. Note that M=3D0 denotes=20
     an unstructured VC-4, VC-3 or STS-1 SPE.=20
=20
=20
=20
=20
=20
=20
E. Mannie Editor       Internet-Draft June 2002                     10=20
=0C
               draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20

      The M encoding is summarized in the following table:=20
   =20
          M    SDH                          SONET=20
         ----------------------------------------------------------=20
          0    unstructured VC-4/VC-3  unstructured STS-1 SPE=20
          1    VC-2                    VT-6=20
          2    -                       1st VT-3=20
          3    -                       2nd VT-3=20
          4    1st VC-12               1st VT-2=20
          5    2nd VC-12               2nd VT-2=20
          6    3rd VC-12               3rd VT-2=20
          7    1st VC-11               1st VT-1.5=20
          8    2nd VC-11               2nd VT-1.5=20
          9    3rd VC-11               3rd VT-1.5=20
          10   4th VC-11               4th VT-1.5=20
=20
   Examples of labels:=20
   =20
   Example 1: S>0, U=3D1, K=3D1, L=3D0, M=3D0=20
   Denotes the unstructured VC-4 of the Sth AUG-1.=20
   =20
   Example 2: S>0, U=3D1, K>1, L=3D1, M=3D0=20
   Denotes the unstructured VC-3 of the Kth-1 TUG-3 of the Sth AUG-1.=20
   =20
   Example 3: S>0, U=3D0, K=3D0, L=3D0, M=3D0=20
   Denotes the unstructured SPE of the Sth STS-1.=20
   =20
   Example 4: S>0, U=3D0, K=3D0, L>1, M=3D1=20
   Denotes the VT-6 in the Lth-1 VT Group in the Sth STS-1.=20
   =20
   Example 5: S>0, U=3D0, K=3D0, L>1, M=3D9=20
   Denotes the 3rd VT-1.5 in the Lth-1 VT Group in the Sth STS-1.=20
=20
   In case of contiguous concatenation, the label that is used is the=20
   lowest label of the contiguously concatenated signal as explained=20
   before. The higher part of the label indicates where the signal=20
   starts and the lowest part is not significant. For instance, when=20
   requesting an STS-48c the label is S>0, U=3D0, K=3D0, L=3D0, M=3D0.=20
   =20
   In case of STM-0, the values of S, U and K must be equal to zero=20
   according to the field coding rules. For instance, when requesting=20
   an unstructured VC-3 in an STM-0 the label is S=3D0, U=3D0, K=3D0, =
L=3D1,=20
   M=3D0.=20
   =20
   In case of STS-3c SPE, the value of S is the index of the first=20
   STS-1 of the STS-3c SPE in the SONET multiplex where SPEs are=20
   numbered from 1 to N (before any interleaving).=20
   =20
   When a transparent concatenated STM-N/STS-3*N (N=3D1, 4, 16, 64,=20
   256) is requested, the label is coded as for the case of=20
   contiguous concatenation and with S=3D1. I.e. S=3D1, U=3D0, K=3D0, =
L=3D0,=20
   M=3D0.=20
   =20
   =20
=20
E. Mannie Editor       Internet-Draft June 2002                     11=20
=0C
               draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20

4. Acknowledgments=20
   =20
   Valuable comments and input were received from many people.=20
   =20
   =20
5. Security Considerations=20
   =20
   This draft introduces no new security considerations to either=20
   [GMPLS-RSVP] or [GMPLS-LDP].=20
=20
=20
6. References=20
   =20
   [GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS -=20
               Signaling Functional Description", Internet Draft,=20
               draft-ietf-mpls-generalized-signaling-07.txt,=20
               November 2001.=20
   =20
   [GMPLS-LDP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling -=20
               CR-LDP Extensions", Internet Draft,=20
               draft-ietf-mpls-generalized-cr-ldp-05.txt,=20
               November 2001.=20
   =20
   [GMPLS-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS=20
                Signaling - RSVP-TE Extensions", Internet Draft,=20
                draft-ietf-mpls-generalized-rsvp-te-06.txt,=20
                November 2001.=20
   =20
   [GMPLS-SONET-SDH-EXT] E. Mannie Editor, "GMPLS extensions to=20
                control non-standard SONET and SDH features",=20
                Internet Draft, draft-ietf-ccamp-gmpls-sonet-sdh-=20
                extensions-01.txt, December 2001.=20
   =20
   [GMPLS-ARCH] E. Mannie Editor, "GMPLS Architecture", Internet=20
                Draft, draft-ietf-ccamp-gmpls-architecture-01.txt,=20
                November 2001.=20
   =20
   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=20
             Requirement Levels," RFC 2119.=20
=20
   [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated=20
             Services," RFC 2210, September 1997.=20
=20
=20
7. Authors Addresses=20
   =20
      Stefan Ansorge=20
      Alcatel=20
      Lorenzstrasse 10=20
      70435 Stuttgart=20
      Germany=20
      Phone: +49 7 11 821 337 44=20
      Email: [email-masked]=20
   =20
=20
E. Mannie Editor       Internet-Draft June 2002                     12=20
=0C
               draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20

      Peter Ashwood-Smith=20
      Nortel Networks Corp.=20
      P.O. Box 3511 Station C,=20
      Ottawa, ON K1Y 4H7=20
      Canada=20
      Phone:  +1 613 763 4534=20
      Email:  [email-masked]=20
=20
      Ayan Banerjee=20
      Calient Networks=20
      5853 Rue Ferrari=20
      San Jose, CA 95138=20
      Phone:  +1 408 972-3645=20
      Email:  [email-masked]=20
=20
      Lou Berger=20
      Movaz Networks, Inc.=20
      7926 Jones Branch Drive=20
      Suite 615=20
      McLean VA, 22102=20
      Phone:  +1 703 847-1801=20
      Email:  [email-masked]=20
   =20
      Greg Bernstein=20
      Ciena Corporation=20
      10480 Ridgeview Court=20
      Cupertino, CA 94014=20
      Phone:  +1 408 366 4713=20
      Email:  [email-masked]=20
   =20
      Angela Chiu=20
      Celion Networks=20
      One Sheila Drive, Suite 2=20
      Tinton Falls, NJ 07724-2658=20
      Phone: +1 732 747 9987=20
      Email: [email-masked]=20
   =20
      John Drake=20
      Calient Networks=20
      5853 Rue Ferrari=20
      San Jose, CA 95138=20
      Phone:  +1 408 972 3720=20
      Email:  [email-masked]=20
   =20
      Yanhe Fan=20
      Axiowave Networks, Inc.=20
      100 Nickerson Road=20
      Marlborough, MA 01752=20
      Phone:  +1 508 460 6969 Ext. 627=20
      Email:  [email-masked]=20
=20
=20
=20
=20
=20
E. Mannie Editor       Internet-Draft June 2002                     13=20
=0C
               draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20

      Michele Fontana=20
      Alcatel=20
      Via Trento 30,=20
      I-20059 Vimercate, Italy=20
      Phone: +39 039 686-7053=20
      Email: [email-masked]=20
=20
      Gert Grammel=20
      Alcatel=20
      Via Trento 30,=20
      I-20059 Vimercate, Italy=20
      Phone: +39 039 686-7060=20
      Email: [email-masked]=20
   =20
      Juergen Heiles=20
      Siemens AG=20
      Hofmannstr. 51=20
      D-81379 Munich, Germany=20
      Phone: +49 89 7 22 - 4 86 64=20
      Email: [email-masked]=20
=20
      Suresh Katukam=20
      Cisco Systems=20
      1450 N. McDowell Blvd,=20
      Petaluma, CA 94954-6515 USA=20
      e-mail: [email-masked]=20
=20
      Kireeti Kompella=20
      Juniper Networks, Inc.=20
      1194 N. Mathilda Ave.=20
      Sunnyvale, CA 94089=20
      Email:  [email-masked]=20
   =20
      Jonathan P. Lang=20
      Calient Networks=20
      25 Castilian=20
      Goleta, CA 93117=20
      Email:  [email-masked]=20
   =20
      Zhi-Wei Lin=20
      101 Crawfords Corner Rd=20
      Holmdel, NJ  07733-3030=20
      Phone: +1 732 949 5141=20
      Email: [email-masked]=20
   =20
      Ben Mack-Crane=20
      Tellabs=20
      Email: [email-masked]=20
=20
=20
=20
=20
=20
=20
=20
E. Mannie Editor       Internet-Draft June 2002                     14=20
=0C
               draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20

      Eric Mannie=20
      EBONE=20
      Terhulpsesteenweg 6A=20
      1560 Hoeilaart - Belgium=20
      Phone:  +32 2 658 56 52=20
      Mobile: +32 496 58 56 52=20
      Fax:    +32 2 658 51 18=20
      Email:  [email-masked]=20
=20
      Dimitri Papadimitriou=20
      Alcatel=20
      Francis Wellesplein 1,=20
      B-2018 Antwerpen, Belgium=20
      Phone: +32 3 240-8491=20
      Email: [email-masked]=20
   =20
      Mike Raftelis=20
      White Rock Networks=20
      18111 Preston Road Suite 900=20
      Dallas, TX 75252=20
      Phone: +1 (972)588-3728=20
      Fax:   +1 (972)588-3701=20
      Email: [email-masked]=20
   =20
      Bala Rajagopalan=20
      Tellium, Inc.=20
      2 Crescent Place=20
      P.O. Box 901=20
      Oceanport, NJ 07757-0901=20
      Phone:  +1 732 923 4237=20
      Fax:    +1 732 923 9804=20
      Email:  [email-masked]=20
   =20
      Yakov Rekhter=20
      Juniper Networks, Inc.=20
      Email:  [email-masked]=20
   =20
      Debanjan Saha=20
      Tellium Optical Systems=20
      2 Crescent Place=20
      Oceanport, NJ 07757-0901=20
      Phone:  +1 732 923 4264=20
      Fax:    +1 732 923 9804=20
      Email:  [email-masked]=20
   =20
      Vishal Sharma=20
      Metanoia, Inc.=20
      335 Elan Village Lane=20
      San Jose, CA 95134=20
      Phone:  +1 408 943 1794=20
      Email: [email-masked]=20
   =20
   =20
   =20
=20
E. Mannie Editor       Internet-Draft June 2002                     15=20
=0C
               draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20

      George Swallow=20
      Cisco Systems, Inc.=20
      250 Apollo Drive=20
      Chelmsford, MA 01824=20
      Voice:  +1 978 244 8143=20
      Email:  [email-masked]=20
=20
      Z. Bo Tang=20
      Tellium, Inc.=20
      2 Crescent Place=20
      P.O. Box 901=20
      Oceanport, NJ 07757-0901=20
      Phone:  +1 732 923 4231=20
      Fax:    +1 732 923 9804=20
      Email:  [email-masked]=20
=20
      Eve Varma=20
      101 Crawfords Corner Rd=20
      Holmdel, NJ  07733-3030=20
      Phone: +1 732 949 8559=20
      Email: [email-masked]=20
=20
      Maarten Vissers=20
      Botterstraat 45=20
      Postbus 18=20
      1270 AA Huizen, Netherlands=20
      Email: [email-masked]=20
   =20
      Yangguang Xu=20
      21-2A41, 1600 Osgood Street=20
      North Andover, MA 01845=20
      Email: [email-masked]=20
   =20

=20
E. Mannie Editor       Internet-Draft June 2002                     16=20
=0C
               draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20

Appendix 1 - Signal Type Values Extension For VC-3=20
   =20
   This appendix defines the following optional additional Signal=20
   Type value for the Signal Type field of section 2.1:=20
   =20
       Value         Type=20
       -----  ---------------------=20
        20     "VC-3 via AU-3 at the end"=20
   =20
   According to the G.707 standard a VC-3 in the TU-3/TUG-3/VC-4/AU-4=20
   branch of the SDH multiplex cannot be structured in TUG-2s,=20
   however a VC-3 in the AU-3 branch can be. In addition, a VC-3=20
   could be switched between the two branches if required.=20
=20
   A VC-3 circuit could be terminated on an ingress interface of an=20
   LSR (e.g. forming a VC-3 forwarding adjacency). This LSR could=20
   then want to demultiplex this VC-3 and switch internal low order=20
   LSPs. For implementation reasons, this could be only possible if=20
   the LSR receives the VC-3 in the AU-3 branch. E.g. for an LSR not=20
   able to switch internally from a TU-3 branch to an AU-3 branch on=20
   its incoming interface before demultiplexing and then switching=20
   the content with its switch fabric.=20
   =20
   In that case it is useful to indicate that the VC-3 LSP must be=20
   terminated at the end in the AU-3 branch instead of the TU-3=20
   branch.=20
   =20
   This is achieved by using the "VC-3 via AU-3 at the end" signal=20
   type. This information can be used, for instance, by the=20
   penultimate LSR to switch an incoming VC-3 received in any branch=20
   to the TU-3 branch on the outgoing interface to the destination=20
   LSR.=20
   =20
   The "VC-3 via AU-3 at the end" signal type does not imply that the=20
   VC-3 must be switched via the AU-3 branch at some other places in=20
   the network. The VC-3 signal type just indicates that a VC-3 in=20
   any branch is suitable.=20

=20
E. Mannie Editor       Internet-Draft June 2002                     17=20
=0C
               draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20

Annex 1 - Examples=20
   =20
   This annex defines examples of SONET and SDH signal coding. Their=20
   objective is to help the reader to understand how works the traffic=20
   parameter coding and not to give examples of typical SONET or SDH=20
   signals.=20
   =20
   As stated above, signal types are Elementary Signals to which=20
   successive concatenation, multiplication and transparency=20
   transforms can be applied.=20
   =20
   1. A VC-4 signal is formed by the application of RCC with value 0,=20
   NCC with value 0, NVC with value 0, MT with value 1 and T with=20
   value 0 to a VC-4 Elementary Signal.=20
   =20
   2. A VC-4-7v signal is formed by the application of RCC with value=20
   0, NCC with value 0, NVC with value 7 (virtual concatenation of 7=20
   components), MT with value 1 and T with value 0 to a VC-4=20
   Elementary Signal.=20
   =20
   3. A VC-4-16c signal is formed by the application of RCC with flag=20
   1 (standard contiguous concatenation), NCC with value 16, NVC with=20
   value 0, MT with value 1 and T with value 0 to a VC-4 Elementary=20
   Signal.=20
   =20
   4. An STM-16 signal with Multiplex Section layer transparency is=20
   formed by the application of RCC with value 0, NCC with value 0,=20
   NVC with value 0, MT with value 1 and T with flag 2 to an STM-16=20
   Elementary Signal.=20
=20
   5. An STM-4c signal (i.e. VC-4-4C with the transport overhead)=20
   with Multiplex Section layer transparency is formed by the=20
   application of RCC with flag 1, NCC with value 1, NVC with value=20
   0, MT with value 1 and T with flag 2 applied to an STM-4=20
   Elementary Signal.=20
   =20
   6. An STM-256c signal with Multiplex Section layer transparency is=20
   formed by the application of RCC with flag 1, NCC with value 1,=20
   NVC with value 0, MT with value 1 and T with flag 2 applied to an=20
   STM-256 Elementary Signal.=20
   =20
   7. An STS-1 SPE signal is formed by the application of RCC with=20
   value 0, NCC with value 0, NVC with value 0, MT with value 1 and T=20
   with value 0 to an STS-1 SPE Elementary Signal.=20
   =20
   8. An STS-3c SPE signal is formed by the application of RCC with=20
   value 0 (no contiguous concatenation), NCC with value 0, NVC with=20
   value 0, MT with value 1 and T with value 0 to an STS-3c SPE=20
   Elementary Signal.=20
   =20
   9. An STS-48c SPE signal is formed by the application of RCC with=20
   flag 1 (standard contiguous concatenation), NCC with value 16, NVC=20
   with value 0, MT with value 1 and T with value 0 to an STS-3c SPE=20
   Elementary Signal.=20
=20
E. Mannie Editor       Internet-Draft June 2002                     18=20
=0C
               draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20

   =20
   10. An STS-1-3v SPE signal is formed by the application of RCC=20
   with value 0, NVC with value 3 (virtual concatenation of 3=20
   components), MT with value 1 and T with value 0 to an STS-1 SPE=20
   Elementary Signal.=20
   =20
   11. An STS-3c-9v SPE signal is formed by the application of RCC=20
   with value 0, NCC with value 0, NVC with value 9 (virtual=20
   concatenation of 9 STS-3c), MT with value 1 and T with value 0 to=20
   an STS-3c SPE Elementary Signal.=20
   =20
   12. An STS-12 signal with Section layer (full) transparency is=20
   formed by the application of RCC with value 0, NVC with value 0,=20
   MT with value 1 and T with flag 1 to an STS-12 Elementary Signal.=20
=20
   13. 3 x STS-768c SPE signal is formed by the application of RCC=20
   with flag 1, NCC with value 256, NVC with value 0, MT with value=20
   3, and T with value 0 to an STS-3c SPE Elementary Signal.=20
   =20
   14. 5 x VC-4-13v composed signal is formed by the application of=20
   RCC with value 0, NVC with value 13, MT with value 5 and T with=20
   value 0 to a VC-4 Elementary Signal.=20

=20
E. Mannie Editor       Internet-Draft June 2002                     19=20
=0C
------_=_NextPart_000_01C18432.3B958350
Content-Type: application/octet-stream;
	name="draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt"

   CCAMP Working Group                   Eric Mannie (Ebone) - Editor=20
   Internet Draft                            =20
   Expiration Date: June 2002                Stefan Ansorge (Alcatel)=20
                                         Peter Ashwood-Smith (Nortel)=20
                                              Ayan Banerjee (Calient)=20
                                                   Lou Berger (Movaz)=20
                                               Greg Bernstein (Ciena)=20
                                                 Angela Chiu (Celion)=20
                                                 John Drake (Calient)=20
                                                 Yanhe Fan (Axiowave)=20
                                            Michele Fontana (Alcatel)=20
                                               Gert Grammel (Alcatel)=20
                                              Juergen Heiles(Siemens)=20
                                               Suresh Katukam (Cisco)=20
                                           Kireeti Kompella (Juniper)=20
                                           Jonathan P. Lang (Calient)=20
                                                  Fong Liaw (Zaffire)=20
                                                 Zhi-Wei Lin (Lucent)=20
                                             Ben Mack-Crane (Tellabs)=20
                                      Dimitri Papadimitriou (Alcatel)=20
                                       Dimitrios Pendarakis (Tellium)=20
                                           Mike Raftelis (White Rock)=20
                                           Bala Rajagopalan (Tellium)=20
                                              Yakov Rekhter (Juniper)=20
                                              Debanjan Saha (Tellium)=20
                                             Vishal Sharma (Metanoia)=20
                                               George Swallow (Cisco)=20
                                                 Z. Bo Tang (Tellium)=20
                                                   Eve Varma (Lucent)=20
                                             Maarten Vissers (Lucent)=20
                                                Yangguang Xu (Lucent)=20
   =20
                                                        December 2001=20
   =20
   =20
    GMPLS Extensions to Control Non-Standard SONET and SDH Features=20
   =20
   =20
         draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt=20
   =20
=20
Status of this Memo=20
   =20
   This document is an Internet-Draft and is in full conformance with=20
   all provisions of Section 10 of RFC2026.  Internet-Drafts are=20
   working documents of the Internet Engineering Task Force (IETF),=20
   its areas, and its working groups.  Note that other groups may=20
   also distribute working documents as Internet-Drafts.=20
   =20
   Internet-Drafts are draft documents valid for a maximum of six=20
   months and may be updated, replaced, or obsoleted by other=20
   documents at any time. It is inappropriate to use Internet-Drafts=20
   as reference material or to cite them other than as "work in=20
   progress."=20
=20
E. Mannie Editor                                                     1=20
=0C
  draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt  December, 2001=20

   =20
   To view the current status of any Internet-Draft, please check the=20
   "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow=20
   Directory, see http://www.ietf.org/shadow.html.=20
=20
=20
Abstract=20
   =20
   This document is a companion to the GMPLS signaling extensions to=20
   control SONET and SDH document [GMPLS-SONET-SDH] that defines the=20
   SONET/SDH technology specific information needed when using GMPLS=20
   signaling.=20
   =20
   This informational document defines GMPLS signaling extensions to=20
   control four optional non-standard (i.e. proprietary) SONET and=20
   SDH features: group signals, arbitrary concatenation, virtual=20
   concatenation of contiguously concatenated signals and per byte=20
   transparency.=20
   =20
   =20
1. Introduction=20
   =20
   Generalized MPLS (GMPLS) [GMPLS-ARCH] extends MPLS from supporting=20
   packet (Packet Switching Capable - PSC) interfaces and switching=20
   to include support of four new classes of interfaces and=20
   switching: Layer-2 Switch Capable (L2SC), Time-Division Multiplex=20
   (TDM), Lambda Switch Capable (LSC) and Fiber-Switch Capable (FSC).=20
   =20
   A functional description of the extensions to MPLS signaling=20
   needed to support the new classes of interfaces and switching is=20
   provided in [GMPLS-SIG]. [GMPLS-RSVP] describes RSVP-TE specific=20
   formats and mechanisms needed to support all five classes of=20
   interfaces, and CR-LDP extensions can be found in [GMPLS-LDP]. =20
   =20
   [GMPLS-SONET-SDH] presents details that are specific to SONET/SDH.=20
   Per [GMPLS-SIG], SONET/SDH specific parameters are carried in the=20
   signaling protocol in traffic parameter specific objects.=20
   =20
   This informational document defines GMPLS signaling extensions to=20
   control four optional non-standard (i.e. proprietary) SONET/SDH=20
   features: group signals (section 2), arbitrary concatenation=20
   (section 3), virtual concatenation of contiguously concatenated=20
   signals (section 4), and per byte transparency (section 5).=20
   Section 6 gives examples of SONET/SDH traffic parameters (also=20
   referred to as signal coding) when requesting a SONET/SDH LSP.=20
   =20
   Such features are already implemented or under development by a=20
   significant number of manufacturers. For instance, arbitrary=20
   concatenation is already implemented in many legacy SONET and SDH=20
   equipment that don't support any byte-oriented protocol based=20
   control plane.=20
   =20

=20
E. Mannie Editor       Internet-Draft June 2002                      2=20
=0C
  draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt  December, 2001=20

   This document doesn't specify how to implement these features in=20
   the transmission plane but how to control their usage with a GMPLS=20
   control plane.=20
   =20
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL=20
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"=20
   in this document are to be interpreted as described in [RFC2119].=20
=20
=20
2. Signal Type Values Extension For Group Signals=20
   =20
   This section defines the following optional additional Signal Type=20
   values for the Signal Type field of section 2.1 of [GMPLS-SONET-
   SDH]:=20
   =20
       Value         Type=20
       -----  ---------------------=20
        13     VTG      / TUG-2=20
        14                TUG-3=20
        15     STSG-3   / AUG-1=20
        16     STSG-12  / AUG-4=20
        17     STSG-48  / AUG-16=20
        18     STSG-192 / AUG-64=20
        19     STSG-768 / AUG-256=20
   =20
  Administrative Unit Group-Ns (AUG-Ns) and STS Groups-3*Ns (STSG-Ms),=20
  are logical objects defined as a collection of AU-3s/STS-1 SPEs, AU-
  4s/STS-3c SPEs and/or AU-4-Xcs/STS-3*Xc SPEs (X =3D 4,16,64,256).=20
  =20
  When used as a signal type this means that all the VC-3s/STS-1_SPEs,=20
  VC-4s/STS-3c_SPEs or VC-4-Xcs/STS-3*Xc SPEs in the AU-3s/STS-1 SPEs,=20
  AU-4s/STS-3c SPEs or AU-4-Xcs/STS-3*Xc SPEs that comprise the AUG-
  N/STSG-3*N are switched together as one unique signal.=20
  =20
  In addition the structure of the VC-3s/STS-1_SPEs, VC-4s/STS-3c_SPEs=20
  and VC-4-Xcs/STS-3*Xc_SPEs in the AUG-N/STSG-3*N are preserved and=20
  are allowed to change over the life of an AUG-N/STSG-3*N.=20
  =20
  It is this flexibility in the relationships between the component VCs =

  or SPEs that differentiates this signal from a set of VC-3s/STS-
  1_SPEs, VC-4s/STS-3c_SPEs or VC-4-Xcs/STS-3*Xc_SPEs. Whether the AUG-
  N/STSG-3*N is structured with AU-3s/STS-1 SPEs, AU-4s/STS-3c SPEs=20
  and/or AU-4-Xcs/STS-3*Xc SPEs does not need to be specified and is=20
  allowed to change over time. The same reasoning applies to TUG-2/VTG=20
  and TUG-3 signal types.=20
   =20
  For example an STSG-48 could at one time consist of four STS-12c=20
  signals and at another point in time of three STS-12c signals and=20
  four STS-3c signals. =20
  =20
  Note that the use of VTG, TUG-X, AUG-N and STSG-M as circuit types is =

  not described in ANSI and ITU-T standards. These signal types are=20
  conceptual objects that intend to designate a group of physical=20
  objects in the data plane.=20
=20
E. Mannie Editor       Internet-Draft June 2002                      3=20
=0C
  draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt  December, 2001=20

=20
=20
3. Contiguous Concatenation Extension=20
   =20
   This section defines the following optional extension flag for the=20
   Requested Contiguous Concatenation (RCC) field defined in section=20
   2.1 of [GMPLS-SONET-SDH]:=20
   =20
      Flag 2 (bit 2): Arbitrary contiguous concatenation.=20
   =20
   This flag allows an upstream node to signal to a downstream node=20
   that it supports arbitrary contiguous concatenation. This type of=20
   concatenation is not defined by ANSI or ITU-T.=20
   =20
   Arbitrary contiguous concatenation allows the contiguous=20
   concatenation of any number X of VC-4/STS-1 SPE/STS-3c SPE with X=20
   less or equal N, resulting in a VC-4-Xa/STS-1-Xa SPE/STS-3c-Xa SPE=20
   signal. In addition, it allows the arbitrary contiguous=20
   concatenated signal to start at any location (AU-4/STS-1 timeslot)=20
   in the STM-N/STS-N signal.=20
   =20
   This flag can be setup together with Flag 1 (Standard Contiguous=20
   Concatenation) to give a choice to the downstream node. The=20
   resulting type of contiguous concatenation can be different at=20
   each hop according to the result of the negotiation.=20
   =20
   A label is assigned following the same rule as for the Standard=20
   Contiguous Concatenation (see [GMPLS-SONET-SDH]).=20
=20
=20
4. Virtual Concatenation Extension=20
   =20
   This section defines the following optional extension for the=20
   signals that can be virtually concatenated.=20
   =20
   In addition to the elementary signal types, which can be virtual=20
   concatenated as described in section 2.1 of [GMPLS-SONET-SDH],=20
   identical contiguously concatenated signals may be virtually=20
   concatenated. In this last case, it allows for instance to request=20
   the virtual concatenation of several VC-4-4c/STS-12c SPEs (i.e.=20
   per [GMPLS-SONET-SDH] (STS-3c)-4c SPE), or more generally any VC-
   4-Xc/STS-3c-Xc SPEs to obtain a VC-4-Xc-Yv/STS-3c-Xc-Yv.=20
   =20
   The virtual concatenation can also be applied to arbitrary=20
   contiguously concatenated signals to form VC-4-Xa-Yv/STS-1-Xa-Yv=20
   SPE/STS-3c-Xa-Yv SPE. Note that STS-3c-Xa-Yv SPE signal is=20
   described only for completeness of the mechanism defined in this=20
   document.=20
   =20
   The standard definition for virtual concatenation allows each=20
   virtual concatenation components to travel over diverse paths.=20
   Within GMPLS, virtual concatenation components must travel over=20
   the same (component) link if they are part of the same LSP. This=20
   is due to the way that labels are bound to a (component) link.=20
=20
E. Mannie Editor       Internet-Draft June 2002                      4=20
=0C
  draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt  December, 2001=20

   Note however, that the routing of components on different paths is=20
   indeed equivalent to establishing different LSPs, each one having=20
   its own route. Several LSPs can be initiated and terminated=20
   between the same nodes and their corresponding components can then=20
   be associated together (i.e. virtually concatenated).=20
=20
   In case of virtual concatenation of a contiguously concatenated=20
   signal, the same rule as described in section 3 of [GMPLS-SONET-
   SD] for virtual concatenation applies, except that a component of=20
   the virtually concatenated signal is now a contiguously=20
   concatenated signal. The first label indicates the first=20
   contiguously concatenated signal; the second label indicates the=20
   second contiguously concatenated signal, and so on.=20
=20
=20
5. Transparency Extension=20
   =20
   This section defines the following optional extension for the=20
   Transparency field defined in section 2.1 of [GMPLS-SONET-SDH].=20
   =20
  This "extended" transparency (simply referred here as=20
  transparency) can be requested for a particular SOH/RSOH or=20
  MSOH/LOH field in the STM-N/STS-N signal.=20
  =20
  Transparency is not applied at the interfaces of the initiating=20
  and terminating LSRs, but is only applied between intermediate=20
  LSRs. Moreover, the transparency extensions can be implemented=20
  effectively in very different ways, e.g. by forwarding the=20
  corresponding overhead bytes unmodified, or by tunneling the=20
  bytes. =20
  =20
  This document specifies neither how transparency is achieved; nor=20
  the behavior of the signal at the egress of the transparent=20
  network during fault conditions at the ingress of the transparent=20
  network or within the transparent network; nor network deployment=20
  scenarios. The signaling is independent of these considerations.=20
  =20
  When the signaling is used between intermediate nodes it is up to=20
  a data plane profile or specification to indicate how transparency=20
  is effectively achieved in the data plane. When the signaling is=20
  used at the interfaces with the initiating and terminating LSRs it=20
  is up to the data plane specification to guarantee compliant=20
  behavior to G.707/T1.105 under fault free and fault conditions.=20
  =20
  Note that B1 in the SOH/RSOH is computed over the complete=20
  previous frame, if one bit changes, B1 must be re-computed. Note=20
  that B2 in the LOH/MSOH is also computed over the complete=20
  previous frame, except the SOH/RSOH.=20
  =20
  =20
  =20
  =20
  =20
  =20
=20
E. Mannie Editor       Internet-Draft June 2002                      5=20
=0C
  draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt  December, 2001=20

  The different transparency extension flags are the following:=20
       =20
       Flag 3  (bit 3) : J0.=20
       Flag 4  (bit 4) : SOH/RSOH DCC (D1-D3).=20
       Flag 5  (bit 5) : LOH/MSOH DCC (D4-D12).=20
       Flag 6  (bit 6) : LOH/MSOH Extended DCC (D13-D156).=20
       Flag 7  (bit 7) : K1/K2.=20
       Flag 8  (bit 8) : E1.=20
       Flag 9  (bit 9) : F1.=20
       Flag 10 (bit 10): E2.=20
       Flag 11 (bit 11): B1.=20
       Flag 12 (bit 12): B2.=20
       Flag 13 (bit 13): M0.=20
       Flag 14 (bit 14): M1.=20
  =20
  Line/Multiplex Section layer transparency (refer to section 2.1 of=20
  [GMPLS-SONET-SDH]) can be combined only with any of the following=20
  transparency types: J0, SOH/RSOH DCC (D1-D3), E1, F1; and all=20
  other transparency flags must be ignored.=20
  =20
  Note that the extended LOH/MSOH DCC (D13-D156) is only applicable=20
  to (defined for) STS-768/STM-256.=20
   =20
   If B1 transparency is requested, this means transparency for the bit =

   error supervision functionality provided by the B1. The B1 contains=20
   the BIP8 calculated over the previous RS/Section frame of the STM-
   N/STS-N signal at the RS/Section termination source. At the=20
   RS/Section termination sink the B1 BIP is compared with the local=20
   BIP also calculated over the previous RS/Section frame of the STM-
   N/STS-N. Any difference between the two BIP values is an indication=20
   for a bit error that occurred between the termination source and=20
   sink. In case of B1 transparency this functionality shall be=20
   preserved. This means that a B1 bit error detection as described=20
   above performed after the transparent transport (at a RS/Section=20
   termination sink) indicates exactly the bit errors that occur=20
   between the B1 insertion point (RS/Section termination source) and=20
   this point. Any intended changes to the previous RS/Section frame=20
   content due to the implementation of the transparency feature (e.g.=20
   modifications of the RS/Section overhead, modifications of the=20
   payload due to pointer justifications) have to be reflected in the=20
   B1 BIP value, it has to be adjusted accordingly.=20
   =20
   If B2 transparency is requested, this means transparency for the bit =

   error supervision functionality provided by the B2. The B2 contains=20
   the BIP24*N/BIP8*N calculated over the previous MS/Line frame of the =

   STM-N/STS-N signal at the MS/Line termination source. At the MS/Line =

   termination sink the B2 BIP is compared with the local BIP also=20
   calculated over the previous MS/Line frame of the STM-N/STS-N. Any=20
   difference between the two BIP values is an indication for a bit=20
   error that occurred between the termination source and sink. In case =

   of B2 transparency this functionality shall be preserved. This means =

   that a B2 bit error detection as described above performed after the =

   transparent transport (at a MS/Line termination sink) indicates=20
   exactly the bit errors that occur between the B2 insertion point=20
=20
E. Mannie Editor       Internet-Draft June 2002                      6=20
=0C
  draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt  December, 2001=20

   (MS/Line termination source) and this point. Any intended changes to =

   the previous MS/Line frame content due to the implementation of the=20
   transparency feature (e.g. modifications of the MS/Line overhead,=20
   modifications of the payload due to pointer justifications) have to=20
   be reflected in the B2 BIP value, it has to be adjusted accordingly. =
=20
   =20
   M1 and M1/M0 transparency are only meaningful when the B2=20
   transparency is requested.=20
   =20
   =20
6. Examples=20
   =20
   This section defines examples of SONET and SDH signal coding. Their=20
   objective is to help the reader to understand how works the traffic=20
   parameter coding and not to give examples of typical SONET or SDH=20
   signals.=20
   =20
   As stated in [GMPLS_SONET_SDH], signal types are Elementary=20
   Signals to which successive concatenation, multiplication and=20
   transparency transforms can be applied.=20
   =20
   1. An STM-64 signal with RSOH and MSOH DCCs transparency is formed=20
   by the application of RCC with value 0, NCC with value 0, NVC with=20
   value 0, MT with value 1 and T with flag 4 and 5 to an STM-64=20
   Elementary Signal.=20
=20
   2. An STS-192 signal with K1/K2 and LOH DCC transparency is formed=20
   by the application of RCC with value 0, NVC with value 0, MT with=20
   value 1 and T with flags 5 and 7 to an STS-192 Elementary Signal.=20
   =20
   3. An STS-48c signal with LOH DCC and E2 transparency is formed by=20
   the application of RCC with flag 1, NCC with value 1, NVC with=20
   value 0, MT with value 1 and T with flag 5 and 10 to an STS-48=20
   Elementary Signal.=20
   =20
   4. An STS-768c signal with K1/K2 and LOH DCC transparency is=20
   formed by the application of RCC with flag 1, NCC with value 1,=20
   NVC with value 0, MT with value 1 and T with flag 5 and 7 to an=20
   STS-768 Elementary Signal.=20
   =20
   5. 4 x STS-12 signals with K1/K2 and LOH DCC transparency is=20
   formed by the application of RCC with value 0, NVC with value 0,=20
   MT with value 4 and T with flags 5 and 7 to an STS-12 Elementary=20
   Signal.=20
   =20
   6. A VC-4-3a signal is formed by the application of RCC with flag=20
   2 (arbitrary contiguous concatenation), NCC with value 3, NVC with=20
   value 0, MT with value 1 and T with value 0 to a VC-4 Elementary=20
   Signal.=20
   =20
   7. An STS-1-34a SPE signal is formed by the application of RCC=20
   with flag 2 (arbitrary contiguous concatenation), NCC with value=20
   34, NVC with value 0, MT with value 1 and T with value 0 to an=20
   STS-1 SPE Elementary Signal.=20
=20
E. Mannie Editor       Internet-Draft June 2002                      7=20
=0C
  draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt  December, 2001=20

   =20
   8. 2 x STS-1-4a-5v SPE signal is formed by the application of RCC=20
   with flag 2 (for arbitrary contiguous concatenation), NCC with=20
   value 4, NVC with value 5, MT with value 2 and T with value 0 to=20
   an STS-1 SPE Elementary Signal.=20
=20
=20
7. Acknowledgments=20
   =20
   Valuable comments and input were received from many people.=20
   =20
   =20
8. Security Considerations=20
   =20
   This draft introduces no new security considerations to [GMPLS-
   SONET-SDH].=20
=20
=20
9. References=20
   =20
   [GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS -=20
               Signaling Functional Description", Internet Draft,=20
               draft-ietf-mpls-generalized-signaling-07.txt,=20
               November 2001.=20
   =20
   [GMPLS-LDP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling -=20
               CR-LDP Extensions", Internet Draft,=20
               draft-ietf-mpls-generalized-cr-ldp-05.txt,=20
               November 2001.=20
   =20
   [GMPLS-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS=20
                Signaling - RSVP-TE Extensions", Internet Draft,=20
                draft-ietf-mpls-generalized-rsvp-te-06.txt,=20
                November 2001.=20
   =20
   [GMPLS-SONET-SDH] E. Mannie Editor, "GMPLS extensions for SONET=20
                and SDH control", Internet Draft,=20
                draft-ietf-ccamp-gmpls-sonet-sdh-03.txt, December=20
                2001.=20
   =20
   [GMPLS-ARCH] E. Mannie Editor, "GMPLS Architecture", Internet=20
                Draft, draft-ietf-ccamp-gmpls-architecture-01.txt,=20
                November 2001.=20
   =20
   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=20
             Requirement Levels," RFC 2119.=20
=20
=20
=20
=20
=20
=20
=20
=20
=20
E. Mannie Editor       Internet-Draft June 2002                      8=20
=0C
  draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt  December, 2001=20

10. Authors Addresses=20
   =20
      Stefan Ansorge=20
      Alcatel=20
      Lorenzstrasse 10=20
      70435 Stuttgart=20
      Germany=20
      Phone: +49 7 11 821 337 44=20
      Email: [email-masked]=20
   =20
      Peter Ashwood-Smith=20
      Nortel Networks Corp.=20
      P.O. Box 3511 Station C,=20
      Ottawa, ON K1Y 4H7=20
      Canada=20
      Phone:  +1 613 763 4534=20
      Email:  [email-masked]=20
   =20
      Ayan Banerjee=20
      Calient Networks=20
      5853 Rue Ferrari=20
      San Jose, CA 95138=20
      Phone:  +1 408 972-3645=20
      Email:  [email-masked]=20
   =20
      Lou Berger=20
      Movaz Networks, Inc.=20
      7926 Jones Branch Drive=20
      Suite 615=20
      McLean VA, 22102=20
      Phone:  +1 703 847-1801=20
      Email:  [email-masked]=20
   =20
      Greg Bernstein=20
      Ciena Corporation=20
      10480 Ridgeview Court=20
      Cupertino, CA 94014=20
      Phone:  +1 408 366 4713=20
      Email:  [email-masked]=20
   =20
      Angela Chiu=20
      Celion Networks=20
      One Sheila Drive, Suite 2=20
      Tinton Falls, NJ 07724-2658=20
      Phone: +1 732 747 9987=20
      Email: [email-masked]=20
   =20
      John Drake=20
      Calient Networks=20
      5853 Rue Ferrari=20
      San Jose, CA 95138=20
      Phone:  +1 408 972 3720=20
      Email:  [email-masked]=20
   =20
=20
E. Mannie Editor       Internet-Draft June 2002                      9=20
=0C
  draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt  December, 2001=20

      Yanhe Fan=20
      Axiowave Networks, Inc.=20
      100 Nickerson Road=20
      Marlborough, MA 01752=20
      Phone:  +1 508 460 6969 Ext. 627=20
      Email:  [email-masked]=20
=20
      Michele Fontana=20
      Alcatel=20
      Via Trento 30,=20
      I-20059 Vimercate, Italy=20
      Phone: +39 039 686-7053=20
      Email: [email-masked]=20
=20
      Gert Grammel=20
      Alcatel=20
      Via Trento 30,=20
      I-20059 Vimercate, Italy=20
      Phone: +39 039 686-7060=20
      Email: [email-masked]=20
=20
      Juergen Heiles=20
      Siemens AG=20
      Hofmannstr. 51=20
      D-81379 Munich, Germany=20
      Phone: +49 89 7 22 - 4 86 64=20
      Email: [email-masked]=20
=20
      Suresh Katukam=20
      Cisco Systems=20
      1450 N. McDowell Blvd,=20
      Petaluma, CA 94954-6515 USA=20
      e-mail: [email-masked]=20
=20
      Kireeti Kompella=20
      Juniper Networks, Inc.=20
      1194 N. Mathilda Ave.=20
      Sunnyvale, CA 94089=20
      Email:  [email-masked]=20
   =20
      Jonathan P. Lang=20
      Calient Networks=20
      25 Castilian=20
      Goleta, CA 93117=20
      Email:  [email-masked]=20
   =20
      Zhi-Wei Lin=20
      101 Crawfords Corner Rd=20
      Holmdel, NJ  07733-3030=20
      Phone: +1 732 949 5141=20
      Email: [email-masked]=20
   =20
   =20
   =20
=20
E. Mannie Editor       Internet-Draft June 2002                     10=20
=0C
  draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt  December, 2001=20

      Ben Mack-Crane=20
      Tellabs=20
      Email: [email-masked]=20
=20
      Eric Mannie=20
      EBONE=20
      Terhulpsesteenweg 6A=20
      1560 Hoeilaart - Belgium=20
      Phone:  +32 2 658 56 52=20
      Mobile: +32 496 58 56 52=20
      Fax:    +32 2 658 51 18=20
      Email:  [email-masked]=20
=20
      Dimitri Papadimitriou=20
      Alcatel=20
      Francis Wellesplein 1,=20
      B-2018 Antwerpen, Belgium=20
      Phone: +32 3 240-8491=20
      Email: [email-masked]=20
=20
      Mike Raftelis=20
      White Rock Networks=20
      18111 Preston Road Suite 900=20
      Dallas, TX 75252=20
      Phone: +1 (972)588-3728=20
      Fax:   +1 (972)588-3701=20
      Email: [email-masked]=20
   =20
      Bala Rajagopalan=20
      Tellium, Inc.=20
      2 Crescent Place=20
      P.O. Box 901=20
      Oceanport, NJ 07757-0901=20
      Phone:  +1 732 923 4237=20
      Fax:    +1 732 923 9804=20
      Email:  [email-masked]=20
   =20
      Yakov Rekhter=20
      Juniper Networks, Inc.=20
      Email:  [email-masked]=20
   =20
      Debanjan Saha=20
      Tellium Optical Systems=20
      2 Crescent Place=20
      Oceanport, NJ 07757-0901=20
      Phone:  +1 732 923 4264=20
      Fax:    +1 732 923 9804=20
      Email:  [email-masked]=20
   =20
   =20
   =20
   =20
   =20
   =20
=20
E. Mannie Editor       Internet-Draft June 2002                     11=20
=0C
  draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt  December, 2001=20

      Vishal Sharma=20
      Metanoia, Inc.=20
      335 Elan Village Lane=20
      San Jose, CA 95134=20
      Phone:  +1 408 943 1794=20
      Email: [email-masked]=20
   =20
      George Swallow=20
      Cisco Systems, Inc.=20
      250 Apollo Drive=20
      Chelmsford, MA 01824=20
      Voice:  +1 978 244 8143=20
      Email:  [email-masked]=20
=20
      Z. Bo Tang=20
      Tellium, Inc.=20
      2 Crescent Place=20
      P.O. Box 901=20
      Oceanport, NJ 07757-0901=20
      Phone:  +1 732 923 4231=20
      Fax:    +1 732 923 9804=20
      Email:  [email-masked]=20
=20
      Eve Varma=20
      101 Crawfords Corner Rd=20
      Holmdel, NJ  07733-3030=20
      Phone: +1 732 949 8559=20
      Email: [email-masked]=20
=20
      Maarten Vissers=20
      Botterstraat 45=20
      Postbus 18=20
      1270 AA Huizen, Netherlands=20
      Email: [email-masked]=20
   =20
      Yangguang Xu=20
      21-2A41, 1600 Osgood Street=20
      North Andover, MA 01845=20
      Email: [email-masked]=20

=20
E. Mannie Editor       Internet-Draft June 2002                     12=20
=0C
------_=_NextPart_000_01C18432.3B958350--

Delivery-date: Thu, 13 Dec 2001 12:26:35 -0800
Date: Thu, 13 Dec 2001 13:15:16 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
CC: Maarten Vissers <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

John,
It would seem from this standpoint, ANY transport plane protection
must use "primary" for all trails. You have already made this argument
for the 1+1 case to carry the permanently bridged copy of the payload.

In 1:1 or 1:n, when protection is not being used to carry one/any of
the normal traffic signals, it may either carry a null signal (no bridge)
or transport plane extra traffic. Even if the transport plane has only
a null signal on protection, the control plane cannot itself place extra
traffic on any portion of the end-to-end protection channel as this is
where the APS protocol is carried to coordinate the 1:1 or 1:n protection.
The protection channel overhead is chosen to carry the APS since it is
necessary to exchange APS bytes to complete a switch when working channels
are failed. If the protection channel has failed and APS cannot be exchanged,
normal traffic signals will not be selected from protection.
Regards,
Steve

John Drake wrote:
> 
> Maarten,
> 
> That's fine, however it's beside the point.  The semantics of
> Primary/Secondary refer to the control plane and whether the node
> establishing a given LSP is planning to use it at the time it's established
> or at a later time.  As I indicated in an earlier note, 1+1 transport plane
> protection would be accomplished in the control plane by establishing two
> LSPs of type Primary.  The control plane really doesn't care which LSP the
> transport plane is using as Working and which as Protect, although that
> information is available to the control plane at the LSP endpoints.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Thursday, December 13, 2001 12:15 AM
> To: [email-masked]
> Subject: Re: Moving right along ... generalized-signaling-06
> 
> There exist well defined protection terminology in ITU-T for the transport
> plane. "Working" and "Protection" are being used and not primary/secondary.
> E.g.
> a 1+1 architecture has one working connection, one protection connection and
> a
> permanent bridge.
> 
> Besides working/protection indication for the transport entity, there is
> - "active" and "standby" to indicate if the signal is selected from the
> working
> or protection transport entity; i.e. if selector selects from working, the
> working is active and protection is standby, if the selector selects from
> protection the working is standby and the protection is active.
> - "normal" and "extra traffic" signal. The normal signal is protected.
> 
> Regards,
> 
> Maarten
> 
> [email-masked] wrote:
> >
> > Jonathan....review the text below....I think the problem is 1:1.
> >
> > neil
> >
> > > -----Original Message-----
> > > From: Jonathan Lang [mailto:[email-masked]]
> > > Sent: 12 December 2001 17:46
> > > To: 'Ben Mack-Crane'; John Drake
> > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > Subject: RE: Moving right along ... generalized-signaling-06
> > >
> > >
> > > Ben,
> > >   Please see inline.
> > >
> > > Thanks,
> > > Jonathan
> > >
> > > > -----Original Message-----
> > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > Sent: Wednesday, December 12, 2001 8:56 AM
> > > > To: John Drake
> > > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > >
> > > >
> > > > See comment below.
> > > >
> > > > Regards,
> > > > Ben
> > > >
> > > > John Drake wrote:
> > > > >
> > > > > Snipped
> > > > >
> > > > > -----Original Message-----
> > > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > > Sent: Tuesday, December 11, 2001 6:38 AM
> > > > > To: Lou Berger
> > > > > Cc: Kireeti Kompella; [email-masked]
> > > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > > >
> > > > > >
> > > > > > >
> > > > > > >7) In Protection Information it states "The resources
> > > > allocated for a
> > > > > > >    secondary LSP MAY be used by other LSPs until the
> > > > primary LSP fails
> > > > > > >    over to the secondary LSP."  This may not always be
> > > > the case.  An
> > > > > > >    explicit flag indicating whether or not extra
> > > > traffic may use the
> > > > > > >    secondary path resources is needed.
> > > > > >
> > > > > > ??? This is the purpose of this bit.
> > > > >
> > > > > This is not clear from the definition.  The bit is defined
> > > > as indicating
> > > > > the LSP is a secondary (or protecting) LSP and in 1+1
> > > protection the
> > > > > secondary LSP may not be used for extra traffic.
> > > > >
> > > > > Perhaps the problem here is that protection features are
> > > > being defined
> > > > > before the protection framework and requirements are
> > > done.  Is this
> > > > > presupposing some particular outcome of the recovery work in CAMP?
> > > > >
> > > > > JD:  I think the definition of the bit is fine.  For both
> > > > 1+1 and 1:1
> > > > > protection, there would be a pair of Primary LSPs between
> > > the source
> > > > > and destination, rather than a Primary and a Secondary.
> > > >
> > > > This is an unusual use of terms.  I have never encountered a case
> > > > where both the working and recovery paths are call "primary."
> > > >
> > > > This is not consistent with either draft-mpls-recovery-framework
> > > > or with draft-lang-ccamp-recovery.  I think this is a sign that the
> > > > protection work is immature and not ready for progressing to RFC.
> > > >
> > > For 1+1 path protection, both working/recovery paths are
> > > carrying user data
> > > traffic and it is an endpoint decision as to which path is
> > > actually the
> > > working/recovery path.  At a transit node, both paths need to
> > > be treated as
> > > primary, as the resources are currently being used and
> > > obviously can't be
> > > used for Extra Traffic.
> > >

Delivery-date: Thu, 13 Dec 2001 11:33:10 -0800
From: John Drake <[email-masked]>
To: manoj juneja <[email-masked]>, [email-masked],  [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: Lambda LSP establishment
Date: Thu, 13 Dec 2001 11:24:42 -0800

Eric,

I spoke with Maarten about such an I-D some time ago, and we both thought it
would be a great idea.

Thanks,

John

-----Original Message-----
From: manoj juneja [mailto:[email-masked]]
Sent: Thursday, December 13, 2001 10:45 AM
To: [email-masked]; [email-masked]; John Drake;
[email-masked]
Cc: [email-masked]
Subject: RE: Lambda LSP establishment

Hi Eric,
          I fully support ur idea of having an informational draft
explaining different scenarios of SDH/SONET LSP establishment. The
concept of hierarchy is clear in case of SDH/SONET. What about the LSC
or FSC interfaces ?
2-3 days back john responded to my question on lambda hierarchy that a
lambda LSP can be advertised as a FA with different switching type (say
TDM) and then a TDM LSP can be tunneled over a lambda LSP. I am
interested in knowing the list of such scenarios in case of LSC or FSC
LSP advertised as a FA and its different combinations of switching
capabilities as these things are not expalined anywhere.
When a head or tail end of LSP advertises it as a FA then how the
multiplexing capabilities (like can switch VC-4 but not VC-3 etc.) of
the FA are decided ?

Regards,
manoj.

>From: "Mannie, Eric" <[email-masked]>
>To: 'Heiles Juergen ' <[email-masked]>, ''John Drake' '  
><[email-masked]>, 'Maarten Vissers ' <[email-masked]>, 'manoj 
>juneja ' <[email-masked]>
>CC: "[email-masked] '" <[email-masked]>
>Subject: RE: Lambda LSP establishment
>Date: Thu, 13 Dec 2001 18:56:31 +0100
>
>Hi All,
>
>A few comments,
>
> >In MPLS the FA establishes "virtual" layer networks. In GMPLS the layer
>networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, OCh, OMS, OTS). 
>A
>FA basically corresponds to a real trail in a circuit switched network.
>
>Eric: ...and this trail is setup dynamically using GMPLS. That's the
>interest. One can think of SDH/SONET FAs as shortcuts or express-routes.
>
> >One special thing about the SDH label is, that it includes a hierarchy as
>it identifies the lower order VC in a higher order VC in a STM-N signal.
>Note that this is somehow in contradiction with a statement in the GMPLS
>signaling document which says
>
> >"A Generalized Label only carries a single level of label, i.e., it is
>    non-hierarchical.  When multiple levels of label (LSPs within LSPs)
>    are required, each LSP must be established separately, see [MPLS-
>    HIERARCHY]."
>
>No, hierarchy of labels is not hierarchy of layers. And even one should 
>have
>a common definition of what means a "layer". This text says that we cannot
>have multiple embedded labels, e.g. one label containting a label stack.
>This is a signaling stuff that doesn't imply anything on the transport
>plane.
>
>Now, a label identifies ONE LSP at an interface. This LSP can be HO or LO 
>in
>SDH. The label can be fully specified or partially specified, depending on
>the context where the LSP is established.
>
>E.g. when an LSP is established over a FA, the highest part of the LSP 
>label
>is not relevant. When the FA LSP is established the lowest part of the FA
>LSP label is not relevant.
>
>If a low order LSP is established without any higher order FA, the label is
>fully specified. As you said the link is indeed the "ultimate FA" in that
>case. Except that from the routing point of view a link and an FA are two
>different things. There is a routing adjacency "over" a link but not over a
>FA.
>
>The SDH/SONET label just includes what you need to include in each 
>scenario.
>
>Moreover, the label MUST be interpreted according to the type of interface
>for which it is used. It is possible to code two labels having the same
>value but a complete different meaning. Labels are context sensitive of
>course.
>
>For instance, an LSP over an STM-0 interface or over a FA will have the
>highest part set to zero, and could possibly have the same lowest part. You
>cannot understand what means the label without knowning the detail of the
>interface. In that case, the interface is either an STM-0 interface or a
>VC-3 FA. And of course that FA and STM-0 interface are two different 
>things,
>but from the LSP point of view, in both cases what it wants is a VC-3 in
>which it can be multiplexed.
>
>Hope this helps.
>
>I start to wonder if we should have an informational draft describing
>different scenarios of SDH/SONET LSP establishment. That could complement
>the SDH/SONET signaling drafts and the GMPLS architecture. That could solve
>many terminology and modeling issues.
>
>Kind regards,
>
>Eric
>
>-----Original Message-----
>From: Heiles Juergen
>To: 'John Drake'; Maarten Vissers; manoj juneja
>Cc: [email-masked]
>Sent: 12/13/01 11:15 AM
>Subject: RE: Lambda LSP establishment
>
>Let me express my understanding of FAs in MPLS/GMPLS, please correct me
>if I am wrong. I have also some questions related to the label
>generation and interactions between layer networks.
>
>The label in MPLS is local to the link between two adjacent MPLS
>switches, it indicates a LSP in this link. This link is therefore the
>ultimate FA. An already established LSP between two MPLS switches, which
>don't have to be adjacent, can be used to transport/tunnel other LSPs
>between this two nodes. This already established LSP generates a virtual
>adjacency between the two nodes, the FA. As several LSPs can use this FA
>it is also a kind of virtual multiplexing.
>If you compare it with a circuit switched network the FA is a server
>layer trail that provides transport (a link connection) for one or more
>client layer signals.
>In MPLS the FA establishes "virtual" layer networks. In GMPLS the layer
>networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, OCh, OMS,
>OTS). A FA basically corresponds to a real trail in a circuit switched
>network.
>In GMPLS the label is also local to the link between the two devices
>that perform the switching. For example for SDH the VC-N is identified
>by the STM-N link/port and the SUKLM number according to
>draft-ietf-ccamp-gmpls-sonet-sdh-02.txt. The STM-N port is identified by
>the interface ID (I am not sure on this) and SUKLM is the SDH label that
>locates the VC within the STM-N.
>From just the SDH viewpoint the STM-N connection is the ultimate server
>trail/FA. However the STM-N signal could be transported over a Optical
>Channel or G.709 ODU. The OCh or ODU can already start in the equipment
>that performs the VC-N switching. So the STM-N signal is not the port,
>but the WDM signal is the port and the STM-N signal makes use of a OCh
>or ODU server layer trail. This server layer trail can be established
>via management or using GMPLS.
>Can someone explain how a label for a VC-4 is generated in this case
>(pre-established OCh or ODU trail via management or setup using GMPLS).
>This interaction between the different technologies/labels need in my
>view some further explanation.
>
>One special thing about the SDH label is, that it includes a hierarchy
>as it identifies the lower order VC in a higher order VC in a STM-N
>signal. Note that this is somehow in contradiction with a statement in
>the GMPLS signaling document which says
>"A Generalized Label only carries a single level of label, i.e., it is
>    non-hierarchical.  When multiple levels of label (LSPs within LSPs)
>    are required, each LSP must be established separately, see [MPLS-
>    HIERARCHY]."
>Following this statement each layer should have its own label
>independent of server layers.
>The combination of hierarchies in labels is based on technology (e.g.
>SDH, Sonet, G.709 ODU) but has in my view no real technical reason. The
>SDH label for example fits to standard STM-N signals, but not to sub-STM
>signals.
>For the SDH the full SUKLM number is used if a e.g. VC-12 is located in
>relation to a STM-N interface. If it is located in relation to a VC-4
>(the VC-4 is in this case a FA) SUK are set to 0. For me it is not clear
>in which case I use the first and in which case I use the second case as
>a VC-4 trail is always needed for a VC-12 connection. This VC-4 could be
>established using management or GMPLS. However it should have no
>influence on the label.
>Some more information is needed in my view in this area.
>
>
>Juergen
>
>
> > -----Original Message-----
> > From: John Drake [mailto:[email-masked]]
> > Sent: Wednesday, December 12, 2001 6:54 AM
> > To: Maarten Vissers; manoj juneja
> > Cc: [email-masked]
> > Subject: RE: Lambda LSP establishment
> >
> >
> > fortunately, this is just your opinion
> >
> > -----Original Message-----
> > From: Maarten Vissers [mailto:[email-masked]]
> > Sent: Tuesday, December 11, 2001 9:31 PM
> > To: manoj juneja
> > Cc: [email-masked]
> > Subject: Re: Lambda LSP establishment
> >
> >
> > Manoj,
> >
> > Forget the FA stuff, it is not appropriate in circuit
> > networks. It only
> > applies
> > to MPLS. We should remove it when it is used in relation with PDH,
> > SDH/SONET,
> > OTN and pre-OTN. The text in sdh-sonet draft should state
> > that if there is a
> > LOVC link (IETF: link bundle/TE link) then the LOVC signals
> > use a label with
> > "00KLM".
> >
> > Regards,
> >
> > Maarten
> >
> > manoj juneja wrote:
> > >
> > > Hi Marteen,
> > >             The concept of FA is mentioned for SDH/SONET in
> > gmpls-sdh
> > > -sonet draft. It says that if u have a HOVC trail as a FA
> > (advertized
> > > as a link) then u can allocate the lower level signals in
> > it by making
> > > the higher bits of label as 0s (i.e. S and U}. This is fine
> > for the same
> > > technology. What about the case where the TDM LSP has to be tunneled
> > through
> > > the Lambda LSP ? What will be the form of label (i.e.
> > {SUKLM} or lambda
> > > etc.) ?
> > >
> > > Regards,
> > > manoj.
> > >
> > > >From: Maarten Vissers <[email-masked]>
> > > >To: manoj juneja <[email-masked]>
> > > >CC: [email-masked]
> > > >Subject: Re: Lambda LSP establishment
> > > >Date: Tue, 11 Dec 2001 15:56:41 +0100
> > > >
> > > >Manoj,
> > > >
> > > >You refer to one wavelength to be available between A-E without
> > wavelength
> > > >conversion capability. This suggests that you operate at
> > the OCh layer
> > > >network.
> > > >Then you specify the capacity of the 4 OCh link
> > connections (A-B, B-C,
> > C-D,
> > > >D-E)
> > > >to be "C". Say that C is about 10 Gbit/s. You then assume
> > that there is a
> > > >request for an OCh signal with capacity C/4 (e.g. 2.5
> > Gbit/s) between C
> > and
> > > >E.
> > > >The result is that the OCh link connections C-D and D-E
> > are transporting
> > > >the OCh
> > > >signal (of e.g. 2.5G). These OCh link connections are now
> > in service and
> > > >not
> > > >longer available to an other OCh connection request. I.e.
> > a request for
> > an
> > > >OCh
> > > >connection between A and E will be rejected.
> > > >
> > > >FAs are not applicable in the circuit layers. IF there is
> > a trail in
> > server
> > > >layer X, then there is a link in its client layer Y. X and
> > Y are thus
> > > >different
> > > >layer networks and signals.
> > > >
> > > >If C-E is a "FA", then in an OTN the C-E connection would
> > be an OCh trail
> > > >supporting an ODUk (k=1 if OCh is 2G5) link with a single link
> > connection.
> > > >
> > > >Note a FA in MPLS creates essentially a MPLS sublayer
> > network. Such is
> > not
> > > >possible in the SDH/SONET, OTN, PDH or ATM technologies.
> > > >
> > > >Regards,
> > > >
> > > >Maarten
> > > >
> > > >OCh link connections
> > > >
> > > >manoj juneja wrote:
> > > > >
> > > > > Hi All,
> > > > >         If I have 5 nodes A, B, C, D and E connected as
> > shown. Assume
> > > > > that only one wavelength is available on the path A to E (no
> > wavelength
> > > > > conversion capability is there on the complete path).
> > Let the capacity
> > > > > of the wavelength be C. Further assume a request arrives for
> > connection
> > > > > from node C to E for a line capacity of C/4. This
> > request will be
> > > > > successful as we have available wavelength. Now If
> > another request
> > > > > comes at node A to establish another connection from
> > node A to node E
> > > > > via nodes {A,B,C,D,E} for a line capacity of C/4.
> > Should this request
> > > > > be successful as we have already allocated the wavelength ?
> > > > >
> > > > > If the previous connection from C to E of capacity C/4 had been
> > > > > advertised as a FA, in that case will the IInd request succeed ?
> > > > >
> > > > > If the previous connection from C to E of capacity C/4
> > had not been
> > > > > advertised as FA then what will be the fate of IInd connection ?
> > > > >
> > > > >        A <--> B <---> C <----> D <---> <----> E
> > > > >
> > > > > Regards,
> > > > > manoj.
> > > > >
> > > > >
> > _________________________________________________________________
> > > > > Get your FREE download of MSN Explorer at
> > > >http://explorer.msn.com/intl.asp
> > > ><< mvissers.vcf >>
> > >
> > > _________________________________________________________________
> > > Send and receive Hotmail on your mobile device:
>http://mobile.msn.com

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

Delivery-date: Thu, 13 Dec 2001 11:29:57 -0800
From: John Drake <[email-masked]>
To: Heiles Juergen <[email-masked]>, Maarten Vissers <[email-masked]>, manoj juneja <[email-masked]>
Cc: [email-masked]
Subject: RE: Lambda LSP establishment
Date: Thu, 13 Dec 2001 11:24:34 -0800

-----Original Message-----
From: Heiles Juergen [mailto:[email-masked]]
Sent: Thursday, December 13, 2001 2:16 AM
To: John Drake; Maarten Vissers; manoj juneja
Cc: [email-masked]
Subject: RE: Lambda LSP establishment

Let me express my understanding of FAs in MPLS/GMPLS, please correct me if I
am wrong. I have also some questions related to the label generation and
interactions between layer networks.

The label in MPLS is local to the link between two adjacent MPLS switches,
it indicates a LSP in this link. This link is therefore the ultimate FA. An
already established LSP between two MPLS switches, which don't have to be
adjacent, can be used to transport/tunnel other LSPs between this two nodes.
This already established LSP generates a virtual adjacency between the two
nodes, the FA. As several LSPs can use this FA it is also a kind of virtual
multiplexing.

JD:  What people don't seem to realize is that LSP hierarchy and FAs were
developed for GMPLS and not for MPLS.  In the case of a non-PSC FA, the
virtual multiplexing that you mention is real.

If you compare it with a circuit switched network the FA is a server layer
trail that provides transport (a link connection) for one or more client
layer signals.
In MPLS the FA establishes "virtual" layer networks. In GMPLS the layer
networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, OCh, OMS, OTS). A
FA basically corresponds to a real trail in a circuit switched network.

JD:  However, that 'real trail' may be established dynamically as an FA and
its path may include two or more MPLS nodes.  To expand on my example of the
other day, one might establish an FA LSP of type TDM and capacity OC-192
across a lambda core and advertise it as being able to multiplex four
OC-48s.  Up to four OC 48 FA LSPs could then be established using this FA
LSP as a link.  Each of these four OC 48s could then be advertised as FA
LSPs and so on. 

In GMPLS the label is also local to the link between the two devices that
perform the switching. For example for SDH the VC-N is identified by the
STM-N link/port and the SUKLM number according to
draft-ietf-ccamp-gmpls-sonet-sdh-02.txt. The STM-N port is identified by the
interface ID (I am not sure on this) and SUKLM is the SDH label that locates
the VC within the STM-N.
>From just the SDH viewpoint the STM-N connection is the ultimate server
trail/FA. However the STM-N signal could be transported over a Optical
Channel or G.709 ODU. The OCh or ODU can already start in the equipment that
performs the VC-N switching. So the STM-N signal is not the port, but the
WDM signal is the port and the STM-N signal makes use of a OCh or ODU server
layer trail. This server layer trail can be established via management or
using GMPLS. 
Can someone explain how a label for a VC-4 is generated in this case
(pre-established OCh or ODU trail via management or setup using GMPLS). This
interaction between the different technologies/labels need in my view some
further explanation.

JD:  The details of the SONET/SDH hierarchy are, as I've noted previously,
beyond me.  However, the general model is that the head and tail ends of an
FA LSP communicate directly to allocate a label for a given LSP from the
address space of the FA LSP.  If that FA LSP is of type TDM, then the label
will be a SONET/SDH label.

One special thing about the SDH label is, that it includes a hierarchy as it
identifies the lower order VC in a higher order VC in a STM-N signal. Note
that this is somehow in contradiction with a statement in the GMPLS
signaling document which says 
"A Generalized Label only carries a single level of label, i.e., it is
   non-hierarchical.  When multiple levels of label (LSPs within LSPs)
   are required, each LSP must be established separately, see [MPLS-
   HIERARCHY]."
Following this statement each layer should have its own label independent of
server layers.
The combination of hierarchies in labels is based on technology (e.g. SDH,
Sonet, G.709 ODU) but has in my view no real technical reason. The SDH label
for example fits to standard STM-N signals, but not to sub-STM signals.
For the SDH the full SUKLM number is used if a e.g. VC-12 is located in
relation to a STM-N interface. If it is located in relation to a VC-4 (the
VC-4 is in this case a FA) SUK are set to 0. For me it is not clear in which
case I use the first and in which case I use the second case as a VC-4 trail
is always needed for a VC-12 connection. This VC-4 could be established
using management or GMPLS. However it should have no influence on the label.

Some more information is needed in my view in this area.

JD:  You're probably right.

Juergen

> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: Wednesday, December 12, 2001 6:54 AM
> To: Maarten Vissers; manoj juneja
> Cc: [email-masked]
> Subject: RE: Lambda LSP establishment
> 
> 
> fortunately, this is just your opinion
> 
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Tuesday, December 11, 2001 9:31 PM
> To: manoj juneja
> Cc: [email-masked]
> Subject: Re: Lambda LSP establishment
> 
> 
> Manoj,
> 
> Forget the FA stuff, it is not appropriate in circuit 
> networks. It only
> applies
> to MPLS. We should remove it when it is used in relation with PDH,
> SDH/SONET,
> OTN and pre-OTN. The text in sdh-sonet draft should state 
> that if there is a
> LOVC link (IETF: link bundle/TE link) then the LOVC signals 
> use a label with
> "00KLM".
> 
> Regards,
> 
> Maarten
> 
> manoj juneja wrote:
> > 
> > Hi Marteen,
> >             The concept of FA is mentioned for SDH/SONET in 
> gmpls-sdh
> > -sonet draft. It says that if u have a HOVC trail as a FA 
> (advertized
> > as a link) then u can allocate the lower level signals in 
> it by making
> > the higher bits of label as 0s (i.e. S and U}. This is fine 
> for the same
> > technology. What about the case where the TDM LSP has to be tunneled
> through
> > the Lambda LSP ? What will be the form of label (i.e. 
> {SUKLM} or lambda
> > etc.) ?
> > 
> > Regards,
> > manoj.
> > 
> > >From: Maarten Vissers <[email-masked]>
> > >To: manoj juneja <[email-masked]>
> > >CC: [email-masked]
> > >Subject: Re: Lambda LSP establishment
> > >Date: Tue, 11 Dec 2001 15:56:41 +0100
> > >
> > >Manoj,
> > >
> > >You refer to one wavelength to be available between A-E without
> wavelength
> > >conversion capability. This suggests that you operate at 
> the OCh layer
> > >network.
> > >Then you specify the capacity of the 4 OCh link 
> connections (A-B, B-C,
> C-D,
> > >D-E)
> > >to be "C". Say that C is about 10 Gbit/s. You then assume 
> that there is a
> > >request for an OCh signal with capacity C/4 (e.g. 2.5 
> Gbit/s) between C
> and
> > >E.
> > >The result is that the OCh link connections C-D and D-E 
> are transporting
> > >the OCh
> > >signal (of e.g. 2.5G). These OCh link connections are now 
> in service and
> > >not
> > >longer available to an other OCh connection request. I.e. 
> a request for
> an
> > >OCh
> > >connection between A and E will be rejected.
> > >
> > >FAs are not applicable in the circuit layers. IF there is 
> a trail in
> server
> > >layer X, then there is a link in its client layer Y. X and 
> Y are thus
> > >different
> > >layer networks and signals.
> > >
> > >If C-E is a "FA", then in an OTN the C-E connection would 
> be an OCh trail
> > >supporting an ODUk (k=1 if OCh is 2G5) link with a single link
> connection.
> > >
> > >Note a FA in MPLS creates essentially a MPLS sublayer 
> network. Such is
> not
> > >possible in the SDH/SONET, OTN, PDH or ATM technologies.
> > >
> > >Regards,
> > >
> > >Maarten
> > >
> > >OCh link connections
> > >
> > >manoj juneja wrote:
> > > >
> > > > Hi All,
> > > >         If I have 5 nodes A, B, C, D and E connected as 
> shown. Assume
> > > > that only one wavelength is available on the path A to E (no
> wavelength
> > > > conversion capability is there on the complete path). 
> Let the capacity
> > > > of the wavelength be C. Further assume a request arrives for
> connection
> > > > from node C to E for a line capacity of C/4. This 
> request will be
> > > > successful as we have available wavelength. Now If 
> another request
> > > > comes at node A to establish another connection from 
> node A to node E
> > > > via nodes {A,B,C,D,E} for a line capacity of C/4. 
> Should this request
> > > > be successful as we have already allocated the wavelength ?
> > > >
> > > > If the previous connection from C to E of capacity C/4 had been
> > > > advertised as a FA, in that case will the IInd request succeed ?
> > > >
> > > > If the previous connection from C to E of capacity C/4 
> had not been
> > > > advertised as FA then what will be the fate of IInd connection ?
> > > >
> > > >        A <--> B <---> C <----> D <---> <----> E
> > > >
> > > > Regards,
> > > > manoj.
> > > >
> > > > 
> _________________________________________________________________
> > > > Get your FREE download of MSN Explorer at
> > >http://explorer.msn.com/intl.asp
> > ><< mvissers.vcf >>
> > 
> > _________________________________________________________________
> > Send and receive Hotmail on your mobile device: 
http://mobile.msn.com

Delivery-date: Thu, 13 Dec 2001 10:49:09 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: Lambda LSP establishment
Date: Thu, 13 Dec 2001 11:45:09 -0700

Hi Eric,
          I fully support ur idea of having an informational draft
explaining different scenarios of SDH/SONET LSP establishment. The
concept of hierarchy is clear in case of SDH/SONET. What about the LSC
or FSC interfaces ?
2-3 days back john responded to my question on lambda hierarchy that a
lambda LSP can be advertised as a FA with different switching type (say
TDM) and then a TDM LSP can be tunneled over a lambda LSP. I am
interested in knowing the list of such scenarios in case of LSC or FSC
LSP advertised as a FA and its different combinations of switching
capabilities as these things are not expalined anywhere.
When a head or tail end of LSP advertises it as a FA then how the
multiplexing capabilities (like can switch VC-4 but not VC-3 etc.) of
the FA are decided ?

Regards,
manoj.

>From: "Mannie, Eric" <[email-masked]>
>To: 'Heiles Juergen ' <[email-masked]>, ''John Drake' '  
><[email-masked]>, 'Maarten Vissers ' <[email-masked]>, 'manoj 
>juneja ' <[email-masked]>
>CC: "[email-masked] '" <[email-masked]>
>Subject: RE: Lambda LSP establishment
>Date: Thu, 13 Dec 2001 18:56:31 +0100
>
>Hi All,
>
>A few comments,
>
> >In MPLS the FA establishes "virtual" layer networks. In GMPLS the layer
>networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, OCh, OMS, OTS). 
>A
>FA basically corresponds to a real trail in a circuit switched network.
>
>Eric: ...and this trail is setup dynamically using GMPLS. That's the
>interest. One can think of SDH/SONET FAs as shortcuts or express-routes.
>
> >One special thing about the SDH label is, that it includes a hierarchy as
>it identifies the lower order VC in a higher order VC in a STM-N signal.
>Note that this is somehow in contradiction with a statement in the GMPLS
>signaling document which says
>
> >"A Generalized Label only carries a single level of label, i.e., it is
>    non-hierarchical.  When multiple levels of label (LSPs within LSPs)
>    are required, each LSP must be established separately, see [MPLS-
>    HIERARCHY]."
>
>No, hierarchy of labels is not hierarchy of layers. And even one should 
>have
>a common definition of what means a "layer". This text says that we cannot
>have multiple embedded labels, e.g. one label containting a label stack.
>This is a signaling stuff that doesn't imply anything on the transport
>plane.
>
>Now, a label identifies ONE LSP at an interface. This LSP can be HO or LO 
>in
>SDH. The label can be fully specified or partially specified, depending on
>the context where the LSP is established.
>
>E.g. when an LSP is established over a FA, the highest part of the LSP 
>label
>is not relevant. When the FA LSP is established the lowest part of the FA
>LSP label is not relevant.
>
>If a low order LSP is established without any higher order FA, the label is
>fully specified. As you said the link is indeed the "ultimate FA" in that
>case. Except that from the routing point of view a link and an FA are two
>different things. There is a routing adjacency "over" a link but not over a
>FA.
>
>The SDH/SONET label just includes what you need to include in each 
>scenario.
>
>Moreover, the label MUST be interpreted according to the type of interface
>for which it is used. It is possible to code two labels having the same
>value but a complete different meaning. Labels are context sensitive of
>course.
>
>For instance, an LSP over an STM-0 interface or over a FA will have the
>highest part set to zero, and could possibly have the same lowest part. You
>cannot understand what means the label without knowning the detail of the
>interface. In that case, the interface is either an STM-0 interface or a
>VC-3 FA. And of course that FA and STM-0 interface are two different 
>things,
>but from the LSP point of view, in both cases what it wants is a VC-3 in
>which it can be multiplexed.
>
>Hope this helps.
>
>I start to wonder if we should have an informational draft describing
>different scenarios of SDH/SONET LSP establishment. That could complement
>the SDH/SONET signaling drafts and the GMPLS architecture. That could solve
>many terminology and modeling issues.
>
>Kind regards,
>
>Eric
>
>-----Original Message-----
>From: Heiles Juergen
>To: 'John Drake'; Maarten Vissers; manoj juneja
>Cc: [email-masked]
>Sent: 12/13/01 11:15 AM
>Subject: RE: Lambda LSP establishment
>
>Let me express my understanding of FAs in MPLS/GMPLS, please correct me
>if I am wrong. I have also some questions related to the label
>generation and interactions between layer networks.
>
>The label in MPLS is local to the link between two adjacent MPLS
>switches, it indicates a LSP in this link. This link is therefore the
>ultimate FA. An already established LSP between two MPLS switches, which
>don't have to be adjacent, can be used to transport/tunnel other LSPs
>between this two nodes. This already established LSP generates a virtual
>adjacency between the two nodes, the FA. As several LSPs can use this FA
>it is also a kind of virtual multiplexing.
>If you compare it with a circuit switched network the FA is a server
>layer trail that provides transport (a link connection) for one or more
>client layer signals.
>In MPLS the FA establishes "virtual" layer networks. In GMPLS the layer
>networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, OCh, OMS,
>OTS). A FA basically corresponds to a real trail in a circuit switched
>network.
>In GMPLS the label is also local to the link between the two devices
>that perform the switching. For example for SDH the VC-N is identified
>by the STM-N link/port and the SUKLM number according to
>draft-ietf-ccamp-gmpls-sonet-sdh-02.txt. The STM-N port is identified by
>the interface ID (I am not sure on this) and SUKLM is the SDH label that
>locates the VC within the STM-N.
>From just the SDH viewpoint the STM-N connection is the ultimate server
>trail/FA. However the STM-N signal could be transported over a Optical
>Channel or G.709 ODU. The OCh or ODU can already start in the equipment
>that performs the VC-N switching. So the STM-N signal is not the port,
>but the WDM signal is the port and the STM-N signal makes use of a OCh
>or ODU server layer trail. This server layer trail can be established
>via management or using GMPLS.
>Can someone explain how a label for a VC-4 is generated in this case
>(pre-established OCh or ODU trail via management or setup using GMPLS).
>This interaction between the different technologies/labels need in my
>view some further explanation.
>
>One special thing about the SDH label is, that it includes a hierarchy
>as it identifies the lower order VC in a higher order VC in a STM-N
>signal. Note that this is somehow in contradiction with a statement in
>the GMPLS signaling document which says
>"A Generalized Label only carries a single level of label, i.e., it is
>    non-hierarchical.  When multiple levels of label (LSPs within LSPs)
>    are required, each LSP must be established separately, see [MPLS-
>    HIERARCHY]."
>Following this statement each layer should have its own label
>independent of server layers.
>The combination of hierarchies in labels is based on technology (e.g.
>SDH, Sonet, G.709 ODU) but has in my view no real technical reason. The
>SDH label for example fits to standard STM-N signals, but not to sub-STM
>signals.
>For the SDH the full SUKLM number is used if a e.g. VC-12 is located in
>relation to a STM-N interface. If it is located in relation to a VC-4
>(the VC-4 is in this case a FA) SUK are set to 0. For me it is not clear
>in which case I use the first and in which case I use the second case as
>a VC-4 trail is always needed for a VC-12 connection. This VC-4 could be
>established using management or GMPLS. However it should have no
>influence on the label.
>Some more information is needed in my view in this area.
>
>
>Juergen
>
>
> > -----Original Message-----
> > From: John Drake [mailto:[email-masked]]
> > Sent: Wednesday, December 12, 2001 6:54 AM
> > To: Maarten Vissers; manoj juneja
> > Cc: [email-masked]
> > Subject: RE: Lambda LSP establishment
> >
> >
> > fortunately, this is just your opinion
> >
> > -----Original Message-----
> > From: Maarten Vissers [mailto:[email-masked]]
> > Sent: Tuesday, December 11, 2001 9:31 PM
> > To: manoj juneja
> > Cc: [email-masked]
> > Subject: Re: Lambda LSP establishment
> >
> >
> > Manoj,
> >
> > Forget the FA stuff, it is not appropriate in circuit
> > networks. It only
> > applies
> > to MPLS. We should remove it when it is used in relation with PDH,
> > SDH/SONET,
> > OTN and pre-OTN. The text in sdh-sonet draft should state
> > that if there is a
> > LOVC link (IETF: link bundle/TE link) then the LOVC signals
> > use a label with
> > "00KLM".
> >
> > Regards,
> >
> > Maarten
> >
> > manoj juneja wrote:
> > >
> > > Hi Marteen,
> > >             The concept of FA is mentioned for SDH/SONET in
> > gmpls-sdh
> > > -sonet draft. It says that if u have a HOVC trail as a FA
> > (advertized
> > > as a link) then u can allocate the lower level signals in
> > it by making
> > > the higher bits of label as 0s (i.e. S and U}. This is fine
> > for the same
> > > technology. What about the case where the TDM LSP has to be tunneled
> > through
> > > the Lambda LSP ? What will be the form of label (i.e.
> > {SUKLM} or lambda
> > > etc.) ?
> > >
> > > Regards,
> > > manoj.
> > >
> > > >From: Maarten Vissers <[email-masked]>
> > > >To: manoj juneja <[email-masked]>
> > > >CC: [email-masked]
> > > >Subject: Re: Lambda LSP establishment
> > > >Date: Tue, 11 Dec 2001 15:56:41 +0100
> > > >
> > > >Manoj,
> > > >
> > > >You refer to one wavelength to be available between A-E without
> > wavelength
> > > >conversion capability. This suggests that you operate at
> > the OCh layer
> > > >network.
> > > >Then you specify the capacity of the 4 OCh link
> > connections (A-B, B-C,
> > C-D,
> > > >D-E)
> > > >to be "C". Say that C is about 10 Gbit/s. You then assume
> > that there is a
> > > >request for an OCh signal with capacity C/4 (e.g. 2.5
> > Gbit/s) between C
> > and
> > > >E.
> > > >The result is that the OCh link connections C-D and D-E
> > are transporting
> > > >the OCh
> > > >signal (of e.g. 2.5G). These OCh link connections are now
> > in service and
> > > >not
> > > >longer available to an other OCh connection request. I.e.
> > a request for
> > an
> > > >OCh
> > > >connection between A and E will be rejected.
> > > >
> > > >FAs are not applicable in the circuit layers. IF there is
> > a trail in
> > server
> > > >layer X, then there is a link in its client layer Y. X and
> > Y are thus
> > > >different
> > > >layer networks and signals.
> > > >
> > > >If C-E is a "FA", then in an OTN the C-E connection would
> > be an OCh trail
> > > >supporting an ODUk (k=1 if OCh is 2G5) link with a single link
> > connection.
> > > >
> > > >Note a FA in MPLS creates essentially a MPLS sublayer
> > network. Such is
> > not
> > > >possible in the SDH/SONET, OTN, PDH or ATM technologies.
> > > >
> > > >Regards,
> > > >
> > > >Maarten
> > > >
> > > >OCh link connections
> > > >
> > > >manoj juneja wrote:
> > > > >
> > > > > Hi All,
> > > > >         If I have 5 nodes A, B, C, D and E connected as
> > shown. Assume
> > > > > that only one wavelength is available on the path A to E (no
> > wavelength
> > > > > conversion capability is there on the complete path).
> > Let the capacity
> > > > > of the wavelength be C. Further assume a request arrives for
> > connection
> > > > > from node C to E for a line capacity of C/4. This
> > request will be
> > > > > successful as we have available wavelength. Now If
> > another request
> > > > > comes at node A to establish another connection from
> > node A to node E
> > > > > via nodes {A,B,C,D,E} for a line capacity of C/4.
> > Should this request
> > > > > be successful as we have already allocated the wavelength ?
> > > > >
> > > > > If the previous connection from C to E of capacity C/4 had been
> > > > > advertised as a FA, in that case will the IInd request succeed ?
> > > > >
> > > > > If the previous connection from C to E of capacity C/4
> > had not been
> > > > > advertised as FA then what will be the fate of IInd connection ?
> > > > >
> > > > >        A <--> B <---> C <----> D <---> <----> E
> > > > >
> > > > > Regards,
> > > > > manoj.
> > > > >
> > > > >
> > _________________________________________________________________
> > > > > Get your FREE download of MSN Explorer at
> > > >http://explorer.msn.com/intl.asp
> > > ><< mvissers.vcf >>
> > >
> > > _________________________________________________________________
> > > Send and receive Hotmail on your mobile device:
>http://mobile.msn.com

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

Delivery-date: Thu, 13 Dec 2001 10:00:32 -0800
From: "Mannie, Eric" <[email-masked]>
To: 'Heiles Juergen ' <[email-masked]>, ''John Drake' ' <[email-masked]>, 'Maarten Vissers ' <[email-masked]>,  'manoj juneja ' <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>
Subject: RE: Lambda LSP establishment
Date: Thu, 13 Dec 2001 18:56:31 +0100

Hi All,

A few comments,

>In MPLS the FA establishes "virtual" layer networks. In GMPLS the layer
networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, OCh, OMS, OTS). A
FA basically corresponds to a real trail in a circuit switched network.

Eric: ...and this trail is setup dynamically using GMPLS. That's the
interest. One can think of SDH/SONET FAs as shortcuts or express-routes.

>One special thing about the SDH label is, that it includes a hierarchy as
it identifies the lower order VC in a higher order VC in a STM-N signal.
Note that this is somehow in contradiction with a statement in the GMPLS
signaling document which says 

>"A Generalized Label only carries a single level of label, i.e., it is 
   non-hierarchical.  When multiple levels of label (LSPs within LSPs) 
   are required, each LSP must be established separately, see [MPLS- 
   HIERARCHY]." 

No, hierarchy of labels is not hierarchy of layers. And even one should have
a common definition of what means a "layer". This text says that we cannot
have multiple embedded labels, e.g. one label containting a label stack.
This is a signaling stuff that doesn't imply anything on the transport
plane.

Now, a label identifies ONE LSP at an interface. This LSP can be HO or LO in
SDH. The label can be fully specified or partially specified, depending on
the context where the LSP is established.

E.g. when an LSP is established over a FA, the highest part of the LSP label
is not relevant. When the FA LSP is established the lowest part of the FA
LSP label is not relevant.

If a low order LSP is established without any higher order FA, the label is
fully specified. As you said the link is indeed the "ultimate FA" in that
case. Except that from the routing point of view a link and an FA are two
different things. There is a routing adjacency "over" a link but not over a
FA.

The SDH/SONET label just includes what you need to include in each scenario.

Moreover, the label MUST be interpreted according to the type of interface
for which it is used. It is possible to code two labels having the same
value but a complete different meaning. Labels are context sensitive of
course.

For instance, an LSP over an STM-0 interface or over a FA will have the
highest part set to zero, and could possibly have the same lowest part. You
cannot understand what means the label without knowning the detail of the
interface. In that case, the interface is either an STM-0 interface or a
VC-3 FA. And of course that FA and STM-0 interface are two different things,
but from the LSP point of view, in both cases what it wants is a VC-3 in
which it can be multiplexed.

Hope this helps.

I start to wonder if we should have an informational draft describing
different scenarios of SDH/SONET LSP establishment. That could complement
the SDH/SONET signaling drafts and the GMPLS architecture. That could solve
many terminology and modeling issues.

Kind regards,

Eric

-----Original Message-----
From: Heiles Juergen
To: 'John Drake'; Maarten Vissers; manoj juneja
Cc: [email-masked]
Sent: 12/13/01 11:15 AM
Subject: RE: Lambda LSP establishment

Let me express my understanding of FAs in MPLS/GMPLS, please correct me
if I am wrong. I have also some questions related to the label
generation and interactions between layer networks.

The label in MPLS is local to the link between two adjacent MPLS
switches, it indicates a LSP in this link. This link is therefore the
ultimate FA. An already established LSP between two MPLS switches, which
don't have to be adjacent, can be used to transport/tunnel other LSPs
between this two nodes. This already established LSP generates a virtual
adjacency between the two nodes, the FA. As several LSPs can use this FA
it is also a kind of virtual multiplexing.
If you compare it with a circuit switched network the FA is a server
layer trail that provides transport (a link connection) for one or more
client layer signals.
In MPLS the FA establishes "virtual" layer networks. In GMPLS the layer
networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, OCh, OMS,
OTS). A FA basically corresponds to a real trail in a circuit switched
network.
In GMPLS the label is also local to the link between the two devices
that perform the switching. For example for SDH the VC-N is identified
by the STM-N link/port and the SUKLM number according to
draft-ietf-ccamp-gmpls-sonet-sdh-02.txt. The STM-N port is identified by
the interface ID (I am not sure on this) and SUKLM is the SDH label that
locates the VC within the STM-N.
>From just the SDH viewpoint the STM-N connection is the ultimate server
trail/FA. However the STM-N signal could be transported over a Optical
Channel or G.709 ODU. The OCh or ODU can already start in the equipment
that performs the VC-N switching. So the STM-N signal is not the port,
but the WDM signal is the port and the STM-N signal makes use of a OCh
or ODU server layer trail. This server layer trail can be established
via management or using GMPLS. 
Can someone explain how a label for a VC-4 is generated in this case
(pre-established OCh or ODU trail via management or setup using GMPLS).
This interaction between the different technologies/labels need in my
view some further explanation.

One special thing about the SDH label is, that it includes a hierarchy
as it identifies the lower order VC in a higher order VC in a STM-N
signal. Note that this is somehow in contradiction with a statement in
the GMPLS signaling document which says 
"A Generalized Label only carries a single level of label, i.e., it is
   non-hierarchical.  When multiple levels of label (LSPs within LSPs)
   are required, each LSP must be established separately, see [MPLS-
   HIERARCHY]."
Following this statement each layer should have its own label
independent of server layers.
The combination of hierarchies in labels is based on technology (e.g.
SDH, Sonet, G.709 ODU) but has in my view no real technical reason. The
SDH label for example fits to standard STM-N signals, but not to sub-STM
signals.
For the SDH the full SUKLM number is used if a e.g. VC-12 is located in
relation to a STM-N interface. If it is located in relation to a VC-4
(the VC-4 is in this case a FA) SUK are set to 0. For me it is not clear
in which case I use the first and in which case I use the second case as
a VC-4 trail is always needed for a VC-12 connection. This VC-4 could be
established using management or GMPLS. However it should have no
influence on the label. 
Some more information is needed in my view in this area.

Juergen

> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: Wednesday, December 12, 2001 6:54 AM
> To: Maarten Vissers; manoj juneja
> Cc: [email-masked]
> Subject: RE: Lambda LSP establishment
> 
> 
> fortunately, this is just your opinion
> 
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Tuesday, December 11, 2001 9:31 PM
> To: manoj juneja
> Cc: [email-masked]
> Subject: Re: Lambda LSP establishment
> 
> 
> Manoj,
> 
> Forget the FA stuff, it is not appropriate in circuit 
> networks. It only
> applies
> to MPLS. We should remove it when it is used in relation with PDH,
> SDH/SONET,
> OTN and pre-OTN. The text in sdh-sonet draft should state 
> that if there is a
> LOVC link (IETF: link bundle/TE link) then the LOVC signals 
> use a label with
> "00KLM".
> 
> Regards,
> 
> Maarten
> 
> manoj juneja wrote:
> > 
> > Hi Marteen,
> >             The concept of FA is mentioned for SDH/SONET in 
> gmpls-sdh
> > -sonet draft. It says that if u have a HOVC trail as a FA 
> (advertized
> > as a link) then u can allocate the lower level signals in 
> it by making
> > the higher bits of label as 0s (i.e. S and U}. This is fine 
> for the same
> > technology. What about the case where the TDM LSP has to be tunneled
> through
> > the Lambda LSP ? What will be the form of label (i.e. 
> {SUKLM} or lambda
> > etc.) ?
> > 
> > Regards,
> > manoj.
> > 
> > >From: Maarten Vissers <[email-masked]>
> > >To: manoj juneja <[email-masked]>
> > >CC: [email-masked]
> > >Subject: Re: Lambda LSP establishment
> > >Date: Tue, 11 Dec 2001 15:56:41 +0100
> > >
> > >Manoj,
> > >
> > >You refer to one wavelength to be available between A-E without
> wavelength
> > >conversion capability. This suggests that you operate at 
> the OCh layer
> > >network.
> > >Then you specify the capacity of the 4 OCh link 
> connections (A-B, B-C,
> C-D,
> > >D-E)
> > >to be "C". Say that C is about 10 Gbit/s. You then assume 
> that there is a
> > >request for an OCh signal with capacity C/4 (e.g. 2.5 
> Gbit/s) between C
> and
> > >E.
> > >The result is that the OCh link connections C-D and D-E 
> are transporting
> > >the OCh
> > >signal (of e.g. 2.5G). These OCh link connections are now 
> in service and
> > >not
> > >longer available to an other OCh connection request. I.e. 
> a request for
> an
> > >OCh
> > >connection between A and E will be rejected.
> > >
> > >FAs are not applicable in the circuit layers. IF there is 
> a trail in
> server
> > >layer X, then there is a link in its client layer Y. X and 
> Y are thus
> > >different
> > >layer networks and signals.
> > >
> > >If C-E is a "FA", then in an OTN the C-E connection would 
> be an OCh trail
> > >supporting an ODUk (k=1 if OCh is 2G5) link with a single link
> connection.
> > >
> > >Note a FA in MPLS creates essentially a MPLS sublayer 
> network. Such is
> not
> > >possible in the SDH/SONET, OTN, PDH or ATM technologies.
> > >
> > >Regards,
> > >
> > >Maarten
> > >
> > >OCh link connections
> > >
> > >manoj juneja wrote:
> > > >
> > > > Hi All,
> > > >         If I have 5 nodes A, B, C, D and E connected as 
> shown. Assume
> > > > that only one wavelength is available on the path A to E (no
> wavelength
> > > > conversion capability is there on the complete path). 
> Let the capacity
> > > > of the wavelength be C. Further assume a request arrives for
> connection
> > > > from node C to E for a line capacity of C/4. This 
> request will be
> > > > successful as we have available wavelength. Now If 
> another request
> > > > comes at node A to establish another connection from 
> node A to node E
> > > > via nodes {A,B,C,D,E} for a line capacity of C/4. 
> Should this request
> > > > be successful as we have already allocated the wavelength ?
> > > >
> > > > If the previous connection from C to E of capacity C/4 had been
> > > > advertised as a FA, in that case will the IInd request succeed ?
> > > >
> > > > If the previous connection from C to E of capacity C/4 
> had not been
> > > > advertised as FA then what will be the fate of IInd connection ?
> > > >
> > > >        A <--> B <---> C <----> D <---> <----> E
> > > >
> > > > Regards,
> > > > manoj.
> > > >
> > > > 
> _________________________________________________________________
> > > > Get your FREE download of MSN Explorer at
> > >http://explorer.msn.com/intl.asp
> > ><< mvissers.vcf >>
> > 
> > _________________________________________________________________
> > Send and receive Hotmail on your mobile device: 
http://mobile.msn.com

Delivery-date: Thu, 13 Dec 2001 08:12:47 -0800
From: John Drake <[email-masked]>
To: Maarten Vissers <[email-masked]>, [email-masked]
Subject: RE: Moving right along ... generalized-signaling-06
Date: Thu, 13 Dec 2001 08:08:41 -0800

Maarten,

That's fine, however it's beside the point.  The semantics of
Primary/Secondary refer to the control plane and whether the node
establishing a given LSP is planning to use it at the time it's established
or at a later time.  As I indicated in an earlier note, 1+1 transport plane
protection would be accomplished in the control plane by establishing two
LSPs of type Primary.  The control plane really doesn't care which LSP the
transport plane is using as Working and which as Protect, although that
information is available to the control plane at the LSP endpoints.

Thanks,

John  

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Thursday, December 13, 2001 12:15 AM
To: [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

There exist well defined protection terminology in ITU-T for the transport
plane. "Working" and "Protection" are being used and not primary/secondary.
E.g.
a 1+1 architecture has one working connection, one protection connection and
a
permanent bridge.

Besides working/protection indication for the transport entity, there is 
- "active" and "standby" to indicate if the signal is selected from the
working
or protection transport entity; i.e. if selector selects from working, the
working is active and protection is standby, if the selector selects from
protection the working is standby and the protection is active.
- "normal" and "extra traffic" signal. The normal signal is protected.

Regards,

Maarten

[email-masked] wrote:
> 
> Jonathan....review the text below....I think the problem is 1:1.
> 
> neil
> 
> > -----Original Message-----
> > From: Jonathan Lang [mailto:[email-masked]]
> > Sent: 12 December 2001 17:46
> > To: 'Ben Mack-Crane'; John Drake
> > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > Subject: RE: Moving right along ... generalized-signaling-06
> >
> >
> > Ben,
> >   Please see inline.
> >
> > Thanks,
> > Jonathan
> >
> > > -----Original Message-----
> > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > Sent: Wednesday, December 12, 2001 8:56 AM
> > > To: John Drake
> > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > Subject: Re: Moving right along ... generalized-signaling-06
> > >
> > >
> > > See comment below.
> > >
> > > Regards,
> > > Ben
> > >
> > > John Drake wrote:
> > > >
> > > > Snipped
> > > >
> > > > -----Original Message-----
> > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > Sent: Tuesday, December 11, 2001 6:38 AM
> > > > To: Lou Berger
> > > > Cc: Kireeti Kompella; [email-masked]
> > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > >
> > > > >
> > > > > >
> > > > > >7) In Protection Information it states "The resources
> > > allocated for a
> > > > > >    secondary LSP MAY be used by other LSPs until the
> > > primary LSP fails
> > > > > >    over to the secondary LSP."  This may not always be
> > > the case.  An
> > > > > >    explicit flag indicating whether or not extra
> > > traffic may use the
> > > > > >    secondary path resources is needed.
> > > > >
> > > > > ??? This is the purpose of this bit.
> > > >
> > > > This is not clear from the definition.  The bit is defined
> > > as indicating
> > > > the LSP is a secondary (or protecting) LSP and in 1+1
> > protection the
> > > > secondary LSP may not be used for extra traffic.
> > > >
> > > > Perhaps the problem here is that protection features are
> > > being defined
> > > > before the protection framework and requirements are
> > done.  Is this
> > > > presupposing some particular outcome of the recovery work in CAMP?
> > > >
> > > > JD:  I think the definition of the bit is fine.  For both
> > > 1+1 and 1:1
> > > > protection, there would be a pair of Primary LSPs between
> > the source
> > > > and destination, rather than a Primary and a Secondary.
> > >
> > > This is an unusual use of terms.  I have never encountered a case
> > > where both the working and recovery paths are call "primary."
> > >
> > > This is not consistent with either draft-mpls-recovery-framework
> > > or with draft-lang-ccamp-recovery.  I think this is a sign that the
> > > protection work is immature and not ready for progressing to RFC.
> > >
> > For 1+1 path protection, both working/recovery paths are
> > carrying user data
> > traffic and it is an endpoint decision as to which path is
> > actually the
> > working/recovery path.  At a transit node, both paths need to
> > be treated as
> > primary, as the resources are currently being used and
> > obviously can't be
> > used for Extra Traffic.
> >

Delivery-date: Thu, 13 Dec 2001 02:17:46 -0800
From: Heiles Juergen <[email-masked]>
To: "'John Drake'" <[email-masked]>, Maarten Vissers <[email-masked]>, manoj juneja <[email-masked]>
Cc: [email-masked]
Subject: RE: Lambda LSP establishment
Date: Thu, 13 Dec 2001 11:15:30 +0100

Let me express my understanding of FAs in MPLS/GMPLS, please correct me if I am wrong. I have also some questions related to the label generation and interactions between layer networks.

The label in MPLS is local to the link between two adjacent MPLS switches, it indicates a LSP in this link. This link is therefore the ultimate FA. An already established LSP between two MPLS switches, which don't have to be adjacent, can be used to transport/tunnel other LSPs between this two nodes. This already established LSP generates a virtual adjacency between the two nodes, the FA. As several LSPs can use this FA it is also a kind of virtual multiplexing.
If you compare it with a circuit switched network the FA is a server layer trail that provides transport (a link connection) for one or more client layer signals.
In MPLS the FA establishes "virtual" layer networks. In GMPLS the layer networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, OCh, OMS, OTS). A FA basically corresponds to a real trail in a circuit switched network.
In GMPLS the label is also local to the link between the two devices that perform the switching. For example for SDH the VC-N is identified by the STM-N link/port and the SUKLM number according to draft-ietf-ccamp-gmpls-sonet-sdh-02.txt. The STM-N port is identified by the interface ID (I am not sure on this) and SUKLM is the SDH label that locates the VC within the STM-N.
>From just the SDH viewpoint the STM-N connection is the ultimate server trail/FA. However the STM-N signal could be transported over a Optical Channel or G.709 ODU. The OCh or ODU can already start in the equipment that performs the VC-N switching. So the STM-N signal is not the port, but the WDM signal is the port and the STM-N signal makes use of a OCh or ODU server layer trail. This server layer trail can be established via management or using GMPLS. 
Can someone explain how a label for a VC-4 is generated in this case (pre-established OCh or ODU trail via management or setup using GMPLS). This interaction between the different technologies/labels need in my view some further explanation.

One special thing about the SDH label is, that it includes a hierarchy as it identifies the lower order VC in a higher order VC in a STM-N signal. Note that this is somehow in contradiction with a statement in the GMPLS signaling document which says 
"A Generalized Label only carries a single level of label, i.e., it is
   non-hierarchical.  When multiple levels of label (LSPs within LSPs)
   are required, each LSP must be established separately, see [MPLS-
   HIERARCHY]."
Following this statement each layer should have its own label independent of server layers.
The combination of hierarchies in labels is based on technology (e.g. SDH, Sonet, G.709 ODU) but has in my view no real technical reason. The SDH label for example fits to standard STM-N signals, but not to sub-STM signals.
For the SDH the full SUKLM number is used if a e.g. VC-12 is located in relation to a STM-N interface. If it is located in relation to a VC-4 (the VC-4 is in this case a FA) SUK are set to 0. For me it is not clear in which case I use the first and in which case I use the second case as a VC-4 trail is always needed for a VC-12 connection. This VC-4 could be established using management or GMPLS. However it should have no influence on the label. 
Some more information is needed in my view in this area.

Juergen

> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: Wednesday, December 12, 2001 6:54 AM
> To: Maarten Vissers; manoj juneja
> Cc: [email-masked]
> Subject: RE: Lambda LSP establishment
> 
> 
> fortunately, this is just your opinion
> 
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Tuesday, December 11, 2001 9:31 PM
> To: manoj juneja
> Cc: [email-masked]
> Subject: Re: Lambda LSP establishment
> 
> 
> Manoj,
> 
> Forget the FA stuff, it is not appropriate in circuit 
> networks. It only
> applies
> to MPLS. We should remove it when it is used in relation with PDH,
> SDH/SONET,
> OTN and pre-OTN. The text in sdh-sonet draft should state 
> that if there is a
> LOVC link (IETF: link bundle/TE link) then the LOVC signals 
> use a label with
> "00KLM".
> 
> Regards,
> 
> Maarten
> 
> manoj juneja wrote:
> > 
> > Hi Marteen,
> >             The concept of FA is mentioned for SDH/SONET in 
> gmpls-sdh
> > -sonet draft. It says that if u have a HOVC trail as a FA 
> (advertized
> > as a link) then u can allocate the lower level signals in 
> it by making
> > the higher bits of label as 0s (i.e. S and U}. This is fine 
> for the same
> > technology. What about the case where the TDM LSP has to be tunneled
> through
> > the Lambda LSP ? What will be the form of label (i.e. 
> {SUKLM} or lambda
> > etc.) ?
> > 
> > Regards,
> > manoj.
> > 
> > >From: Maarten Vissers <[email-masked]>
> > >To: manoj juneja <[email-masked]>
> > >CC: [email-masked]
> > >Subject: Re: Lambda LSP establishment
> > >Date: Tue, 11 Dec 2001 15:56:41 +0100
> > >
> > >Manoj,
> > >
> > >You refer to one wavelength to be available between A-E without
> wavelength
> > >conversion capability. This suggests that you operate at 
> the OCh layer
> > >network.
> > >Then you specify the capacity of the 4 OCh link 
> connections (A-B, B-C,
> C-D,
> > >D-E)
> > >to be "C". Say that C is about 10 Gbit/s. You then assume 
> that there is a
> > >request for an OCh signal with capacity C/4 (e.g. 2.5 
> Gbit/s) between C
> and
> > >E.
> > >The result is that the OCh link connections C-D and D-E 
> are transporting
> > >the OCh
> > >signal (of e.g. 2.5G). These OCh link connections are now 
> in service and
> > >not
> > >longer available to an other OCh connection request. I.e. 
> a request for
> an
> > >OCh
> > >connection between A and E will be rejected.
> > >
> > >FAs are not applicable in the circuit layers. IF there is 
> a trail in
> server
> > >layer X, then there is a link in its client layer Y. X and 
> Y are thus
> > >different
> > >layer networks and signals.
> > >
> > >If C-E is a "FA", then in an OTN the C-E connection would 
> be an OCh trail
> > >supporting an ODUk (k=1 if OCh is 2G5) link with a single link
> connection.
> > >
> > >Note a FA in MPLS creates essentially a MPLS sublayer 
> network. Such is
> not
> > >possible in the SDH/SONET, OTN, PDH or ATM technologies.
> > >
> > >Regards,
> > >
> > >Maarten
> > >
> > >OCh link connections
> > >
> > >manoj juneja wrote:
> > > >
> > > > Hi All,
> > > >         If I have 5 nodes A, B, C, D and E connected as 
> shown. Assume
> > > > that only one wavelength is available on the path A to E (no
> wavelength
> > > > conversion capability is there on the complete path). 
> Let the capacity
> > > > of the wavelength be C. Further assume a request arrives for
> connection
> > > > from node C to E for a line capacity of C/4. This 
> request will be
> > > > successful as we have available wavelength. Now If 
> another request
> > > > comes at node A to establish another connection from 
> node A to node E
> > > > via nodes {A,B,C,D,E} for a line capacity of C/4. 
> Should this request
> > > > be successful as we have already allocated the wavelength ?
> > > >
> > > > If the previous connection from C to E of capacity C/4 had been
> > > > advertised as a FA, in that case will the IInd request succeed ?
> > > >
> > > > If the previous connection from C to E of capacity C/4 
> had not been
> > > > advertised as FA then what will be the fate of IInd connection ?
> > > >
> > > >        A <--> B <---> C <----> D <---> <----> E
> > > >
> > > > Regards,
> > > > manoj.
> > > >
> > > > 
> _________________________________________________________________
> > > > Get your FREE download of MSN Explorer at
> > >http://explorer.msn.com/intl.asp
> > ><< mvissers.vcf >>
> > 
> > _________________________________________________________________
> > Send and receive Hotmail on your mobile device: 
http://mobile.msn.com

Delivery-date: Thu, 13 Dec 2001 00:16:50 -0800
Date: Thu, 13 Dec 2001 09:15:11 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

This is a multi-part message in MIME format.
--------------64509841E5E3E9A093182912
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

There exist well defined protection terminology in ITU-T for the transport
plane. "Working" and "Protection" are being used and not primary/secondary. E.g.
a 1+1 architecture has one working connection, one protection connection and a
permanent bridge.

Besides working/protection indication for the transport entity, there is 
- "active" and "standby" to indicate if the signal is selected from the working
or protection transport entity; i.e. if selector selects from working, the
working is active and protection is standby, if the selector selects from
protection the working is standby and the protection is active.
- "normal" and "extra traffic" signal. The normal signal is protected.

Regards,

Maarten

[email-masked] wrote:
> 
> Jonathan....review the text below....I think the problem is 1:1.
> 
> neil
> 
> > -----Original Message-----
> > From: Jonathan Lang [mailto:[email-masked]]
> > Sent: 12 December 2001 17:46
> > To: 'Ben Mack-Crane'; John Drake
> > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > Subject: RE: Moving right along ... generalized-signaling-06
> >
> >
> > Ben,
> >   Please see inline.
> >
> > Thanks,
> > Jonathan
> >
> > > -----Original Message-----
> > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > Sent: Wednesday, December 12, 2001 8:56 AM
> > > To: John Drake
> > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > Subject: Re: Moving right along ... generalized-signaling-06
> > >
> > >
> > > See comment below.
> > >
> > > Regards,
> > > Ben
> > >
> > > John Drake wrote:
> > > >
> > > > Snipped
> > > >
> > > > -----Original Message-----
> > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > Sent: Tuesday, December 11, 2001 6:38 AM
> > > > To: Lou Berger
> > > > Cc: Kireeti Kompella; [email-masked]
> > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > >
> > > > >
> > > > > >
> > > > > >7) In Protection Information it states "The resources
> > > allocated for a
> > > > > >    secondary LSP MAY be used by other LSPs until the
> > > primary LSP fails
> > > > > >    over to the secondary LSP."  This may not always be
> > > the case.  An
> > > > > >    explicit flag indicating whether or not extra
> > > traffic may use the
> > > > > >    secondary path resources is needed.
> > > > >
> > > > > ??? This is the purpose of this bit.
> > > >
> > > > This is not clear from the definition.  The bit is defined
> > > as indicating
> > > > the LSP is a secondary (or protecting) LSP and in 1+1
> > protection the
> > > > secondary LSP may not be used for extra traffic.
> > > >
> > > > Perhaps the problem here is that protection features are
> > > being defined
> > > > before the protection framework and requirements are
> > done.  Is this
> > > > presupposing some particular outcome of the recovery work in CAMP?
> > > >
> > > > JD:  I think the definition of the bit is fine.  For both
> > > 1+1 and 1:1
> > > > protection, there would be a pair of Primary LSPs between
> > the source
> > > > and destination, rather than a Primary and a Secondary.
> > >
> > > This is an unusual use of terms.  I have never encountered a case
> > > where both the working and recovery paths are call "primary."
> > >
> > > This is not consistent with either draft-mpls-recovery-framework
> > > or with draft-lang-ccamp-recovery.  I think this is a sign that the
> > > protection work is immature and not ready for progressing to RFC.
> > >
> > For 1+1 path protection, both working/recovery paths are
> > carrying user data
> > traffic and it is an endpoint decision as to which path is
> > actually the
> > working/recovery path.  At a transit node, both paths need to
> > be treated as
> > primary, as the resources are currently being used and
> > obviously can't be
> > used for Extra Traffic.
> >
--------------64509841E5E3E9A093182912
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------64509841E5E3E9A093182912--

Delivery-date: Wed, 12 Dec 2001 17:28:54 -0800
From: "Karmakar, Soumen" <[email-masked]>
To: "'Robin Qiu'" <[email-masked]>, [email-masked]
Subject: RE: NodeId as destinationIpAddress in (UNI) RSVP and LMP messages
Date: Wed, 12 Dec 2001 17:25:43 -0800

Hi Robin,
Between the pair of UNI C and UNI N there can be multiple control channels
where they can be used simultaneously or in primary/backup modes. That
really doesn't matter as long as the "signalling channel" which is a bunch
of all IPCCs between these two nodes are up. Hence the node Ids are used in
ip header.
Since in optical links there may not be one to one association of signalling
and data channels the RSVP_HOP object was modified to carry the extra
information of data channels (by adding the TLVs) . See RFC 2205 for use of
the RSVP_HOP object . Depending on the IPCC being numbered/unnumbered the
IPv4_IF_ID_RSVP_HOP  object is used to identify the IPCC ; i.e combination
of hop address (node address) and interface id used for unnumbered, in
numbered use the IP address (of ipcc) and lih is not used.

Soumen

> -----Original Message-----
> From: Robin Qiu [mailto:[email-masked]]
> Sent: Wednesday, December 12, 2001 9:18 AM
> To: [email-masked]
> Subject: NodeId as destinationIpAddress in (UNI) RSVP and LMP messages
> 
> 
> Hi,
> 
> Can anyone help on this?
> 
> In UNI125.7, 12.4.2, it says that the IP header for UNI RSVP messages
> must be set to the NodeId of the UNI peer. In section 9.3, it 
> also says
> that for ServiceDiscovery LMP messages, the destination IP address is
> set to the NodeId of the recipient.
> 
> Question: how do you force to use a specific IPCC you selected,
> assuming that the selected IPCC has a different address?
> 
> Thanks.
> 
> Robin Qiu
> 
> 
> _________________________________________________________________
> Chat with friends online, try MSN Messenger: http://messenger.msn.com
> 
> 

Delivery-date: Wed, 12 Dec 2001 12:49:22 -0800
Date: Wed, 12 Dec 2001 15:46:19 -0500
To: "Zhi-Wei Lin" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: Moving right along ... generalized-signaling-06
Cc: "Ben Mack-Crane" <[email-masked]>, "John Drake" <[email-masked]>,"Berger, Lou" <[email-masked]>, "Kireeti Kompella" <[email-masked]>,<[email-masked]>

Zhi, Ben,

         Most (if not all) of the flags in this object have been there from 
day one of the GMPLS draft.  They have been presented, discussed, and 
agreed to in multiple WG sessions.  The WG also decided (maybe in 
summer'00?) to defer other, more detailed/complex protection until we 
completed these drafts.  Time to move on...

Lou

At 12:36 PM 12/12/2001, Zhi-Wei Lin wrote:

>Hi Ben,
>
>Yes I agree. Maybe given the status of protection and complexities that
>it would introduce, can we treat it as a separate "function" of GMPLS
>and pull it out of the current document and into a new document that
>deals exclusively with protection?
>
>It would be a (relatively) simple task:
>
>(1) Remove section 7 of gmpls-sig doc
>(2) Remove section 6 of gmpls-rsvpte doc
>(3) Remove section 6 of gmpls-crldp doc
>
>and put these sections under a new document called gmpls-recovery (or
>gmpls-protection) and then start work on this separately.
>
>Zhi
>
>Ben Mack-Crane wrote:
>
> > Zhi,
> >
> > A while ago there was a draft proposing a fairly comprehensive
> > signaling solution for protection.  At the time, there was not
> > as much support for working on protection as there is now.
> >
> > There are several attributes that could be signaled in setting up
> > a protection mechanism, including
> >
> > - whether the path is a working or recovery path
> > - what notification mechanism is used to trigger the protection mechanism
> > - hold-off time
> > - wait-to-restore time, and
> > - revertive operation
> >
> > This was an early draft, so there may be other attributes needed, or some
> > simplification might be possible.  In any case, the working group must
> > decide how to progress the protection work.  I don't think it is a good
> > idea to take an ill-defined (and perhaps incomplete) solution to RFC.
> >
> > Regards,
> > Ben
> >
> > Zhi-Wei Lin wrote:
> >
> >>Hi,
> >>
> >>To further the discussion, would it be possible to add a new flag for
> >>purpose of identifying whether or not a connection (secondary
> >>connection) can support extra traffic. A 1:1 connection should be able
> >>to support extra traffic (if secondary is not used) while a 1+1 would
> >>not support extra traffic.
> >>
> >>Also, we may want to add a flag for whether or not a protection is
> >>revertive.
> >>
> >>Also, current "link flags" is assumed to provide link protection. Maybe
> >>we can add a new flag for either "link" or "path" protection.
> >>
> >>So the total is three new flags using 3 bits, out of the current 25
> >>reserved bits.
> >>
> >>What do you think?
> >>Zhi
> >>
> >>John Drake wrote:
> >>
> >>
> >>>Snipped
> >>>
> >>>-----Original Message-----
> >>>From: Ben Mack-Crane 
> [<mailto:[email-masked]>mailto:[email-masked]]
> >>>Sent: Tuesday, December 11, 2001 6:38 AM
> >>>To: Lou Berger
> >>>Cc: Kireeti Kompella; [email-masked]
> >>>Subject: Re: Moving right along ... generalized-signaling-06
> >>>
> >>>
> >>>
> >>>
> >>>>>7) In Protection Information it states "The resources allocated for a
> >>>>>  secondary LSP MAY be used by other LSPs until the primary LSP fails
> >>>>>  over to the secondary LSP."  This may not always be the case.  An
> >>>>>  explicit flag indicating whether or not extra traffic may use the
> >>>>>  secondary path resources is needed.
> >>>>>
> >>>>>
> >>>>??? This is the purpose of this bit.
> >>>>
> >>>>
> >>>This is not clear from the definition.  The bit is defined as indicating
> >>>the LSP is a secondary (or protecting) LSP and in 1+1 protection the
> >>>secondary LSP may not be used for extra traffic.
> >>>
> >>>Perhaps the problem here is that protection features are being defined
> >>>before the protection framework and requirements are done.  Is this
> >>>presupposing some particular outcome of the recovery work in CAMP?
> >>>
> >>>JD:  I think the definition of the bit is fine.  For both 1+1 and 1:1
> >>>protection, there would be a pair of Primary LSPs between the source
> >>>and destination, rather than a Primary and a Secondary.
> >>>
> >>>
> >>>

Delivery-date: Wed, 12 Dec 2001 12:44:13 -0800
From: "Raju Venkatraman" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Reception of RSVP packets at intermediate node
Date: Wed, 12 Dec 2001 20:40:46 +0000

Hi,

Sorry for posting this question on this mailing list but I'd appreciate any 
help to my question.

Is there a socket option to intercept and receive RSVP protocol messages at 
intermediate node on Sun Solaris [reception of packets not destined to this 
intermediate node]? The pacekts with router alert option are just not being 
intercepted at intermediate node. At intermediate node, when such packet is 
received an ICMP packet is being sent towards upstream node with cause "Bad 
Protocol (46), Destination Unreachable".

Any help would be greatly appreciated.

Regards.
Raju

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

Delivery-date: Wed, 12 Dec 2001 12:36:27 -0800
Date: Wed, 12 Dec 2001 15:30:45 -0500
To: "Ben Mack-Crane" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: Moving right along ... generalized-rsvp-te-05
Cc: "Berger, Lou" <[email-masked]>, "Kireeti Kompella" <[email-masked]>,<[email-masked]>

Ben,
         see below for topics not covered in other threads.

Lou

At 09:37 AM 12/11/2001, Ben Mack-Crane wrote:

>See comments below.
>
>Regards,
>Ben
>
>Lou Berger wrote:
> >
> > At 03:08 PM 10/29/2001, Ben Mack-Crane wrote:
> >
> > >After reviewing draft-ietf-mpls-generalized-rsvp-te-05.txt
> > >I have the following comments and questions:
> > >
> > >1) In the procedures regarding the Generalized Label Request
> > >    object, the statement is made that "The node may either
> > >    directly support the LSP or it may use a tunnel (FA),
> > >    i.e., another class of switching."
> >
> > please see the routing drafts.
>
>Will these tell me that an FA is a type of switching?  I still think
>that's not accurate.

[covered in other threads]

> >
> > >A Tunnel (FA) is a type
> > >    of link, not a class of switching.  This adds to the
> > >    confusion I've noted about the need for and use of Switching
> > >    Type.
>
>Switching Type continues to be ill-defined.  I have heard that the real
>definition is different from that given in the current drafts.  If the
>signaling information is not clearly defined and it's use described, we
>can hardly expect interoperability.

I can't speak for others.  My belief is that there is a very concrete 
definition.   I thought the text in the draft was clear as well, but let me 
try again:

         Switching Type: 8 bits

         Indicates the type of switching that should be performed
         on a particular link.  This field is needed for links that
         advertise more than one type of switching capability.
         This field contains one of the values advertised for the
         corresponding link in the routing Switching Capability
         field as defined in [GMPLS-RTG].

In other words, on links where one Switching Capability is advertised 
(which will be all the time for most equipment) Switching Type is set to 
the same value as advertised in routing.  On links where multiple Switching 
Capabilities are advertised, Switching Type is set to the value advertised 
in Switching Capability that matches the type of switching to be performed.

[I'll put the revised text in the next rev...]

> >
> > >2) Bandwidth Encoding use of the Intserv Tspec object seems
> > >    quite unusual since this use is not consistent with existing
> > >    uses of this object, and new uses could easily use a new
> > >    C-Type.
> >
> > I think either approach work.  This topic was discussed by the authors at
> > least 12-18 months. The current approach was decided then.
>
>It was discussed and rejected for TDM.

>At least we should clarify the
>applicability for this use of the Intserv Tspec.

There was text to this affect in one version.  We removed it based on a 
comment that as the drafts are not technology specific, the comment was 
inappropriate.  As we clearly can't please everyone all the time, the 
current text will stand.

> >
> > >3) In the procedures for Generalized Label it states "If the label is
> > >    unacceptable then the recipient MUST generate a ResvErr message with
> > >    a "Routing problem/MPLS label allocation failure" indication."
> > >    I think "Unacceptable Label Value" would be more appropriate.
> >
> > okay.
> >
> > >4) In the Waveband Switching section it says "For compatibility reasons,
> > >    a new RSVP C-Type (3) is assigned."  What is the compatability
> > >    problem this is solving?
> >
> > simply to distinguish types.  I remove the text to avoid such confusion in
> > the future.
> >
> > >5) In the Label Set object, why is the Label Type field 14 bits if
> > >    only the low order 8 bits are used?
> >
> > for CR-LDP compatibility.
> >
> > >6) Some new error strings are defined, "Label Set" and "Unsupported Link
> > >    Protection," but no values or placeholders are included. Where are 
> new
> > >    error values to be documented?
> >
> > As part of IANA assignment.
>
>Is this to be added to the IANA Considerations section or is it a new 
>document?

The document will be updated when values are assigned in the appropriate 
places.  Most are marked by TBA.

> >
> > >7) The Notify message is intended to "enable expedited notification of
> > >    failures," but it relies on the IP layer which may be affected by the
> > >    failure that the Notify is reporting.  This could defeat the goal
> > >    of rapid notification.  Without some means of guaranteeing the Notify
> > >    doesn't have to wait for IP routing convergence to be delivered,
> > >    it isn't a satisfactory solution.
> > >
>
>Well?  Does anyone else have thoughts on this?
>
> > >8) The description of the C-Type field in the Label ERO subobject 
> suggests
> > >    that this subobject contains a Label Object.  Is this the case, or 
> does
> > >    the Label ERO subobject simple contain label values, and the C-Type
> > >    matches the C-Type that would be used if the same label values were
> > >    included in a Label object?
> >
> > per the draft:
> >
> >        Label: Variable
> >
> >           This field identifies the label to be used.  The format of this
> >           field is identical to the one used by the Label field in
> >           Generalized Label, see Section 3.2.1.
> >
> > >9) In deleting an LSP from the egress, the R bit is set in the Admin 
> Status
> > >    object.  The ingress responds with a PathTear message.  Does this 
> PathTear
> > >    contain the Admin Status object or should the R bit be cleared?
> >
> > It's not in the BNF, so no it's not included.
> >
>
>So perhaps we should change
>
>    1.  The egress node indicates its desire for deletion by inserting
>        an Admin Status Object in a Resv message and setting the Reflect (R)
>        and Delete (D) bits.
>
>to
>
>    1.  The egress node indicates its desire for deletion by inserting
>        an Admin Status Object in a Resv message and setting the
>        Delete (D) bit.

no.  This precludes unique identification of the originator of the D bit.

Lou.

> > >10)The Notify message may contain a new setting of the Admin Status.
> > >    Under what conditions would an intermediate or egress node change
> > >    Admin Status?
> >
> > It may be used at any time that a PathErr or ResvErr is generated.
> >
> > >  What happens if the Notify receiver is not the ingress?
> >
> > same action as would be taken if/when the corresponding message is 
> received.
> >
> > >11)In Interface Identification it says "Data channels are specified from
> > >the view point
> > >    of the sender of the Path message."  Is this true even for Resv 
> messages
> > >    or should it read "Data channels are specified from the viewpoint
> > >    of the sender of the message."?
> >
> > current text is correct.
> >
> > >12)In Restart_Cap it says "Refreshing of Resv and Path state SHOULD be
> > >    suppressed during this waiting period."  I assume this is refreshes
> > >    toward the failed neighbor, not to all neighbors for that LSP.  True?
> >
> > yes.
> >
> > thanks for the comments,
> > lou
> >
> > >Regards,
> > >Ben Mack-Crane

Delivery-date: Wed, 12 Dec 2001 11:07:39 -0800
From: John Drake <[email-masked]>
To: Ben Mack-Crane <[email-masked]>, Jonathan Lang <[email-masked]>
Cc: Lou Berger <[email-masked]>, Kireeti Kompella <[email-masked]>,  [email-masked]
Subject: RE: Moving right along ... generalized-signaling-06
Date: Wed, 12 Dec 2001 11:01:38 -0800

-----Original Message-----
From: Ben Mack-Crane [mailto:[email-masked]]
Sent: Wednesday, December 12, 2001 10:10 AM
To: Jonathan Lang
Cc: John Drake; Lou Berger; Kireeti Kompella; [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

Jonathan,

I agree that both the working and recovery paths must be connected
and carrying traffic (except at the egress).  It is a problem that 
the term "primary" is being overloaded to indicate both "working"
and "connected in transit nodes".

JD:  The fact that you don't understand the semantics of the
Primary/Secondary
bit doesn't necessarily mean that they're incorrect

If it is an endpoint decision as to which is the working and which
is the recovery path, this seems to add more complexity to the
operator's job in setting up protected paths.

JD:  Assertion

It would seem quite
reasonable to signal which path is which.

JD:  And why would the intermediate nodes care?

Regards,
Ben

Jonathan Lang wrote:
> 
> Ben,
>   Please see inline.
> 
> Thanks,
> Jonathan
> 
> > -----Original Message-----
> > From: Ben Mack-Crane [mailto:[email-masked]]
> > Sent: Wednesday, December 12, 2001 8:56 AM
> > To: John Drake
> > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > Subject: Re: Moving right along ... generalized-signaling-06
> >
> >
> > See comment below.
> >
> > Regards,
> > Ben
> >
> > John Drake wrote:
> > >
> > > Snipped
> > >
> > > -----Original Message-----
> > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > Sent: Tuesday, December 11, 2001 6:38 AM
> > > To: Lou Berger
> > > Cc: Kireeti Kompella; [email-masked]
> > > Subject: Re: Moving right along ... generalized-signaling-06
> > >
> > > >
> > > > >
> > > > >7) In Protection Information it states "The resources
> > allocated for a
> > > > >    secondary LSP MAY be used by other LSPs until the
> > primary LSP fails
> > > > >    over to the secondary LSP."  This may not always be
> > the case.  An
> > > > >    explicit flag indicating whether or not extra
> > traffic may use the
> > > > >    secondary path resources is needed.
> > > >
> > > > ??? This is the purpose of this bit.
> > >
> > > This is not clear from the definition.  The bit is defined
> > as indicating
> > > the LSP is a secondary (or protecting) LSP and in 1+1 protection the
> > > secondary LSP may not be used for extra traffic.
> > >
> > > Perhaps the problem here is that protection features are
> > being defined
> > > before the protection framework and requirements are done.  Is this
> > > presupposing some particular outcome of the recovery work in CAMP?
> > >
> > > JD:  I think the definition of the bit is fine.  For both
> > 1+1 and 1:1
> > > protection, there would be a pair of Primary LSPs between the source
> > > and destination, rather than a Primary and a Secondary.
> >
> > This is an unusual use of terms.  I have never encountered a case
> > where both the working and recovery paths are call "primary."
> >
> > This is not consistent with either draft-mpls-recovery-framework
> > or with draft-lang-ccamp-recovery.  I think this is a sign that the
> > protection work is immature and not ready for progressing to RFC.
> >
> For 1+1 path protection, both working/recovery paths are carrying user
data
> traffic and it is an endpoint decision as to which path is actually the
> working/recovery path.  At a transit node, both paths need to be treated
as
> primary, as the resources are currently being used and obviously can't be
> used for Extra Traffic.

Delivery-date: Wed, 12 Dec 2001 10:46:14 -0800
From: [email-masked]
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: Moving right along ... generalized-signaling-06
Date: Wed, 12 Dec 2001 18:39:19 -0000

Jonathan....review the text below....I think the problem is 1:1.

neil

> -----Original Message-----
> From: Jonathan Lang [mailto:[email-masked]]
> Sent: 12 December 2001 17:46
> To: 'Ben Mack-Crane'; John Drake
> Cc: Lou Berger; Kireeti Kompella; [email-masked]
> Subject: RE: Moving right along ... generalized-signaling-06
> 
> 
> Ben,
>   Please see inline.
> 
> Thanks,
> Jonathan
> 
> > -----Original Message-----
> > From: Ben Mack-Crane [mailto:[email-masked]]
> > Sent: Wednesday, December 12, 2001 8:56 AM
> > To: John Drake
> > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > Subject: Re: Moving right along ... generalized-signaling-06
> > 
> > 
> > See comment below.
> > 
> > Regards,
> > Ben 
> > 
> > John Drake wrote:
> > > 
> > > Snipped
> > > 
> > > -----Original Message-----
> > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > Sent: Tuesday, December 11, 2001 6:38 AM
> > > To: Lou Berger
> > > Cc: Kireeti Kompella; [email-masked]
> > > Subject: Re: Moving right along ... generalized-signaling-06
> > > 
> > > >
> > > > >
> > > > >7) In Protection Information it states "The resources 
> > allocated for a
> > > > >    secondary LSP MAY be used by other LSPs until the 
> > primary LSP fails
> > > > >    over to the secondary LSP."  This may not always be 
> > the case.  An
> > > > >    explicit flag indicating whether or not extra 
> > traffic may use the
> > > > >    secondary path resources is needed.
> > > >
> > > > ??? This is the purpose of this bit.
> > > 
> > > This is not clear from the definition.  The bit is defined 
> > as indicating
> > > the LSP is a secondary (or protecting) LSP and in 1+1 
> protection the
> > > secondary LSP may not be used for extra traffic.
> > > 
> > > Perhaps the problem here is that protection features are 
> > being defined
> > > before the protection framework and requirements are 
> done.  Is this
> > > presupposing some particular outcome of the recovery work in CAMP?
> > > 
> > > JD:  I think the definition of the bit is fine.  For both 
> > 1+1 and 1:1
> > > protection, there would be a pair of Primary LSPs between 
> the source
> > > and destination, rather than a Primary and a Secondary.
> > 
> > This is an unusual use of terms.  I have never encountered a case
> > where both the working and recovery paths are call "primary."
> > 
> > This is not consistent with either draft-mpls-recovery-framework
> > or with draft-lang-ccamp-recovery.  I think this is a sign that the
> > protection work is immature and not ready for progressing to RFC.
> > 
> For 1+1 path protection, both working/recovery paths are 
> carrying user data
> traffic and it is an endpoint decision as to which path is 
> actually the
> working/recovery path.  At a transit node, both paths need to 
> be treated as
> primary, as the resources are currently being used and 
> obviously can't be
> used for Extra Traffic.
> 

Delivery-date: Wed, 12 Dec 2001 10:31:48 -0800
Date: Wed, 12 Dec 2001 12:09:44 -0600
From: Ben Mack-Crane <[email-masked]>
To: Jonathan Lang <[email-masked]>
CC: John Drake <[email-masked]>, Lou Berger <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

Jonathan,

I agree that both the working and recovery paths must be connected
and carrying traffic (except at the egress).  It is a problem that 
the term "primary" is being overloaded to indicate both "working"
and "connected in transit nodes".

If it is an endpoint decision as to which is the working and which
is the recovery path, this seems to add more complexity to the
operator's job in setting up protected paths.  It would seem quite
reasonable to signal which path is which.

Regards,
Ben

Jonathan Lang wrote:
> 
> Ben,
>   Please see inline.
> 
> Thanks,
> Jonathan
> 
> > -----Original Message-----
> > From: Ben Mack-Crane [mailto:[email-masked]]
> > Sent: Wednesday, December 12, 2001 8:56 AM
> > To: John Drake
> > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > Subject: Re: Moving right along ... generalized-signaling-06
> >
> >
> > See comment below.
> >
> > Regards,
> > Ben
> >
> > John Drake wrote:
> > >
> > > Snipped
> > >
> > > -----Original Message-----
> > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > Sent: Tuesday, December 11, 2001 6:38 AM
> > > To: Lou Berger
> > > Cc: Kireeti Kompella; [email-masked]
> > > Subject: Re: Moving right along ... generalized-signaling-06
> > >
> > > >
> > > > >
> > > > >7) In Protection Information it states "The resources
> > allocated for a
> > > > >    secondary LSP MAY be used by other LSPs until the
> > primary LSP fails
> > > > >    over to the secondary LSP."  This may not always be
> > the case.  An
> > > > >    explicit flag indicating whether or not extra
> > traffic may use the
> > > > >    secondary path resources is needed.
> > > >
> > > > ??? This is the purpose of this bit.
> > >
> > > This is not clear from the definition.  The bit is defined
> > as indicating
> > > the LSP is a secondary (or protecting) LSP and in 1+1 protection the
> > > secondary LSP may not be used for extra traffic.
> > >
> > > Perhaps the problem here is that protection features are
> > being defined
> > > before the protection framework and requirements are done.  Is this
> > > presupposing some particular outcome of the recovery work in CAMP?
> > >
> > > JD:  I think the definition of the bit is fine.  For both
> > 1+1 and 1:1
> > > protection, there would be a pair of Primary LSPs between the source
> > > and destination, rather than a Primary and a Secondary.
> >
> > This is an unusual use of terms.  I have never encountered a case
> > where both the working and recovery paths are call "primary."
> >
> > This is not consistent with either draft-mpls-recovery-framework
> > or with draft-lang-ccamp-recovery.  I think this is a sign that the
> > protection work is immature and not ready for progressing to RFC.
> >
> For 1+1 path protection, both working/recovery paths are carrying user data
> traffic and it is an endpoint decision as to which path is actually the
> working/recovery path.  At a transit node, both paths need to be treated as
> primary, as the resources are currently being used and obviously can't be
> used for Extra Traffic.

Delivery-date: Wed, 12 Dec 2001 10:25:52 -0800
From: "Bill Breck" <[email-masked]>
To: "Zhi-Wei Lin" <[email-masked]>, "Ben Mack-Crane" <[email-masked]>
Cc: "John Drake" <[email-masked]>, "Lou Berger" <[email-masked]>, "Kireeti Kompella" <[email-masked]>, <[email-masked]>
Subject: RE: Moving right along ... generalized-signaling-06
Date: Wed, 12 Dec 2001 11:23:43 -0800

I would also strongly support this modularization approach.

We design our GMPLS software in this manner - would be great if
the drafts also matched that architecture.

-Bill Breck
 GMPLS Architect
 DeriveIt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Zhi-Wei Lin
Sent: Wednesday, December 12, 2001 9:36 AM
To: Ben Mack-Crane
Cc: John Drake; Lou Berger; Kireeti Kompella; [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

Hi Ben,

Yes I agree. Maybe given the status of protection and complexities that 
it would introduce, can we treat it as a separate "function" of GMPLS 
and pull it out of the current document and into a new document that 
deals exclusively with protection?

It would be a (relatively) simple task:

(1) Remove section 7 of gmpls-sig doc
(2) Remove section 6 of gmpls-rsvpte doc
(3) Remove section 6 of gmpls-crldp doc

and put these sections under a new document called gmpls-recovery (or 
gmpls-protection) and then start work on this separately.

Zhi

Ben Mack-Crane wrote:

> Zhi,
> 
> A while ago there was a draft proposing a fairly comprehensive
> signaling solution for protection.  At the time, there was not
> as much support for working on protection as there is now.
> 
> There are several attributes that could be signaled in setting up
> a protection mechanism, including
> 
> - whether the path is a working or recovery path
> - what notification mechanism is used to trigger the protection mechanism
> - hold-off time
> - wait-to-restore time, and
> - revertive operation
> 
> This was an early draft, so there may be other attributes needed, or some
> simplification might be possible.  In any case, the working group must
> decide how to progress the protection work.  I don't think it is a good
> idea to take an ill-defined (and perhaps incomplete) solution to RFC.
> 
> Regards,
> Ben
> 
> Zhi-Wei Lin wrote:
> 
>>Hi,
>>
>>To further the discussion, would it be possible to add a new flag for
>>purpose of identifying whether or not a connection (secondary
>>connection) can support extra traffic. A 1:1 connection should be able
>>to support extra traffic (if secondary is not used) while a 1+1 would
>>not support extra traffic.
>>
>>Also, we may want to add a flag for whether or not a protection is
>>revertive.
>>
>>Also, current "link flags" is assumed to provide link protection. Maybe
>>we can add a new flag for either "link" or "path" protection.
>>
>>So the total is three new flags using 3 bits, out of the current 25
>>reserved bits.
>>
>>What do you think?
>>Zhi
>>
>>John Drake wrote:
>>
>>
>>>Snipped
>>>
>>>-----Original Message-----
>>>From: Ben Mack-Crane [mailto:[email-masked]]
>>>Sent: Tuesday, December 11, 2001 6:38 AM
>>>To: Lou Berger
>>>Cc: Kireeti Kompella; [email-masked]
>>>Subject: Re: Moving right along ... generalized-signaling-06
>>>
>>>
>>>
>>>
>>>>>7) In Protection Information it states "The resources allocated for a
>>>>>  secondary LSP MAY be used by other LSPs until the primary LSP fails
>>>>>  over to the secondary LSP."  This may not always be the case.  An
>>>>>  explicit flag indicating whether or not extra traffic may use the
>>>>>  secondary path resources is needed.
>>>>>
>>>>>
>>>>??? This is the purpose of this bit.
>>>>
>>>>
>>>This is not clear from the definition.  The bit is defined as indicating
>>>the LSP is a secondary (or protecting) LSP and in 1+1 protection the
>>>secondary LSP may not be used for extra traffic.
>>>
>>>Perhaps the problem here is that protection features are being defined
>>>before the protection framework and requirements are done.  Is this
>>>presupposing some particular outcome of the recovery work in CAMP?
>>>
>>>JD:  I think the definition of the bit is fine.  For both 1+1 and 1:1
>>>protection, there would be a pair of Primary LSPs between the source
>>>and destination, rather than a Primary and a Secondary.
>>>
>>>
>>>

Delivery-date: Wed, 12 Dec 2001 10:25:43 -0800
From: "Mannie, Eric" <[email-masked]>
To: 'Maarten Vissers ' <[email-masked]>, 'John Drake ' <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>
Subject: RE: Lambda LSP establishment
Date: Wed, 12 Dec 2001 19:07:50 +0100

Hello Maarten,

A FA is mainly a routing concept (you advertise an LSP as a link in the same
routing protocol used for the routing of that LSP). The FA concept makes
sense for transport networks in many cases, not in other cases. FAs are
useful for SONET/SDH, but it doesn't mean that all possible kinds of
SDH/SONET LSPs can be advertised as FA. There is not an issue at all, this
is just normal operation.

A FA is a control plane feature, you cannot expect the IETF to change its
terminology for IP routing and signaling, that would not make sense and
doesn't present any interest.

>The same applies to the switching types TDM, LSC. These do not align
with the transport plane's layer network structure. They should be replaced
by the proper layer network types. I expect that it will take a few months
before this is resolved :-).

One should not forget that a lot of people that developed GMPLS work for
companies making transport plane products. They manufacture WDM systems,
photonic cross-connect, TDM ADMs, TDM cross-connects, etc. They are well
established and respected in the transport world.

GMPLS was NOT developed by a bunch of IP guys completely ignorant of
transmission systems. GMPLS was mainly developed by Sushi cookers (i.e.
transport plane experts) that came to the IETF because they thought that it
was the right place to develop an IP based control plane for a transport
plane.

The GMPLS work is mainly about OSPF, ISIS, RSVP-TE, CR-LDP, MPLS, IP
addressing, etc. The right place to do extensions on these subjects is the
IETF where the control plane experts are. This is the reason why transport
plane experts went to the IETF two years ago and started to work on GMPLS.

GMPLS is a great example of Sushi guys working with IP guys. It was very
successful considering that in the same time frame no other standardization
body was able to achieve any other control plane. There is certainly
something magic of having IP protocols used in multiple contexts.

I would appreciate if people could give the right consideration to the large
community of transport plane experts working at the IETF (this message is a
general one, not particularly intended to you).

As a conclusion, I think that the transport plane experts that developed
GMPLS are not dummies and know very well what they are doing. I appreciate
your collaboration and the one of Stephen, but I don't consider that your
are the only two people having transport and transmission experience in this
arena.

Kind regards,

Eric

-----Original Message-----
From: Maarten Vissers
To: John Drake
Cc: [email-masked]
Sent: 12/12/01 3:23 PM
Subject: Re: Lambda LSP establishment

John,

As always it takes some time to recognise the need for changes; I
appreciate
that. If it is the intention that GMPLS is used to control the transport
plane
consisting of PDH, SDH/SONET, pre-OTN and OTN then it would be logical
that it
is based on the transport plane's definitions and terminology. The
concept of
the MPLS FA isn't applicable for the mentioned technologies. Trying to
stick to
it in GMPLS is causing confusion and most likely will cause problems in
the
future. Let's prevent that latter to happen, by replacing the FA by the
proper
transport plane concepts.

The same applies to the switching types TDM, LSC. These do not align
with the
transport plane's layer network structure. They should be replaced by
the proper
layer network types.

I expect that it will take a few months before this is resolved :-).

Regards,

Maarten

John Drake wrote:
> 
> fortunately, this is just your opinion

and some others...

> 
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Tuesday, December 11, 2001 9:31 PM
> To: manoj juneja
> Cc: [email-masked]
> Subject: Re: Lambda LSP establishment
> 
> Manoj,
> 
> Forget the FA stuff, it is not appropriate in circuit networks. It
only
> applies
> to MPLS. We should remove it when it is used in relation with PDH,
> SDH/SONET,
> OTN and pre-OTN. The text in sdh-sonet draft should state that if
there is a
> LOVC link (IETF: link bundle/TE link) then the LOVC signals use a
label with
> "00KLM".
> 
> Regards,
> 
> Maarten
> 
> manoj juneja wrote:
> >
> > Hi Marteen,
> >             The concept of FA is mentioned for SDH/SONET in
gmpls-sdh
> > -sonet draft. It says that if u have a HOVC trail as a FA
(advertized
> > as a link) then u can allocate the lower level signals in it by
making
> > the higher bits of label as 0s (i.e. S and U}. This is fine for the
same
> > technology. What about the case where the TDM LSP has to be tunneled
> through
> > the Lambda LSP ? What will be the form of label (i.e. {SUKLM} or
lambda
> > etc.) ?
> >
> > Regards,
> > manoj.
> >
> > >From: Maarten Vissers <[email-masked]>
> > >To: manoj juneja <[email-masked]>
> > >CC: [email-masked]
> > >Subject: Re: Lambda LSP establishment
> > >Date: Tue, 11 Dec 2001 15:56:41 +0100
> > >
> > >Manoj,
> > >
> > >You refer to one wavelength to be available between A-E without
> wavelength
> > >conversion capability. This suggests that you operate at the OCh
layer
> > >network.
> > >Then you specify the capacity of the 4 OCh link connections (A-B,
B-C,
> C-D,
> > >D-E)
> > >to be "C". Say that C is about 10 Gbit/s. You then assume that
there is a
> > >request for an OCh signal with capacity C/4 (e.g. 2.5 Gbit/s)
between C
> and
> > >E.
> > >The result is that the OCh link connections C-D and D-E are
transporting
> > >the OCh
> > >signal (of e.g. 2.5G). These OCh link connections are now in
service and
> > >not
> > >longer available to an other OCh connection request. I.e. a request
for
> an
> > >OCh
> > >connection between A and E will be rejected.
> > >
> > >FAs are not applicable in the circuit layers. IF there is a trail
in
> server
> > >layer X, then there is a link in its client layer Y. X and Y are
thus
> > >different
> > >layer networks and signals.
> > >
> > >If C-E is a "FA", then in an OTN the C-E connection would be an OCh
trail
> > >supporting an ODUk (k=1 if OCh is 2G5) link with a single link
> connection.
> > >
> > >Note a FA in MPLS creates essentially a MPLS sublayer network. Such
is
> not
> > >possible in the SDH/SONET, OTN, PDH or ATM technologies.
> > >
> > >Regards,
> > >
> > >Maarten
> > >
> > >OCh link connections
> > >
> > >manoj juneja wrote:
> > > >
> > > > Hi All,
> > > >         If I have 5 nodes A, B, C, D and E connected as shown.
Assume
> > > > that only one wavelength is available on the path A to E (no
> wavelength
> > > > conversion capability is there on the complete path). Let the
capacity
> > > > of the wavelength be C. Further assume a request arrives for
> connection
> > > > from node C to E for a line capacity of C/4. This request will
be
> > > > successful as we have available wavelength. Now If another
request
> > > > comes at node A to establish another connection from node A to
node E
> > > > via nodes {A,B,C,D,E} for a line capacity of C/4. Should this
request
> > > > be successful as we have already allocated the wavelength ?
> > > >
> > > > If the previous connection from C to E of capacity C/4 had been
> > > > advertised as a FA, in that case will the IInd request succeed ?
> > > >
> > > > If the previous connection from C to E of capacity C/4 had not
been
> > > > advertised as FA then what will be the fate of IInd connection ?
> > > >
> > > >        A <--> B <---> C <----> D <---> <----> E
> > > >
> > > > Regards,
> > > > manoj.
> > > >
> > > >
_________________________________________________________________
> > > > Get your FREE download of MSN Explorer at
> > >http://explorer.msn.com/intl.asp
> > ><< mvissers.vcf >>
> >
> > _________________________________________________________________
> > Send and receive Hotmail on your mobile device:
http://mobile.msn.com
 <<Card for Maarten Vissers>> 

Delivery-date: Wed, 12 Dec 2001 10:21:55 -0800
Cc: Zhi-Wei Lin <[email-masked]>, John Drake <[email-masked]>, Lou Berger <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Date: Wed, 12 Dec 2001 19:02:25 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Ben Mack-Crane <[email-masked]>
Original-CC: Zhi-Wei Lin <[email-masked]>, John Drake <[email-masked]>, Lou Berger <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

This is a multi-part message in MIME format.
--------------47398F9CE3E792A421662D64
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ben,

In ITU-T Q.9/15 work is ongoing to develop a generic protection switching
overview document (G.gps). The first draft is available via the Q.9/15 web page:
http://ties.itu.int/u/tsg15/sg15/wp3/q9/ggps/ggps-v01-0110.doc
http://ties.itu.int/u/tsg15/sg15/wp3/q9/ggps/ggps-v01-0110.pdf

This first draft version contains the linear protection switching generic
aspects. To be added is the ring protection generic aspects (MS SPring and new
OCh SPring and ODUk SPring).

Regards,

Maarten

Ben Mack-Crane wrote:
> 
> Zhi,
> 
> A while ago there was a draft proposing a fairly comprehensive
> signaling solution for protection.  At the time, there was not
> as much support for working on protection as there is now.
> 
> There are several attributes that could be signaled in setting up
> a protection mechanism, including
> 
> - whether the path is a working or recovery path
> - what notification mechanism is used to trigger the protection mechanism
> - hold-off time
> - wait-to-restore time, and
> - revertive operation
> 
> This was an early draft, so there may be other attributes needed, or some
> simplification might be possible.  In any case, the working group must
> decide how to progress the protection work.  I don't think it is a good
> idea to take an ill-defined (and perhaps incomplete) solution to RFC.
> 
> Regards,
> Ben
> 
> Zhi-Wei Lin wrote:
> >
> > Hi,
> >
> > To further the discussion, would it be possible to add a new flag for
> > purpose of identifying whether or not a connection (secondary
> > connection) can support extra traffic. A 1:1 connection should be able
> > to support extra traffic (if secondary is not used) while a 1+1 would
> > not support extra traffic.
> >
> > Also, we may want to add a flag for whether or not a protection is
> > revertive.
> >
> > Also, current "link flags" is assumed to provide link protection. Maybe
> > we can add a new flag for either "link" or "path" protection.
> >
> > So the total is three new flags using 3 bits, out of the current 25
> > reserved bits.
> >
> > What do you think?
> > Zhi
> >
> > John Drake wrote:
> >
> > > Snipped
> > >
> > > -----Original Message-----
> > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > Sent: Tuesday, December 11, 2001 6:38 AM
> > > To: Lou Berger
> > > Cc: Kireeti Kompella; [email-masked]
> > > Subject: Re: Moving right along ... generalized-signaling-06
> > >
> > >
> > >
> > >>>7) In Protection Information it states "The resources allocated for a
> > >>>   secondary LSP MAY be used by other LSPs until the primary LSP fails
> > >>>   over to the secondary LSP."  This may not always be the case.  An
> > >>>   explicit flag indicating whether or not extra traffic may use the
> > >>>   secondary path resources is needed.
> > >>>
> > >>??? This is the purpose of this bit.
> > >>
> > >
> > > This is not clear from the definition.  The bit is defined as indicating
> > > the LSP is a secondary (or protecting) LSP and in 1+1 protection the
> > > secondary LSP may not be used for extra traffic.
> > >
> > > Perhaps the problem here is that protection features are being defined
> > > before the protection framework and requirements are done.  Is this
> > > presupposing some particular outcome of the recovery work in CAMP?
> > >
> > > JD:  I think the definition of the bit is fine.  For both 1+1 and 1:1
> > > protection, there would be a pair of Primary LSPs between the source
> > > and destination, rather than a Primary and a Secondary.
> > >
> > >
--------------47398F9CE3E792A421662D64
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------47398F9CE3E792A421662D64--

Delivery-date: Wed, 12 Dec 2001 10:21:46 -0800
From: Jonathan Lang <[email-masked]>
To: 'Ben Mack-Crane' <[email-masked]>, Zhi-Wei Lin <[email-masked]>
Cc: John Drake <[email-masked]>, Lou Berger <[email-masked]>,  Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: Moving right along ... generalized-signaling-06
Date: Wed, 12 Dec 2001 09:56:44 -0800

Ben,
  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: Ben Mack-Crane [mailto:[email-masked]]
> Sent: Wednesday, December 12, 2001 9:12 AM
> To: Zhi-Wei Lin
> Cc: John Drake; Lou Berger; Kireeti Kompella; [email-masked]
> Subject: Re: Moving right along ... generalized-signaling-06
> 
> 
> Zhi,
> 
> A while ago there was a draft proposing a fairly comprehensive
> signaling solution for protection.  At the time, there was not
> as much support for working on protection as there is now.
I take issue with the above sentences as follows:
sentence 1 - "comprehensive" should be replaced with "complex"
sentence 2 - there was not much support for the specific proposal.  There
has always been support for working on protection & restoration.

> 
> There are several attributes that could be signaled in setting up
> a protection mechanism, including
There are hundreds of attributes that *could* be signaled for setting up a
protection mechanism.  However, it's not clear that all of them are actually
needed.

> 
> - whether the path is a working or recovery path
> - what notification mechanism is used to trigger the 
> protection mechanism
> - hold-off time
> - wait-to-restore time, and
> - revertive operation
> 
> This was an early draft, so there may be other attributes 
> needed, or some
> simplification might be possible.  In any case, the working group must
> decide how to progress the protection work.  I don't think it 
> is a good
> idea to take an ill-defined (and perhaps incomplete) solution to RFC.
> 
> Regards,
> Ben
> 
> Zhi-Wei Lin wrote:
> > 
> > Hi,
> > 
> > To further the discussion, would it be possible to add a 
> new flag for
> > purpose of identifying whether or not a connection (secondary
> > connection) can support extra traffic. A 1:1 connection 
> should be able
> > to support extra traffic (if secondary is not used) while a 
> 1+1 would
> > not support extra traffic.
> > 
> > Also, we may want to add a flag for whether or not a protection is
> > revertive.
> > 
> > Also, current "link flags" is assumed to provide link 
> protection. Maybe
> > we can add a new flag for either "link" or "path" protection.
> > 
> > So the total is three new flags using 3 bits, out of the current 25
> > reserved bits.
> > 
> > What do you think?
> > Zhi
> > 
> > John Drake wrote:
> > 
> > > Snipped
> > >
> > > -----Original Message-----
> > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > Sent: Tuesday, December 11, 2001 6:38 AM
> > > To: Lou Berger
> > > Cc: Kireeti Kompella; [email-masked]
> > > Subject: Re: Moving right along ... generalized-signaling-06
> > >
> > >
> > >
> > >>>7) In Protection Information it states "The resources 
> allocated for a
> > >>>   secondary LSP MAY be used by other LSPs until the 
> primary LSP fails
> > >>>   over to the secondary LSP."  This may not always be 
> the case.  An
> > >>>   explicit flag indicating whether or not extra traffic 
> may use the
> > >>>   secondary path resources is needed.
> > >>>
> > >>??? This is the purpose of this bit.
> > >>
> > >
> > > This is not clear from the definition.  The bit is 
> defined as indicating
> > > the LSP is a secondary (or protecting) LSP and in 1+1 
> protection the
> > > secondary LSP may not be used for extra traffic.
> > >
> > > Perhaps the problem here is that protection features are 
> being defined
> > > before the protection framework and requirements are 
> done.  Is this
> > > presupposing some particular outcome of the recovery work in CAMP?
> > >
> > > JD:  I think the definition of the bit is fine.  For both 
> 1+1 and 1:1
> > > protection, there would be a pair of Primary LSPs between 
> the source
> > > and destination, rather than a Primary and a Secondary.
> > >
> > >
> 

Delivery-date: Wed, 12 Dec 2001 10:12:49 -0800
Date: Wed, 12 Dec 2001 08:58:52 -0800 (PST)
From: Dimitri Papadimitriou <[email-masked]>
Subject: Re: Lambda LSP establishment
To: [email-masked]
Cc: [email-masked]

Maarten,

You have respond to John that the FA concept is
unapplicable to SDH/Sonet, OTN, etc. layered 
transmission network technologies. 

Well to this assertion demonstrating that you
didn't fully understand the draft-ietf-mpls-
lsp-hierarchy-03.txt and that you didn't see
the response that Mike Sexton (one of the fathers
of the G.805 model) gave to you mid-October in
order to explain you that the FA and regions 
concept are in perfect alignment with G.805.

Unfortunately and as always it takes some time
for some people to understand concepts that don't 
come from their own.

Thanks,
- dimitri. 

__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com

Delivery-date: Wed, 12 Dec 2001 10:09:41 -0800
From: Jonathan Lang <[email-masked]>
To: 'Ben Mack-Crane' <[email-masked]>, John Drake <[email-masked]>
Cc: Lou Berger <[email-masked]>, Kireeti Kompella <[email-masked]>,  [email-masked]
Subject: RE: Moving right along ... generalized-signaling-06
Date: Wed, 12 Dec 2001 09:45:34 -0800

Ben,
  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: Ben Mack-Crane [mailto:[email-masked]]
> Sent: Wednesday, December 12, 2001 8:56 AM
> To: John Drake
> Cc: Lou Berger; Kireeti Kompella; [email-masked]
> Subject: Re: Moving right along ... generalized-signaling-06
> 
> 
> See comment below.
> 
> Regards,
> Ben 
> 
> John Drake wrote:
> > 
> > Snipped
> > 
> > -----Original Message-----
> > From: Ben Mack-Crane [mailto:[email-masked]]
> > Sent: Tuesday, December 11, 2001 6:38 AM
> > To: Lou Berger
> > Cc: Kireeti Kompella; [email-masked]
> > Subject: Re: Moving right along ... generalized-signaling-06
> > 
> > >
> > > >
> > > >7) In Protection Information it states "The resources 
> allocated for a
> > > >    secondary LSP MAY be used by other LSPs until the 
> primary LSP fails
> > > >    over to the secondary LSP."  This may not always be 
> the case.  An
> > > >    explicit flag indicating whether or not extra 
> traffic may use the
> > > >    secondary path resources is needed.
> > >
> > > ??? This is the purpose of this bit.
> > 
> > This is not clear from the definition.  The bit is defined 
> as indicating
> > the LSP is a secondary (or protecting) LSP and in 1+1 protection the
> > secondary LSP may not be used for extra traffic.
> > 
> > Perhaps the problem here is that protection features are 
> being defined
> > before the protection framework and requirements are done.  Is this
> > presupposing some particular outcome of the recovery work in CAMP?
> > 
> > JD:  I think the definition of the bit is fine.  For both 
> 1+1 and 1:1
> > protection, there would be a pair of Primary LSPs between the source
> > and destination, rather than a Primary and a Secondary.
> 
> This is an unusual use of terms.  I have never encountered a case
> where both the working and recovery paths are call "primary."
> 
> This is not consistent with either draft-mpls-recovery-framework
> or with draft-lang-ccamp-recovery.  I think this is a sign that the
> protection work is immature and not ready for progressing to RFC.
> 
For 1+1 path protection, both working/recovery paths are carrying user data
traffic and it is an endpoint decision as to which path is actually the
working/recovery path.  At a transit node, both paths need to be treated as
primary, as the resources are currently being used and obviously can't be
used for Extra Traffic.

Delivery-date: Wed, 12 Dec 2001 10:00:03 -0800
Date: Wed, 12 Dec 2001 11:38:53 -0600
From: Ben Mack-Crane <[email-masked]>
To: John Drake <[email-masked]>
CC: Zhi-Wei Lin <[email-masked]>, Lou Berger <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

What does it mean for something to be "a policy decision?"

I take this to mean that it must be configured via a management
interface.  Anything signaling can do can also be done via
management.  The goal is to signal all the necessary
information so that an LSP can be setup to provide the desired
service in an interoperable way.  Leaving some aspects to "policy"
simply means that there is no guarantee that these aspects
will be interoperable (or even easy to configure in a uniform way).

Regards,
Ben

John Drake wrote:
> 
> As I understand it, discussion is closed.  But to answer your questions:
> 
> 1) No, it's a policy decision at the intermediate node.
> 
> 2) No, revertive behavior is a policy decision at the LSP endpoints
> 
> 3) No, path protection is a policy decision at the LSP endpoints
> 
> -----Original Message-----
> From: Zhi-Wei Lin [mailto:[email-masked]]
> Sent: Tuesday, December 11, 2001 8:37 AM
> To: John Drake
> Cc: Ben Mack-Crane; Lou Berger; Kireeti Kompella; [email-masked]
> Subject: Re: Moving right along ... generalized-signaling-06
> 
> Hi,
> 
> To further the discussion, would it be possible to add a new flag for
> purpose of identifying whether or not a connection (secondary
> connection) can support extra traffic. A 1:1 connection should be able
> to support extra traffic (if secondary is not used) while a 1+1 would
> not support extra traffic.
> 
> Also, we may want to add a flag for whether or not a protection is
> revertive.
> 
> Also, current "link flags" is assumed to provide link protection. Maybe
> we can add a new flag for either "link" or "path" protection.
> 
> So the total is three new flags using 3 bits, out of the current 25
> reserved bits.
> 
> What do you think?
> Zhi
> 
> John Drake wrote:
> 
> > Snipped
> >
> > -----Original Message-----
> > From: Ben Mack-Crane [mailto:[email-masked]]
> > Sent: Tuesday, December 11, 2001 6:38 AM
> > To: Lou Berger
> > Cc: Kireeti Kompella; [email-masked]
> > Subject: Re: Moving right along ... generalized-signaling-06
> >
> >
> >
> >>>7) In Protection Information it states "The resources allocated for a
> >>>   secondary LSP MAY be used by other LSPs until the primary LSP fails
> >>>   over to the secondary LSP."  This may not always be the case.  An
> >>>   explicit flag indicating whether or not extra traffic may use the
> >>>   secondary path resources is needed.
> >>>
> >>??? This is the purpose of this bit.
> >>
> >
> > This is not clear from the definition.  The bit is defined as indicating
> > the LSP is a secondary (or protecting) LSP and in 1+1 protection the
> > secondary LSP may not be used for extra traffic.
> >
> > Perhaps the problem here is that protection features are being defined
> > before the protection framework and requirements are done.  Is this
> > presupposing some particular outcome of the recovery work in CAMP?
> >
> > JD:  I think the definition of the bit is fine.  For both 1+1 and 1:1
> > protection, there would be a pair of Primary LSPs between the source
> > and destination, rather than a Primary and a Secondary.
> >
> >

Delivery-date: Wed, 12 Dec 2001 09:54:57 -0800
Date: Wed, 12 Dec 2001 12:36:20 -0500
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Ben Mack-Crane <[email-masked]>
CC: John Drake <[email-masked]>, Lou Berger <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

Hi Ben,

Yes I agree. Maybe given the status of protection and complexities that 
it would introduce, can we treat it as a separate "function" of GMPLS 
and pull it out of the current document and into a new document that 
deals exclusively with protection?

It would be a (relatively) simple task:

(1) Remove section 7 of gmpls-sig doc
(2) Remove section 6 of gmpls-rsvpte doc
(3) Remove section 6 of gmpls-crldp doc

and put these sections under a new document called gmpls-recovery (or 
gmpls-protection) and then start work on this separately.

Zhi

Ben Mack-Crane wrote:

> Zhi,
> 
> A while ago there was a draft proposing a fairly comprehensive
> signaling solution for protection.  At the time, there was not
> as much support for working on protection as there is now.
> 
> There are several attributes that could be signaled in setting up
> a protection mechanism, including
> 
> - whether the path is a working or recovery path
> - what notification mechanism is used to trigger the protection mechanism
> - hold-off time
> - wait-to-restore time, and
> - revertive operation
> 
> This was an early draft, so there may be other attributes needed, or some
> simplification might be possible.  In any case, the working group must
> decide how to progress the protection work.  I don't think it is a good
> idea to take an ill-defined (and perhaps incomplete) solution to RFC.
> 
> Regards,
> Ben
> 
> Zhi-Wei Lin wrote:
> 
>>Hi,
>>
>>To further the discussion, would it be possible to add a new flag for
>>purpose of identifying whether or not a connection (secondary
>>connection) can support extra traffic. A 1:1 connection should be able
>>to support extra traffic (if secondary is not used) while a 1+1 would
>>not support extra traffic.
>>
>>Also, we may want to add a flag for whether or not a protection is
>>revertive.
>>
>>Also, current "link flags" is assumed to provide link protection. Maybe
>>we can add a new flag for either "link" or "path" protection.
>>
>>So the total is three new flags using 3 bits, out of the current 25
>>reserved bits.
>>
>>What do you think?
>>Zhi
>>
>>John Drake wrote:
>>
>>
>>>Snipped
>>>
>>>-----Original Message-----
>>>From: Ben Mack-Crane [mailto:[email-masked]]
>>>Sent: Tuesday, December 11, 2001 6:38 AM
>>>To: Lou Berger
>>>Cc: Kireeti Kompella; [email-masked]
>>>Subject: Re: Moving right along ... generalized-signaling-06
>>>
>>>
>>>
>>>
>>>>>7) In Protection Information it states "The resources allocated for a
>>>>>  secondary LSP MAY be used by other LSPs until the primary LSP fails
>>>>>  over to the secondary LSP."  This may not always be the case.  An
>>>>>  explicit flag indicating whether or not extra traffic may use the
>>>>>  secondary path resources is needed.
>>>>>
>>>>>
>>>>??? This is the purpose of this bit.
>>>>
>>>>
>>>This is not clear from the definition.  The bit is defined as indicating
>>>the LSP is a secondary (or protecting) LSP and in 1+1 protection the
>>>secondary LSP may not be used for extra traffic.
>>>
>>>Perhaps the problem here is that protection features are being defined
>>>before the protection framework and requirements are done.  Is this
>>>presupposing some particular outcome of the recovery work in CAMP?
>>>
>>>JD:  I think the definition of the bit is fine.  For both 1+1 and 1:1
>>>protection, there would be a pair of Primary LSPs between the source
>>>and destination, rather than a Primary and a Secondary.
>>>
>>>
>>>

Delivery-date: Wed, 12 Dec 2001 09:42:33 -0800
Date: Wed, 12 Dec 2001 11:26:41 -0600
From: Ben Mack-Crane <[email-masked]>
To: CCAMP <[email-masked]>
Subject: Comment on Recovery Effort

Hello,

This is a comment that I was unable to make in the WG meeting yesterday
due to time constraints:

The CCAMP recovery work includes contributions that are aimed at 
developing a common terminology for the recovery work.  A good amount of
effort has already gone into a similar effort in MPLS to produce
the draft-ietf-mpls-recovery-framework document, which I think
is progressing toward informational RFC.

It would be a very good idea if CCAMP would build on this work rather
than starting over and defining new terms for the same concepts covered
in that document.  There are certainly some concepts that apply only
to statistical networks; however, many of the concepts, terms and definitions,
either apply directly to other technologies (e.g., TDM, optical) or
could be relatively easily adjusted to do so.

There is also an existing body of work covering recovery mechanisms (particularly
protection switching) in the ITU standards (as pointed out by Maarten).  
The terminology is probably not completely consistent between the ITU and IETF, 
and perhaps this can be remedied somewhat as well.

In any case, starting a new effort to define common terminology is
not a good idea.  We should build on what is already there.

Regards,
Ben

Delivery-date: Wed, 12 Dec 2001 09:19:20 -0800
From: "Robin Qiu" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: NodeId as destinationIpAddress in (UNI) RSVP and LMP messages
Date: Wed, 12 Dec 2001 12:17:32 -0500

Hi,

Can anyone help on this?

In UNI125.7, 12.4.2, it says that the IP header for UNI RSVP messages
must be set to the NodeId of the UNI peer. In section 9.3, it also says
that for ServiceDiscovery LMP messages, the destination IP address is
set to the NodeId of the recipient.

Question: how do you force to use a specific IPCC you selected,
assuming that the selected IPCC has a different address?

Thanks.

Robin Qiu

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

Delivery-date: Wed, 12 Dec 2001 09:19:11 -0800
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Tim Hall" <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>, "Edward Harrison" <[email-masked]>, "Adrian Farrel" <[email-masked]>, "Cheenu Srinivasan" <[email-masked]>
Subject: MIBs for GMPLS
Date: Wed, 12 Dec 2001 12:17:43 -0500

This is a multi-part message in MIME format.

------=_NextPart_000_00AD_01C18307.0088F570
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

At the CCAMP meeting in SLC Tom introduced the set of MIBs for GMPLS =
that we have produced.

Kireeti asked that we take the MIBs to the list to ensure that the big =
issues have been addressed, that everyone is comfortable with the =
approach and there really is a need for the MIBs.

Requirements are handled by...

- protocols within the IETF need MIBs, further=20
  draft-ietf-ccamp-gmpls-architecture-01.txt
  explicitly requires MIBs for GMPLS=20

The biggest issue outstanding was whether the Labels MIB should be =
included within the LSR MIB.  The authors currently feel that it should =
remain as a separate MIB

- to allow people to implement only the TE MIB
  without putting complex conformance statements
  in the LSR MIB
- to allow people to clearly not implement the
  Labels MIB at all.
We would welcome input on this.

Please take this opportunity to give us your input and help shape the =
MIBs.

We hope to respin the drafts in a compilable form in the next few days.

The MIBs are...

http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-tc-mib-00=
.txt
http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-label-mib=
-00.txt
http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-te-mib-00=
.txt
http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-lsr-mib-0=
0.txt

Regards,
Adrian

--
Adrian Farrel
Movaz Networks Inc.
Tel: 703-847-1867
[email-masked]

------=_NextPart_000_00AD_01C18307.0088F570
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3019.2500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DCourier size=3D2>At the CCAMP meeting in SLC Tom =
introduced the=20
set of MIBs for GMPLS that we have produced.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Kireeti asked that we take the MIBs =
to the list=20
to ensure that the big issues have been addressed, that everyone is =
comfortable=20
with the approach and there really is a need for the MIBs.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Requirements are handled =
by...</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>- protocols within the IETF need =
MIBs, further=20
</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;=20
draft-ietf-ccamp-gmpls-architecture-01.txt</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; explicitly requires MIBs for=20
GMPLS&nbsp;</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>The biggest issue outstanding was =
whether the=20
Labels MIB should be included within the LSR MIB.&nbsp; The authors =
currently=20
feel that it should remain as a separate MIB</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>- to allow people to implement only =
the TE=20
MIB</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; without putting complex =
conformance=20
statements</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; in the LSR MIB</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>- to allow people to clearly not =
implement=20
the</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Labels MIB at =
all.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>We would welcome input on =
this.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Please take this opportunity to give =
us your=20
input and help shape the MIBs.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>We hope to respin the drafts in a =
compilable form=20
in the next few days.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>The MIBs are...</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>
<DIV><FONT face=3DCourier size=3D2><A=20
href=3D"http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-t=
c-mib-00.txt">http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-g=
mpls-tc-mib-00.txt</A></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2><A=20
href=3D"http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-l=
abel-mib-00.txt">http://search.ietf.org/internet-drafts/draft-nadeau-ccam=
p-gmpls-label-mib-00.txt</A></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2><A=20
href=3D"http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-t=
e-mib-00.txt">http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-g=
mpls-te-mib-00.txt</A></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2><A=20
href=3D"http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-l=
sr-mib-00.txt">http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-=
gmpls-lsr-mib-00.txt</A></FONT></DIV></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Adrian</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>--<BR>Adrian Farrel<BR>Movaz Networks =

Inc.<BR>Tel: 703-847-1867<BR><A=20
href=3D"mailto:[email-masked]">[email-masked]</A></FONT></DIV></BOD=
Y></HTML>

------=_NextPart_000_00AD_01C18307.0088F570--

Delivery-date: Wed, 12 Dec 2001 09:16:42 -0800
Date: Wed, 12 Dec 2001 11:11:34 -0600
From: Ben Mack-Crane <[email-masked]>
To: Zhi-Wei Lin <[email-masked]>
CC: John Drake <[email-masked]>, Lou Berger <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

Zhi,

A while ago there was a draft proposing a fairly comprehensive
signaling solution for protection.  At the time, there was not
as much support for working on protection as there is now.

There are several attributes that could be signaled in setting up
a protection mechanism, including

- whether the path is a working or recovery path
- what notification mechanism is used to trigger the protection mechanism
- hold-off time
- wait-to-restore time, and
- revertive operation

This was an early draft, so there may be other attributes needed, or some
simplification might be possible.  In any case, the working group must
decide how to progress the protection work.  I don't think it is a good
idea to take an ill-defined (and perhaps incomplete) solution to RFC.

Regards,
Ben

Zhi-Wei Lin wrote:
> 
> Hi,
> 
> To further the discussion, would it be possible to add a new flag for
> purpose of identifying whether or not a connection (secondary
> connection) can support extra traffic. A 1:1 connection should be able
> to support extra traffic (if secondary is not used) while a 1+1 would
> not support extra traffic.
> 
> Also, we may want to add a flag for whether or not a protection is
> revertive.
> 
> Also, current "link flags" is assumed to provide link protection. Maybe
> we can add a new flag for either "link" or "path" protection.
> 
> So the total is three new flags using 3 bits, out of the current 25
> reserved bits.
> 
> What do you think?
> Zhi
> 
> John Drake wrote:
> 
> > Snipped
> >
> > -----Original Message-----
> > From: Ben Mack-Crane [mailto:[email-masked]]
> > Sent: Tuesday, December 11, 2001 6:38 AM
> > To: Lou Berger
> > Cc: Kireeti Kompella; [email-masked]
> > Subject: Re: Moving right along ... generalized-signaling-06
> >
> >
> >
> >>>7) In Protection Information it states "The resources allocated for a
> >>>   secondary LSP MAY be used by other LSPs until the primary LSP fails
> >>>   over to the secondary LSP."  This may not always be the case.  An
> >>>   explicit flag indicating whether or not extra traffic may use the
> >>>   secondary path resources is needed.
> >>>
> >>??? This is the purpose of this bit.
> >>
> >
> > This is not clear from the definition.  The bit is defined as indicating
> > the LSP is a secondary (or protecting) LSP and in 1+1 protection the
> > secondary LSP may not be used for extra traffic.
> >
> > Perhaps the problem here is that protection features are being defined
> > before the protection framework and requirements are done.  Is this
> > presupposing some particular outcome of the recovery work in CAMP?
> >
> > JD:  I think the definition of the bit is fine.  For both 1+1 and 1:1
> > protection, there would be a pair of Primary LSPs between the source
> > and destination, rather than a Primary and a Secondary.
> >
> >

Delivery-date: Wed, 12 Dec 2001 09:10:13 -0800
From: "Adrian Farrel" <[email-masked]>
To: "Don Fedyk" <[email-masked]>, "ccamp" <[email-masked]>
Cc: "Ash, Gerald R \(Jerry\)" <[email-masked]>, "Atsushi Iwata" <[email-masked]>, "Norihito Fujita" <[email-masked]>, "Simon Marshall-Unitt" <[email-masked]>
Subject: Re: Intra-area Crankback
Date: Wed, 12 Dec 2001 12:08:31 -0500

This is a multi-part message in MIME format.

------=_NextPart_000_009F_01C18305.B7423850
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: Intra-area CrankbackThanks Don.

I've been on the authors list for 18 months and no-one has mentioned =
this to me.
I will re-read your draft and highlight the differences.

Regards,
Adrian
  ----- Original Message -----=20
  From: Don Fedyk=20
  To: Adrian Farrel ; ccamp=20
  Cc: Ash, Gerald R (Jerry) ; Atsushi Iwata ; Norihito Fujita ; Simon =
Marshall-Unitt=20
  Sent: Wednesday, December 12, 2001 11:54 AM
  Subject: RE: Intra-area Crankback

  Adrian=20

  The feedback draft is intended for this type of operation.=20
  Feedback is best within the area crank back is best outside=20
  the area. We discussed all of this with the original authors=20
  many many times.=20

  Crankback is a primitive from of feedback.=20

  Don=20

  > -----Original Message-----=20
  > From: Adrian Farrel [mailto:[email-masked]]=20
  > Sent: Wednesday, December 12, 2001 11:21 AM=20
  > To: ccamp=20
  > Cc: Adrian Farrel; Ash, Gerald R (Jerry); Atsushi Iwata; Norihito=20
  > Fujita; Simon Marshall-Unitt=20
  > Subject: Intra-area Crankback=20
  >=20
  >=20
  > At the CCAMP meeting in Salt Lake City I presented=20
  > draft-iwata-mpls-crankback-02.txt=20
  >=20
  > This has previously been cast as a solution to multi-area=20
  > problems, but of=20
  > course it is equally useful within an area for collecting=20
  > additional error=20
  > information and passing it back to repair/re-route points in=20
  > the network.=20
  >=20
  > In fact, the requirements for crankback are more immediate in=20
  > the intra-area=20
  > case and we would like you to consider the draft in that=20
  > context.  That the=20
  > draft also solves inter-area problems should be seen as an=20
  > additional benefit=20
  > that can be utilized in the future if and when multi-area=20
  > MPLS takes off.=20
  >=20
  > In summary, the draft allows an ingress to control crankback=20
  > by requesting=20
  > detailed feedback from the node that detects the failure, and=20
  > by selecting the=20
  > action that can be taken within the network when failure is=20
  > detected/reported.=20
  > This additional information supplements the details reported=20
  > back (e.g. on=20
  > PathErr and GMPLS Notify) and allows recalculation of a path=20
  > that avoids the=20
  > problem.=20
  >=20
  > We would welcome your comments and feedback on the need for=20
  > crankback both=20
  > within and between areas, and on the protocol extensions=20
  > proposed in the draft.=20
  >=20
  > Thanks,=20
  > Adrian=20
  > --=20
  > Adrian Farrel=20
  > Movaz Networks Inc.=20
  > Tel: 703-847-1867=20
  > [email-masked]=20
  >=20
  >=20
  >=20
  >=20

------=_NextPart_000_009F_01C18305.B7423850
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: Intra-area Crankback</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3019.2500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DCourier size=3D2>Thanks Don.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>I've been on the authors list for 18 =
months and=20
no-one has mentioned this to me.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>I will re-read your draft and =
highlight the=20
differences.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Adrian</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:[email-masked]"=20
  title=[email-masked]>Don Fedyk</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
href=3D"mailto:[email-masked]"=20
  title=[email-masked]>Adrian Farrel</A> ; <A=20
  href=3D"mailto:[email-masked]" =
title=[email-masked]>ccamp</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
href=3D"mailto:[email-masked]"=20
  title=[email-masked]>Ash, Gerald R (Jerry)</A> ; <A=20
  href=3D"mailto:[email-masked]" =
title=[email-masked]>Atsushi=20
  Iwata</A> ; <A href=3D"mailto:[email-masked]"=20
  title=[email-masked]>Norihito Fujita</A> ; <A=20
  href=3D"mailto:[email-masked]" =
title=[email-masked]>Simon=20
  Marshall-Unitt</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, December 12, =
2001 11:54=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: Intra-area =
Crankback</DIV>
  <DIV><BR></DIV>
  <P><FONT size=3D2>Adrian</FONT> </P>
  <P><FONT size=3D2>The feedback draft is intended for this type of=20
  operation.</FONT> <BR><FONT size=3D2>Feedback is best within the area =
crank back=20
  is best outside</FONT> <BR><FONT size=3D2>the area. We discussed all =
of this=20
  with the original authors</FONT> <BR><FONT size=3D2>many many =
times.</FONT> </P>
  <P><FONT size=3D2>Crankback is a primitive from of feedback.</FONT> =
</P>
  <P><FONT size=3D2>Don</FONT> </P>
  <P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;=20
  From: Adrian Farrel [<A=20
  href=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT> =
<BR><FONT=20
  size=3D2>&gt; Sent: Wednesday, December 12, 2001 11:21 AM</FONT> =
<BR><FONT=20
  size=3D2>&gt; To: ccamp</FONT> <BR><FONT size=3D2>&gt; Cc: Adrian =
Farrel; Ash,=20
  Gerald R (Jerry); Atsushi Iwata; Norihito</FONT> <BR><FONT =
size=3D2>&gt; Fujita;=20
  Simon Marshall-Unitt</FONT> <BR><FONT size=3D2>&gt; Subject: =
Intra-area=20
  Crankback</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; At the CCAMP meeting in Salt Lake City =
I=20
  presented</FONT> <BR><FONT size=3D2>&gt;=20
  draft-iwata-mpls-crankback-02.txt</FONT> <BR><FONT size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; This has previously been cast as a =
solution to=20
  multi-area </FONT><BR><FONT size=3D2>&gt; problems, but of</FONT> =
<BR><FONT=20
  size=3D2>&gt; course it is equally useful within an area for =
collecting=20
  </FONT><BR><FONT size=3D2>&gt; additional error</FONT> <BR><FONT =
size=3D2>&gt;=20
  information and passing it back to repair/re-route points in =
</FONT><BR><FONT=20
  size=3D2>&gt; the network.</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; In fact, the requirements for crankback are more =
immediate in=20
  </FONT><BR><FONT size=3D2>&gt; the intra-area</FONT> <BR><FONT =
size=3D2>&gt; case=20
  and we would like you to consider the draft in that </FONT><BR><FONT=20
  size=3D2>&gt; context.&nbsp; That the</FONT> <BR><FONT size=3D2>&gt; =
draft also=20
  solves inter-area problems should be seen as an </FONT><BR><FONT =
size=3D2>&gt;=20
  additional benefit</FONT> <BR><FONT size=3D2>&gt; that can be utilized =
in the=20
  future if and when multi-area </FONT><BR><FONT size=3D2>&gt; MPLS =
takes=20
  off.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; In =
summary, the=20
  draft allows an ingress to control crankback </FONT><BR><FONT =
size=3D2>&gt; by=20
  requesting</FONT> <BR><FONT size=3D2>&gt; detailed feedback from the =
node that=20
  detects the failure, and </FONT><BR><FONT size=3D2>&gt; by selecting =
the</FONT>=20
  <BR><FONT size=3D2>&gt; action that can be taken within the network =
when failure=20
  is </FONT><BR><FONT size=3D2>&gt; detected/reported.</FONT> <BR><FONT=20
  size=3D2>&gt; This additional information supplements the details =
reported=20
  </FONT><BR><FONT size=3D2>&gt; back (e.g. on</FONT> <BR><FONT =
size=3D2>&gt;=20
  PathErr and GMPLS Notify) and allows recalculation of a path =
</FONT><BR><FONT=20
  size=3D2>&gt; that avoids the</FONT> <BR><FONT size=3D2>&gt; =
problem.</FONT>=20
  <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; We would =
welcome your=20
  comments and feedback on the need for </FONT><BR><FONT size=3D2>&gt; =
crankback=20
  both</FONT> <BR><FONT size=3D2>&gt; within and between areas, and on =
the=20
  protocol extensions </FONT><BR><FONT size=3D2>&gt; proposed in the =
draft.</FONT>=20
  <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Thanks,</FONT> =
<BR><FONT=20
  size=3D2>&gt; Adrian</FONT> <BR><FONT size=3D2>&gt; --</FONT> =
<BR><FONT=20
  size=3D2>&gt; Adrian Farrel</FONT> <BR><FONT size=3D2>&gt; Movaz =
Networks=20
  Inc.</FONT> <BR><FONT size=3D2>&gt; Tel: 703-847-1867</FONT> <BR><FONT =

  size=3D2>&gt; [email-masked]</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  </FONT></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_009F_01C18305.B7423850--

Delivery-date: Wed, 12 Dec 2001 09:01:04 -0800
Date: Wed, 12 Dec 2001 10:55:59 -0600
From: Ben Mack-Crane <[email-masked]>
To: John Drake <[email-masked]>
CC: Lou Berger <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

See comment below.

Regards,
Ben 

John Drake wrote:
> 
> Snipped
> 
> -----Original Message-----
> From: Ben Mack-Crane [mailto:[email-masked]]
> Sent: Tuesday, December 11, 2001 6:38 AM
> To: Lou Berger
> Cc: Kireeti Kompella; [email-masked]
> Subject: Re: Moving right along ... generalized-signaling-06
> 
> >
> > >
> > >7) In Protection Information it states "The resources allocated for a
> > >    secondary LSP MAY be used by other LSPs until the primary LSP fails
> > >    over to the secondary LSP."  This may not always be the case.  An
> > >    explicit flag indicating whether or not extra traffic may use the
> > >    secondary path resources is needed.
> >
> > ??? This is the purpose of this bit.
> 
> This is not clear from the definition.  The bit is defined as indicating
> the LSP is a secondary (or protecting) LSP and in 1+1 protection the
> secondary LSP may not be used for extra traffic.
> 
> Perhaps the problem here is that protection features are being defined
> before the protection framework and requirements are done.  Is this
> presupposing some particular outcome of the recovery work in CAMP?
> 
> JD:  I think the definition of the bit is fine.  For both 1+1 and 1:1
> protection, there would be a pair of Primary LSPs between the source
> and destination, rather than a Primary and a Secondary.

This is an unusual use of terms.  I have never encountered a case
where both the working and recovery paths are call "primary."

This is not consistent with either draft-mpls-recovery-framework
or with draft-lang-ccamp-recovery.  I think this is a sign that the
protection work is immature and not ready for progressing to RFC.

Delivery-date: Wed, 12 Dec 2001 08:56:51 -0800
From: "Don Fedyk" <[email-masked]>
To: Adrian Farrel <[email-masked]>, ccamp <[email-masked]>
Cc: "Ash, Gerald R (Jerry)" <[email-masked]>, Atsushi Iwata <[email-masked]>, Norihito Fujita <[email-masked]>, Simon Marshall-Unitt <[email-masked]>
Subject: RE: Intra-area Crankback
Date: Wed, 12 Dec 2001 11:54:10 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1832D.9EFF1A10
Content-Type: text/plain;
	charset="iso-8859-1"

Adrian

The feedback draft is intended for this type of operation.
Feedback is best within the area crank back is best outside
the area. We discussed all of this with the original authors
many many times.

Crankback is a primitive from of feedback.

Don

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Wednesday, December 12, 2001 11:21 AM
> To: ccamp
> Cc: Adrian Farrel; Ash, Gerald R (Jerry); Atsushi Iwata; Norihito
> Fujita; Simon Marshall-Unitt
> Subject: Intra-area Crankback
> 
> 
> At the CCAMP meeting in Salt Lake City I presented
> draft-iwata-mpls-crankback-02.txt
> 
> This has previously been cast as a solution to multi-area 
> problems, but of
> course it is equally useful within an area for collecting 
> additional error
> information and passing it back to repair/re-route points in 
> the network.
> 
> In fact, the requirements for crankback are more immediate in 
> the intra-area
> case and we would like you to consider the draft in that 
> context.  That the
> draft also solves inter-area problems should be seen as an 
> additional benefit
> that can be utilized in the future if and when multi-area 
> MPLS takes off.
> 
> In summary, the draft allows an ingress to control crankback 
> by requesting
> detailed feedback from the node that detects the failure, and 
> by selecting the
> action that can be taken within the network when failure is 
> detected/reported.
> This additional information supplements the details reported 
> back (e.g. on
> PathErr and GMPLS Notify) and allows recalculation of a path 
> that avoids the
> problem.
> 
> We would welcome your comments and feedback on the need for 
> crankback both
> within and between areas, and on the protocol extensions 
> proposed in the draft.
> 
> Thanks,
> Adrian
> --
> Adrian Farrel
> Movaz Networks Inc.
> Tel: 703-847-1867
> [email-masked]
> 
> 
> 
> 

------_=_NextPart_001_01C1832D.9EFF1A10
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: Intra-area Crankback</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Adrian</FONT>
</P>

<P><FONT SIZE=2>The feedback draft is intended for this type of operation.</FONT>
<BR><FONT SIZE=2>Feedback is best within the area crank back is best outside</FONT>
<BR><FONT SIZE=2>the area. We discussed all of this with the original authors</FONT>
<BR><FONT SIZE=2>many many times.</FONT>
</P>

<P><FONT SIZE=2>Crankback is a primitive from of feedback.</FONT>
</P>

<P><FONT SIZE=2>Don</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Adrian Farrel [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, December 12, 2001 11:21 AM</FONT>
<BR><FONT SIZE=2>&gt; To: ccamp</FONT>
<BR><FONT SIZE=2>&gt; Cc: Adrian Farrel; Ash, Gerald R (Jerry); Atsushi Iwata; Norihito</FONT>
<BR><FONT SIZE=2>&gt; Fujita; Simon Marshall-Unitt</FONT>
<BR><FONT SIZE=2>&gt; Subject: Intra-area Crankback</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; At the CCAMP meeting in Salt Lake City I presented</FONT>
<BR><FONT SIZE=2>&gt; draft-iwata-mpls-crankback-02.txt</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; This has previously been cast as a solution to multi-area </FONT>
<BR><FONT SIZE=2>&gt; problems, but of</FONT>
<BR><FONT SIZE=2>&gt; course it is equally useful within an area for collecting </FONT>
<BR><FONT SIZE=2>&gt; additional error</FONT>
<BR><FONT SIZE=2>&gt; information and passing it back to repair/re-route points in </FONT>
<BR><FONT SIZE=2>&gt; the network.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; In fact, the requirements for crankback are more immediate in </FONT>
<BR><FONT SIZE=2>&gt; the intra-area</FONT>
<BR><FONT SIZE=2>&gt; case and we would like you to consider the draft in that </FONT>
<BR><FONT SIZE=2>&gt; context.&nbsp; That the</FONT>
<BR><FONT SIZE=2>&gt; draft also solves inter-area problems should be seen as an </FONT>
<BR><FONT SIZE=2>&gt; additional benefit</FONT>
<BR><FONT SIZE=2>&gt; that can be utilized in the future if and when multi-area </FONT>
<BR><FONT SIZE=2>&gt; MPLS takes off.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; In summary, the draft allows an ingress to control crankback </FONT>
<BR><FONT SIZE=2>&gt; by requesting</FONT>
<BR><FONT SIZE=2>&gt; detailed feedback from the node that detects the failure, and </FONT>
<BR><FONT SIZE=2>&gt; by selecting the</FONT>
<BR><FONT SIZE=2>&gt; action that can be taken within the network when failure is </FONT>
<BR><FONT SIZE=2>&gt; detected/reported.</FONT>
<BR><FONT SIZE=2>&gt; This additional information supplements the details reported </FONT>
<BR><FONT SIZE=2>&gt; back (e.g. on</FONT>
<BR><FONT SIZE=2>&gt; PathErr and GMPLS Notify) and allows recalculation of a path </FONT>
<BR><FONT SIZE=2>&gt; that avoids the</FONT>
<BR><FONT SIZE=2>&gt; problem.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; We would welcome your comments and feedback on the need for </FONT>
<BR><FONT SIZE=2>&gt; crankback both</FONT>
<BR><FONT SIZE=2>&gt; within and between areas, and on the protocol extensions </FONT>
<BR><FONT SIZE=2>&gt; proposed in the draft.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Thanks,</FONT>
<BR><FONT SIZE=2>&gt; Adrian</FONT>
<BR><FONT SIZE=2>&gt; --</FONT>
<BR><FONT SIZE=2>&gt; Adrian Farrel</FONT>
<BR><FONT SIZE=2>&gt; Movaz Networks Inc.</FONT>
<BR><FONT SIZE=2>&gt; Tel: 703-847-1867</FONT>
<BR><FONT SIZE=2>&gt; [email-masked]</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1832D.9EFF1A10--

Envelope-to: [email-masked]
Delivery-date: Wed, 12 Dec 2001 08:21:50 -0800
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, "Ash, Gerald R \(Jerry\)" <[email-masked]>, "Atsushi Iwata" <[email-masked]>, "Norihito Fujita" <[email-masked]>, "Simon Marshall-Unitt" <[email-masked]>
Subject: Intra-area Crankback
Date: Wed, 12 Dec 2001 11:20:40 -0500

At the CCAMP meeting in Salt Lake City I presented
draft-iwata-mpls-crankback-02.txt

This has previously been cast as a solution to multi-area problems, but of
course it is equally useful within an area for collecting additional error
information and passing it back to repair/re-route points in the network.

In fact, the requirements for crankback are more immediate in the intra-area
case and we would like you to consider the draft in that context.  That the
draft also solves inter-area problems should be seen as an additional benefit
that can be utilized in the future if and when multi-area MPLS takes off.

In summary, the draft allows an ingress to control crankback by requesting
detailed feedback from the node that detects the failure, and by selecting the
action that can be taken within the network when failure is detected/reported.
This additional information supplements the details reported back (e.g. on
PathErr and GMPLS Notify) and allows recalculation of a path that avoids the
problem.

We would welcome your comments and feedback on the need for crankback both
within and between areas, and on the protocol extensions proposed in the draft.

Thanks,
Adrian
--
Adrian Farrel
Movaz Networks Inc.
Tel: 703-847-1867
[email-masked]

Delivery-date: Wed, 12 Dec 2001 07:15:27 -0800
From: John Drake <[email-masked]>
To: manoj juneja <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Lambda LSP establishment
Date: Wed, 12 Dec 2001 07:13:53 -0800

A FA would be created over a path consisting of links of switching type
lambda, and that FA would then be announced in the link state database with
a switching type of TDM.  That FA LSP (and bear in mind that other than the
Path (?) TLV) there's nothing in the link state database that identifies a
link as being a forwarding adjacency) could then be used for the routing of
other LSPs, either of switching type TDM according to the SONET/SDH
hierarchy rules or of switching type PSC.  When the node at the head end of
the LSP receives a PATH for such an LSP, it tunnels the PATH to the tail end
of the LSP, which then progresses it according to the ERO.  The RESV
returned by the tail end of the FA LSP to the head end of the FA LSP would
contain a SONET or SDH label.    

-----Original Message-----
From: manoj juneja [mailto:[email-masked]]
Sent: Tuesday, December 11, 2001 10:50 PM
To: John Drake; [email-masked]
Cc: [email-masked]
Subject: RE: Lambda LSP establishment

Hi John,
          Can u please then explain how to tunnel a TDM LSP over Lambda
LSP ? I am only interested in what type of labels the tail end of the
lambda FA-LSP will send to the head end of lambda LSP for tunneling the
TDM LSP.
These things are not clear from the drafts as u can see lot of
confusions are there regarding these on the mailing list. After
carefully reading the drafts, we are still not able to make out what the 
draft wants to say. I think these things are only clear to the people who 
either attend the IETF meeting or the authors themselves.
One should write the drafts in such a way that these should be helpful
to the readers and should not create chaos on the mailing lists.

Regards,
manoj.

>From: John Drake <[email-masked]>
>To: Maarten Vissers <[email-masked]>, manoj juneja  
><[email-masked]>
>CC: [email-masked]
>Subject: RE: Lambda LSP establishment
>Date: Tue, 11 Dec 2001 21:53:38 -0800
>
>fortunately, this is just your opinion
>
>-----Original Message-----
>From: Maarten Vissers [mailto:[email-masked]]
>Sent: Tuesday, December 11, 2001 9:31 PM
>To: manoj juneja
>Cc: [email-masked]
>Subject: Re: Lambda LSP establishment
>
>
>Manoj,
>
>Forget the FA stuff, it is not appropriate in circuit networks. It only
>applies
>to MPLS. We should remove it when it is used in relation with PDH,
>SDH/SONET,
>OTN and pre-OTN. The text in sdh-sonet draft should state that if there is 
>a
>LOVC link (IETF: link bundle/TE link) then the LOVC signals use a label 
>with
>"00KLM".
>
>Regards,
>
>Maarten
>
>manoj juneja wrote:
> >
> > Hi Marteen,
> >             The concept of FA is mentioned for SDH/SONET in gmpls-sdh
> > -sonet draft. It says that if u have a HOVC trail as a FA (advertized
> > as a link) then u can allocate the lower level signals in it by making
> > the higher bits of label as 0s (i.e. S and U}. This is fine for the same
> > technology. What about the case where the TDM LSP has to be tunneled
>through
> > the Lambda LSP ? What will be the form of label (i.e. {SUKLM} or lambda
> > etc.) ?
> >
> > Regards,
> > manoj.
> >
> > >From: Maarten Vissers <[email-masked]>
> > >To: manoj juneja <[email-masked]>
> > >CC: [email-masked]
> > >Subject: Re: Lambda LSP establishment
> > >Date: Tue, 11 Dec 2001 15:56:41 +0100
> > >
> > >Manoj,
> > >
> > >You refer to one wavelength to be available between A-E without
>wavelength
> > >conversion capability. This suggests that you operate at the OCh layer
> > >network.
> > >Then you specify the capacity of the 4 OCh link connections (A-B, B-C,
>C-D,
> > >D-E)
> > >to be "C". Say that C is about 10 Gbit/s. You then assume that there is

>a
> > >request for an OCh signal with capacity C/4 (e.g. 2.5 Gbit/s) between C
>and
> > >E.
> > >The result is that the OCh link connections C-D and D-E are 
>transporting
> > >the OCh
> > >signal (of e.g. 2.5G). These OCh link connections are now in service 
>and
> > >not
> > >longer available to an other OCh connection request. I.e. a request for
>an
> > >OCh
> > >connection between A and E will be rejected.
> > >
> > >FAs are not applicable in the circuit layers. IF there is a trail in
>server
> > >layer X, then there is a link in its client layer Y. X and Y are thus
> > >different
> > >layer networks and signals.
> > >
> > >If C-E is a "FA", then in an OTN the C-E connection would be an OCh 
>trail
> > >supporting an ODUk (k=1 if OCh is 2G5) link with a single link
>connection.
> > >
> > >Note a FA in MPLS creates essentially a MPLS sublayer network. Such is
>not
> > >possible in the SDH/SONET, OTN, PDH or ATM technologies.
> > >
> > >Regards,
> > >
> > >Maarten
> > >
> > >OCh link connections
> > >
> > >manoj juneja wrote:
> > > >
> > > > Hi All,
> > > >         If I have 5 nodes A, B, C, D and E connected as shown. 
>Assume
> > > > that only one wavelength is available on the path A to E (no
>wavelength
> > > > conversion capability is there on the complete path). Let the 
>capacity
> > > > of the wavelength be C. Further assume a request arrives for
>connection
> > > > from node C to E for a line capacity of C/4. This request will be
> > > > successful as we have available wavelength. Now If another request
> > > > comes at node A to establish another connection from node A to node 
>E
> > > > via nodes {A,B,C,D,E} for a line capacity of C/4. Should this 
>request
> > > > be successful as we have already allocated the wavelength ?
> > > >
> > > > If the previous connection from C to E of capacity C/4 had been
> > > > advertised as a FA, in that case will the IInd request succeed ?
> > > >
> > > > If the previous connection from C to E of capacity C/4 had not been
> > > > advertised as FA then what will be the fate of IInd connection ?
> > > >
> > > >        A <--> B <---> C <----> D <---> <----> E
> > > >
> > > > Regards,
> > > > manoj.
> > > >
> > > > _________________________________________________________________
> > > > Get your FREE download of MSN Explorer at
> > >http://explorer.msn.com/intl.asp
> > ><< mvissers.vcf >>
> >
> > _________________________________________________________________
> > Send and receive Hotmail on your mobile device: http://mobile.msn.com

_________________________________________________________________
Join the world's largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

Delivery-date: Wed, 12 Dec 2001 06:25:37 -0800
Cc: [email-masked]
Date: Wed, 12 Dec 2001 15:23:03 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
Original-CC: [email-masked]
Subject: Re: Lambda LSP establishment

This is a multi-part message in MIME format.
--------------8B13DB055BAFB764C817E304
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John,

As always it takes some time to recognise the need for changes; I appreciate
that. If it is the intention that GMPLS is used to control the transport plane
consisting of PDH, SDH/SONET, pre-OTN and OTN then it would be logical that it
is based on the transport plane's definitions and terminology. The concept of
the MPLS FA isn't applicable for the mentioned technologies. Trying to stick to
it in GMPLS is causing confusion and most likely will cause problems in the
future. Let's prevent that latter to happen, by replacing the FA by the proper
transport plane concepts.

The same applies to the switching types TDM, LSC. These do not align with the
transport plane's layer network structure. They should be replaced by the proper
layer network types.

I expect that it will take a few months before this is resolved :-).

Regards,

Maarten

John Drake wrote:
> 
> fortunately, this is just your opinion

and some others...

> 
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Tuesday, December 11, 2001 9:31 PM
> To: manoj juneja
> Cc: [email-masked]
> Subject: Re: Lambda LSP establishment
> 
> Manoj,
> 
> Forget the FA stuff, it is not appropriate in circuit networks. It only
> applies
> to MPLS. We should remove it when it is used in relation with PDH,
> SDH/SONET,
> OTN and pre-OTN. The text in sdh-sonet draft should state that if there is a
> LOVC link (IETF: link bundle/TE link) then the LOVC signals use a label with
> "00KLM".
> 
> Regards,
> 
> Maarten
> 
> manoj juneja wrote:
> >
> > Hi Marteen,
> >             The concept of FA is mentioned for SDH/SONET in gmpls-sdh
> > -sonet draft. It says that if u have a HOVC trail as a FA (advertized
> > as a link) then u can allocate the lower level signals in it by making
> > the higher bits of label as 0s (i.e. S and U}. This is fine for the same
> > technology. What about the case where the TDM LSP has to be tunneled
> through
> > the Lambda LSP ? What will be the form of label (i.e. {SUKLM} or lambda
> > etc.) ?
> >
> > Regards,
> > manoj.
> >
> > >From: Maarten Vissers <[email-masked]>
> > >To: manoj juneja <[email-masked]>
> > >CC: [email-masked]
> > >Subject: Re: Lambda LSP establishment
> > >Date: Tue, 11 Dec 2001 15:56:41 +0100
> > >
> > >Manoj,
> > >
> > >You refer to one wavelength to be available between A-E without
> wavelength
> > >conversion capability. This suggests that you operate at the OCh layer
> > >network.
> > >Then you specify the capacity of the 4 OCh link connections (A-B, B-C,
> C-D,
> > >D-E)
> > >to be "C". Say that C is about 10 Gbit/s. You then assume that there is a
> > >request for an OCh signal with capacity C/4 (e.g. 2.5 Gbit/s) between C
> and
> > >E.
> > >The result is that the OCh link connections C-D and D-E are transporting
> > >the OCh
> > >signal (of e.g. 2.5G). These OCh link connections are now in service and
> > >not
> > >longer available to an other OCh connection request. I.e. a request for
> an
> > >OCh
> > >connection between A and E will be rejected.
> > >
> > >FAs are not applicable in the circuit layers. IF there is a trail in
> server
> > >layer X, then there is a link in its client layer Y. X and Y are thus
> > >different
> > >layer networks and signals.
> > >
> > >If C-E is a "FA", then in an OTN the C-E connection would be an OCh trail
> > >supporting an ODUk (k=1 if OCh is 2G5) link with a single link
> connection.
> > >
> > >Note a FA in MPLS creates essentially a MPLS sublayer network. Such is
> not
> > >possible in the SDH/SONET, OTN, PDH or ATM technologies.
> > >
> > >Regards,
> > >
> > >Maarten
> > >
> > >OCh link connections
> > >
> > >manoj juneja wrote:
> > > >
> > > > Hi All,
> > > >         If I have 5 nodes A, B, C, D and E connected as shown. Assume
> > > > that only one wavelength is available on the path A to E (no
> wavelength
> > > > conversion capability is there on the complete path). Let the capacity
> > > > of the wavelength be C. Further assume a request arrives for
> connection
> > > > from node C to E for a line capacity of C/4. This request will be
> > > > successful as we have available wavelength. Now If another request
> > > > comes at node A to establish another connection from node A to node E
> > > > via nodes {A,B,C,D,E} for a line capacity of C/4. Should this request
> > > > be successful as we have already allocated the wavelength ?
> > > >
> > > > If the previous connection from C to E of capacity C/4 had been
> > > > advertised as a FA, in that case will the IInd request succeed ?
> > > >
> > > > If the previous connection from C to E of capacity C/4 had not been
> > > > advertised as FA then what will be the fate of IInd connection ?
> > > >
> > > >        A <--> B <---> C <----> D <---> <----> E
> > > >
> > > > Regards,
> > > > manoj.
> > > >
> > > > _________________________________________________________________
> > > > Get your FREE download of MSN Explorer at
> > >http://explorer.msn.com/intl.asp
> > ><< mvissers.vcf >>
> >
> > _________________________________________________________________
> > Send and receive Hotmail on your mobile device: http://mobile.msn.com
--------------8B13DB055BAFB764C817E304
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------8B13DB055BAFB764C817E304--

Delivery-date: Tue, 11 Dec 2001 22:51:49 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: Lambda LSP establishment
Date: Tue, 11 Dec 2001 23:50:27 -0700

Hi John,
          Can u please then explain how to tunnel a TDM LSP over Lambda
LSP ? I am only interested in what type of labels the tail end of the
lambda FA-LSP will send to the head end of lambda LSP for tunneling the
TDM LSP.
These things are not clear from the drafts as u can see lot of
confusions are there regarding these on the mailing list. After
carefully reading the drafts, we are still not able to make out what the 
draft wants to say. I think these things are only clear to the people who 
either attend the IETF meeting or the authors themselves.
One should write the drafts in such a way that these should be helpful
to the readers and should not create chaos on the mailing lists.

Regards,
manoj.

>From: John Drake <[email-masked]>
>To: Maarten Vissers <[email-masked]>, manoj juneja  
><[email-masked]>
>CC: [email-masked]
>Subject: RE: Lambda LSP establishment
>Date: Tue, 11 Dec 2001 21:53:38 -0800
>
>fortunately, this is just your opinion
>
>-----Original Message-----
>From: Maarten Vissers [mailto:[email-masked]]
>Sent: Tuesday, December 11, 2001 9:31 PM
>To: manoj juneja
>Cc: [email-masked]
>Subject: Re: Lambda LSP establishment
>
>
>Manoj,
>
>Forget the FA stuff, it is not appropriate in circuit networks. It only
>applies
>to MPLS. We should remove it when it is used in relation with PDH,
>SDH/SONET,
>OTN and pre-OTN. The text in sdh-sonet draft should state that if there is 
>a
>LOVC link (IETF: link bundle/TE link) then the LOVC signals use a label 
>with
>"00KLM".
>
>Regards,
>
>Maarten
>
>manoj juneja wrote:
> >
> > Hi Marteen,
> >             The concept of FA is mentioned for SDH/SONET in gmpls-sdh
> > -sonet draft. It says that if u have a HOVC trail as a FA (advertized
> > as a link) then u can allocate the lower level signals in it by making
> > the higher bits of label as 0s (i.e. S and U}. This is fine for the same
> > technology. What about the case where the TDM LSP has to be tunneled
>through
> > the Lambda LSP ? What will be the form of label (i.e. {SUKLM} or lambda
> > etc.) ?
> >
> > Regards,
> > manoj.
> >
> > >From: Maarten Vissers <[email-masked]>
> > >To: manoj juneja <[email-masked]>
> > >CC: [email-masked]
> > >Subject: Re: Lambda LSP establishment
> > >Date: Tue, 11 Dec 2001 15:56:41 +0100
> > >
> > >Manoj,
> > >
> > >You refer to one wavelength to be available between A-E without
>wavelength
> > >conversion capability. This suggests that you operate at the OCh layer
> > >network.
> > >Then you specify the capacity of the 4 OCh link connections (A-B, B-C,
>C-D,
> > >D-E)
> > >to be "C". Say that C is about 10 Gbit/s. You then assume that there is 
>a
> > >request for an OCh signal with capacity C/4 (e.g. 2.5 Gbit/s) between C
>and
> > >E.
> > >The result is that the OCh link connections C-D and D-E are 
>transporting
> > >the OCh
> > >signal (of e.g. 2.5G). These OCh link connections are now in service 
>and
> > >not
> > >longer available to an other OCh connection request. I.e. a request for
>an
> > >OCh
> > >connection between A and E will be rejected.
> > >
> > >FAs are not applicable in the circuit layers. IF there is a trail in
>server
> > >layer X, then there is a link in its client layer Y. X and Y are thus
> > >different
> > >layer networks and signals.
> > >
> > >If C-E is a "FA", then in an OTN the C-E connection would be an OCh 
>trail
> > >supporting an ODUk (k=1 if OCh is 2G5) link with a single link
>connection.
> > >
> > >Note a FA in MPLS creates essentially a MPLS sublayer network. Such is
>not
> > >possible in the SDH/SONET, OTN, PDH or ATM technologies.
> > >
> > >Regards,
> > >
> > >Maarten
> > >
> > >OCh link connections
> > >
> > >manoj juneja wrote:
> > > >
> > > > Hi All,
> > > >         If I have 5 nodes A, B, C, D and E connected as shown. 
>Assume
> > > > that only one wavelength is available on the path A to E (no
>wavelength
> > > > conversion capability is there on the complete path). Let the 
>capacity
> > > > of the wavelength be C. Further assume a request arrives for
>connection
> > > > from node C to E for a line capacity of C/4. This request will be
> > > > successful as we have available wavelength. Now If another request
> > > > comes at node A to establish another connection from node A to node 
>E
> > > > via nodes {A,B,C,D,E} for a line capacity of C/4. Should this 
>request
> > > > be successful as we have already allocated the wavelength ?
> > > >
> > > > If the previous connection from C to E of capacity C/4 had been
> > > > advertised as a FA, in that case will the IInd request succeed ?
> > > >
> > > > If the previous connection from C to E of capacity C/4 had not been
> > > > advertised as FA then what will be the fate of IInd connection ?
> > > >
> > > >        A <--> B <---> C <----> D <---> <----> E
> > > >
> > > > Regards,
> > > > manoj.
> > > >
> > > > _________________________________________________________________
> > > > Get your FREE download of MSN Explorer at
> > >http://explorer.msn.com/intl.asp
> > ><< mvissers.vcf >>
> >
> > _________________________________________________________________
> > Send and receive Hotmail on your mobile device: http://mobile.msn.com

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

Delivery-date: Tue, 11 Dec 2001 21:54:48 -0800
From: John Drake <[email-masked]>
To: Maarten Vissers <[email-masked]>, manoj juneja <[email-masked]>
Cc: [email-masked]
Subject: RE: Lambda LSP establishment
Date: Tue, 11 Dec 2001 21:53:38 -0800

fortunately, this is just your opinion

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, December 11, 2001 9:31 PM
To: manoj juneja
Cc: [email-masked]
Subject: Re: Lambda LSP establishment

Manoj,

Forget the FA stuff, it is not appropriate in circuit networks. It only
applies
to MPLS. We should remove it when it is used in relation with PDH,
SDH/SONET,
OTN and pre-OTN. The text in sdh-sonet draft should state that if there is a
LOVC link (IETF: link bundle/TE link) then the LOVC signals use a label with
"00KLM".

Regards,

Maarten

manoj juneja wrote:
> 
> Hi Marteen,
>             The concept of FA is mentioned for SDH/SONET in gmpls-sdh
> -sonet draft. It says that if u have a HOVC trail as a FA (advertized
> as a link) then u can allocate the lower level signals in it by making
> the higher bits of label as 0s (i.e. S and U}. This is fine for the same
> technology. What about the case where the TDM LSP has to be tunneled
through
> the Lambda LSP ? What will be the form of label (i.e. {SUKLM} or lambda
> etc.) ?
> 
> Regards,
> manoj.
> 
> >From: Maarten Vissers <[email-masked]>
> >To: manoj juneja <[email-masked]>
> >CC: [email-masked]
> >Subject: Re: Lambda LSP establishment
> >Date: Tue, 11 Dec 2001 15:56:41 +0100
> >
> >Manoj,
> >
> >You refer to one wavelength to be available between A-E without
wavelength
> >conversion capability. This suggests that you operate at the OCh layer
> >network.
> >Then you specify the capacity of the 4 OCh link connections (A-B, B-C,
C-D,
> >D-E)
> >to be "C". Say that C is about 10 Gbit/s. You then assume that there is a
> >request for an OCh signal with capacity C/4 (e.g. 2.5 Gbit/s) between C
and
> >E.
> >The result is that the OCh link connections C-D and D-E are transporting
> >the OCh
> >signal (of e.g. 2.5G). These OCh link connections are now in service and
> >not
> >longer available to an other OCh connection request. I.e. a request for
an
> >OCh
> >connection between A and E will be rejected.
> >
> >FAs are not applicable in the circuit layers. IF there is a trail in
server
> >layer X, then there is a link in its client layer Y. X and Y are thus
> >different
> >layer networks and signals.
> >
> >If C-E is a "FA", then in an OTN the C-E connection would be an OCh trail
> >supporting an ODUk (k=1 if OCh is 2G5) link with a single link
connection.
> >
> >Note a FA in MPLS creates essentially a MPLS sublayer network. Such is
not
> >possible in the SDH/SONET, OTN, PDH or ATM technologies.
> >
> >Regards,
> >
> >Maarten
> >
> >OCh link connections
> >
> >manoj juneja wrote:
> > >
> > > Hi All,
> > >         If I have 5 nodes A, B, C, D and E connected as shown. Assume
> > > that only one wavelength is available on the path A to E (no
wavelength
> > > conversion capability is there on the complete path). Let the capacity
> > > of the wavelength be C. Further assume a request arrives for
connection
> > > from node C to E for a line capacity of C/4. This request will be
> > > successful as we have available wavelength. Now If another request
> > > comes at node A to establish another connection from node A to node E
> > > via nodes {A,B,C,D,E} for a line capacity of C/4. Should this request
> > > be successful as we have already allocated the wavelength ?
> > >
> > > If the previous connection from C to E of capacity C/4 had been
> > > advertised as a FA, in that case will the IInd request succeed ?
> > >
> > > If the previous connection from C to E of capacity C/4 had not been
> > > advertised as FA then what will be the fate of IInd connection ?
> > >
> > >        A <--> B <---> C <----> D <---> <----> E
> > >
> > > Regards,
> > > manoj.
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at
> >http://explorer.msn.com/intl.asp
> ><< mvissers.vcf >>
> 
> _________________________________________________________________
> Send and receive Hotmail on your mobile device: http://mobile.msn.com

Delivery-date: Tue, 11 Dec 2001 21:33:27 -0800
Cc: [email-masked]
Date: Wed, 12 Dec 2001 06:30:57 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: manoj juneja <[email-masked]>
Original-CC: [email-masked]
Subject: Re: Lambda LSP establishment

This is a multi-part message in MIME format.
--------------D9B734CF61B3E7B0AEA9DF7E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Manoj,

Forget the FA stuff, it is not appropriate in circuit networks. It only applies
to MPLS. We should remove it when it is used in relation with PDH, SDH/SONET,
OTN and pre-OTN. The text in sdh-sonet draft should state that if there is a
LOVC link (IETF: link bundle/TE link) then the LOVC signals use a label with
"00KLM".

Regards,

Maarten

manoj juneja wrote:
> 
> Hi Marteen,
>             The concept of FA is mentioned for SDH/SONET in gmpls-sdh
> -sonet draft. It says that if u have a HOVC trail as a FA (advertized
> as a link) then u can allocate the lower level signals in it by making
> the higher bits of label as 0s (i.e. S and U}. This is fine for the same
> technology. What about the case where the TDM LSP has to be tunneled through
> the Lambda LSP ? What will be the form of label (i.e. {SUKLM} or lambda
> etc.) ?
> 
> Regards,
> manoj.
> 
> >From: Maarten Vissers <[email-masked]>
> >To: manoj juneja <[email-masked]>
> >CC: [email-masked]
> >Subject: Re: Lambda LSP establishment
> >Date: Tue, 11 Dec 2001 15:56:41 +0100
> >
> >Manoj,
> >
> >You refer to one wavelength to be available between A-E without wavelength
> >conversion capability. This suggests that you operate at the OCh layer
> >network.
> >Then you specify the capacity of the 4 OCh link connections (A-B, B-C, C-D,
> >D-E)
> >to be "C". Say that C is about 10 Gbit/s. You then assume that there is a
> >request for an OCh signal with capacity C/4 (e.g. 2.5 Gbit/s) between C and
> >E.
> >The result is that the OCh link connections C-D and D-E are transporting
> >the OCh
> >signal (of e.g. 2.5G). These OCh link connections are now in service and
> >not
> >longer available to an other OCh connection request. I.e. a request for an
> >OCh
> >connection between A and E will be rejected.
> >
> >FAs are not applicable in the circuit layers. IF there is a trail in server
> >layer X, then there is a link in its client layer Y. X and Y are thus
> >different
> >layer networks and signals.
> >
> >If C-E is a "FA", then in an OTN the C-E connection would be an OCh trail
> >supporting an ODUk (k=1 if OCh is 2G5) link with a single link connection.
> >
> >Note a FA in MPLS creates essentially a MPLS sublayer network. Such is not
> >possible in the SDH/SONET, OTN, PDH or ATM technologies.
> >
> >Regards,
> >
> >Maarten
> >
> >OCh link connections
> >
> >manoj juneja wrote:
> > >
> > > Hi All,
> > >         If I have 5 nodes A, B, C, D and E connected as shown. Assume
> > > that only one wavelength is available on the path A to E (no wavelength
> > > conversion capability is there on the complete path). Let the capacity
> > > of the wavelength be C. Further assume a request arrives for connection
> > > from node C to E for a line capacity of C/4. This request will be
> > > successful as we have available wavelength. Now If another request
> > > comes at node A to establish another connection from node A to node E
> > > via nodes {A,B,C,D,E} for a line capacity of C/4. Should this request
> > > be successful as we have already allocated the wavelength ?
> > >
> > > If the previous connection from C to E of capacity C/4 had been
> > > advertised as a FA, in that case will the IInd request succeed ?
> > >
> > > If the previous connection from C to E of capacity C/4 had not been
> > > advertised as FA then what will be the fate of IInd connection ?
> > >
> > >        A <--> B <---> C <----> D <---> <----> E
> > >
> > > Regards,
> > > manoj.
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at
> >http://explorer.msn.com/intl.asp
> ><< mvissers.vcf >>
> 
> _________________________________________________________________
> Send and receive Hotmail on your mobile device: http://mobile.msn.com
--------------D9B734CF61B3E7B0AEA9DF7E
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------D9B734CF61B3E7B0AEA9DF7E--

Delivery-date: Tue, 11 Dec 2001 16:41:31 -0800
Date: Tue, 11 Dec 2001 17:28:59 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: "Mannie, Eric" <[email-masked]>
CC: "'David S. Miller '" <[email-masked]>, "''Dimitri Papadimitriou' '" <[email-masked]>, "'Steve West '" <[email-masked]>, "''Maarten Vissers' '" <[email-masked]>, "'ccamp '" <[email-masked]>, "'q11/15 '" <[email-masked]>, "'t1x1.5 '" <[email-masked]>
Subject: Re: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt

Eric,
Not really. This is a different "flavor" of protection where the paths are
NOT individually or collectively protected. It is assumed that for a service
where you would be increasing or decreasing the available bandwidth, you
are generally dealing with a packet oriented service where the bandwidth
provide affects the degree of congestion but not basic connectivity. As
a result, LCAS provides a way to remove failed components from the path,
even in the middle to operate (temporarily) with reduced bandwidth.
So if you had a VC-4-10v and one of the VC-4s fails, you can operate
by temporarily reducing the bandwidth to VC-4-9v until service is restored
on the other VC. When the VCs are routed independently, this provides a
very good "lightweight" protection and the ability to take advantage of
ALL of the bandwidth in the absence of failures.
Regards, Steve

"Mannie, Eric" wrote:
> 
> Hi all,
> 
> >LBM also does not accomodate removal of non-contiguous components:
> e.g., if the 3rd of 10 concatenated VCs fail, I suppose you need
> to back down to 2 and then build up ...
> 
> Not totally correct, if they are multiple LSPs used for the circuit, you can
> remove/add VCs at the end of each LSP separately. However, since each LSP is
> protected independently, if "any VC fails" inside, the whole LSP is
> protected (so in that case the problem is a not relevant). If you want to
> have completely separate VCs, you can have one LSP for each VC. Each LSP/VC
> is then provisioned end-to-end, protected (if required) and can be routed
> independently. The capability is the same as in LCAS in that case.
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Stephen Trowbridge
> To: David S. Miller
> Cc: Mannie, Eric; 'Dimitri Papadimitriou'; Steve West; 'Maarten Vissers';
> ccamp; q11/15; t1x1.5
> Sent: 12/11/01 1:52 AM
> Subject: Re: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
> 
> David,
> Virtual Concatenation, with or without LCAS accomodates differential
> delay for different parts of the payload.
> 
> LCAS provides hitless add/remove. Also it provides for removal of
> failed components, even when this results in non-contiguous
> component numbering.
> 
> LBM does not give you hitless add and remove from the payload.
> LBM also does not accomodate removal of non-contiguous components:
> e.g., if the 3rd of 10 concatenated VCs fail, I suppose you need
> to back down to 2 and then build up ...
> Steve
> 
> "David S. Miller" wrote:
> >
> > Am I missing something?
> >
> > I thought that LCAS gains 2 things:
> > 1) Hitless and and remove of payload (dynamic bandwidth allocation)
> > but more importantly
> > 2) Differential Delay through the network for differents parts of the
> > payload (i.e. diverse routing of network traffic).
> >
> > How does GMPLS w/ LBM address the second issue?
> >
> > David Miller
> > Vitesse Semiconductor
> >
> > "Mannie, Eric" wrote:
> > >
> > > Hello Steve,
> > >
> > > Just to complement the answer of Dimitri,
> > >
> > > > You believe that the packet loss rate and robustness of LMB is
> > > > similar to LCAS ?
> > >
> > > LCAS waits for the end of control packet which is multi-framed to
> decide
> > > when the payload is significant (the "transition"). LBM uses for
> instance
> > > the C2 byte for the HOVC, since this byte appears directly in the
> POH and is
> > > not part of a control packet, that should go faster, right ? I.e.
> less
> > > glitch than with LCAS ?
> > >
> > > But having a field in the transport plane to indicate a transition
> (whatever
> > > is the field ) is not the most important issue. Even if you have
> that field,
> > > you need some time to provision the additional VCs/SPEs in the
> network. This
> > > is not done by LCAS, and any control plane or management plane will
> imply
> > > some time for that operation, and the glitch will really come from
> that
> > > process, not from the way that you detect a transition in the
> transport
> > > plane.
> > >
> > > > 4.  LBM is an extension to GMPLS.  GMPLS is required for LBM,
> whereas LCAS
> > > > could potentially be used with GMPLS or with other control plane
> or
> > > > management plane mechanisms ?
> > >
> > > When a distributed control plane is used (e.g. GMPLS or PNNI), using
> LCAS
> > > implies issues on this control plane. LCAS is a stand-alone solution
> that
> > > bypass the control plane to change the resource reservation in both
> end
> > > systems. A control plane maintains states in end systems (e.g. at
> the UNI)
> > > and in intermediate systems ! So, bandwidth modifications must be
> reflected
> > > in the control plane otherwise it will become inconsistent.
> > >
> > > Now, the control plane is natively designed to deal with these
> resource
> > > reservations including in the source and the destination (with the
> UNI).
> > > Moreover, GMPLS is natively designed to deal with bandwidth
> modification (in
> > > the packet world this was one of the major requirements).
> Originally, we
> > > just wanted to describe how to generalize these bandwidth
> modification
> > > principles to SDH/SONET and how to interwork with LCAS.
> > >
> > > Then, we saw that a large part of LCAS was overlapping with GMPLS,
> i.e. all
> > > the protocol part. The rest was the issue about when to decide that
> a VC/SPE
> > > contains real user data or not (the transition).
> > >
> > > Since LCAS added a control message, naturally it used a field in
> that
> > > control message to indicate that transition. But with GMPLS we
> didn't need
> > > any new control message, se we looked at what was available *in the
> > > transport plane* to detect the fact that a VC/SPE contains now real
> user
> > > data (i.e the transition). We found natural to use the so-called
> SDH/SONET
> > > "signal label" (e.g. the C2 byte) (note for the readers: nothing to
> do with
> > > the GMPLS label :-). So we added these aspects to the draft. This is
> the
> > > part that we expected to validate with the ITU-T/T1X1 folks, but
> flames came
> > > first...
> > >
> > > What we are certainly going to do, is to add in the draft a section
> about
> > > how GMPLS should work when LCAS is used at the same time. However,
> we think
> > > that using GMPLS and LCAS at the same time will be more complex than
> simply
> > > using GMPLS and will not bring something additional. So the natural
> > > observation came, "why should we use LCAS with GMPLS and build
> something
> > > more complex when there is almost no issue to solve when simply
> using GMPLS
> > > alone". Using GMPLS and LCAS at the same time to modify the
> bandwidth
> > > implies that we will have two signaling flows between the source and
> the
> > > destination running in parallel and overlapping. GMPLS will also
> speak with
> > > the source and the destination to do the same as LCAS, and with a
> > > distributed control plane you need GMPLS anyway (or PNNI or etc).
> > >
> > > We also added a section to explain how several GMPLS LSPs (i.e.
> circuits)
> > > can be combined together to form a larger virtually concatenated
> circuit.
> > > This allows to deal with the non co-routing of VCs/SPEs with GMPLS.
> > >
> > > Kind regards,
> > >
> > > Eric
> > >
> > > -----Original Message-----
> > > From: Dimitri Papadimitriou
> [mailto:[email-masked]]
> > > Sent: Sunday, November 18, 2001 3:44 PM
> > > To: Steve West
> > > Cc: Mannie, Eric; 'Stephen Trowbridge'; 'Maarten Vissers'; ccamp;
> > > q11/15; t1x1.5
> > > Subject: Re: [T1X1.5] Re: LCAS and
> > > draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
> > >
> > > Hi Steve,
> > >
> > > Thanks for your comments, see in-line...
> > >
> > > Steve West wrote:
> > > >
> > > > Dimitri:
> > > >
> > > > Please confirm my understanding of your proposal:
> > > >
> > > > 1.  Your proposal supports hitless link capacity adjustment.
> (Capacity
> > > > changes that occurs during transmission of a packet will not
> corrupt that
> > > > packet.)  You believe that the packet loss rate and robustness of
> LMB is
> > > > similar to LCAS ?
> > >
> > > It is mentioned in the proposal that the source waits for a
> > > confirmation from the destination (i.e. Resv Message). THEN
> > > the source "equip" the VC/SPE and sends. After the destination
> > > sees in the POH that the VC is "equipped" (transition).
> > >
> > > So instead of using the transitions proposed in LCAS (based
> > > on the H4 CTRL words) we use the ones already available.
> > >
> > > Since we are the beginning, we were very cautious but we expect to
> > > reach more than reasonable robustness and reliability.
> > >
> > > > 2.  LMB requires hardware coordination between the SONET payload
> mapper
> > > and
> > > > the SONET POH processor (C2 octet insertion/extraction logic) ?
> > >
> > > At the transport plane level C2 is the field that LBM uses for the
> > > transition in the HOVC POH.
> > >
> > > > 3.  The hardware based synchronization performance requirements
> are
> > > similar
> > > > to those required by LCAS.  Except that LCAS coordinates the
> critical
> > > > transitions using H4 instead of C2 ?  And that Virtual
> Concatenation
> > > systems
> > > > require to coordinate their payload mappers with bits 1-4 of the
> H4 byte
> > > to
> > > > determine the sequence number anyway ?
> > >
> > > See above, yes and yes (since we re-use existing VC mechanisms)
> > >
> > > > 4.  LBM is an extension to GMPLS.  GMPLS is required for LBM,
> whereas LCAS
> > > > could potentially be used with GMPLS or with other control plane
> or
> > > > management plane mechanisms ?
> > >
> > > The scope of this proposal is to use GMPLS-LBM without LCAS. In fact
> > > (from what i understand in your question) see it more from transport
> > > to control plane impact taking the assumption that you expect some
> > > hardware improvement. Let's first determine if this can be achieved
> > > and then discuss the implementation issues that can arise from this
> > > proposal. In a sense, GMPLS-LBM is a self-consistent solution.
> > >
> > > Regards,
> > > - dimitri.
> > >
> > > > Thanks,
> > > >
> > > > Steve
> > > >
> > > > -----Original Message-----
> > > > From: Dimitri Papadimitriou
> [mailto:[email-masked]]
> > > > Sent: Friday, November 16, 2001 4:09 PM
> > > > To: Mannie, Eric; 'Stephen Trowbridge'; 'Maarten Vissers'
> > > > Cc: ccamp; q11/15; t1x1.5
> > > > Subject: [T1X1.5] Re: LCAS and
> draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
> > > >
> > > > Hi folks,
> > > >
> > > > What happens... when we start the technical discussion
> > > > all guys taking part to the previous one now are gone ?
> > > >
> > > > We would like to start a technical discussion.. rather
> > > > difficult if we stay alone... or everybody agree on
> > > > proposal made in the previous e-mail ? (this in order
> > > > to refine the mechanism detailed in the GMPLS LBM I-D.)
> > > >
> > > > Any technical feedback is highly appreciated.
> > > >
> > > > Cheers,
> > > > - dimitri.
> > > >
> > > > "Mannie, Eric" wrote:
> > > > >
> > > > > Hello Stephen
> > > > >
> > > > > > GMPLS-LBM and LCAS ARE solutions to different problems.
> > > > >
> > > > > No, please see explanations below.
> > > > >
> > > > > > If you use LBM and change the mappings at the two ends without
> some
> > > > > coordination such as LCAS, you will have a glitch to the traffic
> > > > > (I think this is simple enough).
> > > > >
> > > > > No, please see below (C2 or V5 transition).
> > > > >
> > > > > >The compare/contrast discussion of LBM and LCAS is appropriate
> not
> > > > > >because LCAS is "sacred", but because you are comparing apples
> to
> > > > > >oranges. Statements in this document such as "One drawback of
> LCAS is
> > > .."
> > > > > >are unnecessary and inappropriate in this context, since LBM
> does
> > > > > >NOT solve the problem LCAS was designed to solve. Perhaps if
> you
> > > > > >were solving the SAME problem better, this would be OK, but
> this
> > > > > >is not the case.
> > > > >
> > > > > No, please see below.
> > > > >
> > > > > Simple example:
> > > > >
> > > > > 1) you first signal an additional VC/SPE to the destination (via
> a
> > > Path).
> > > > > 2) the destination knows exactly which VC/SPE is added (via the
> label).
> > > > > 3) the new VC is unequipped (indicated in POH C2 (for HOVC)),
> > > > >    so the VC/SPE is not yet added to concatenated signal.
> > > > > 4) then, you wait at the source for a confirmation from the
> destination
> > > > > (i.e. Resv).
> > > > > 5) the source "equip" the VC/SPE and sends.
> > > > > 6) the destination sees in the POH that the VC is "equipped"
> > > (transition).
> > > > >
> > > > > The difference between LCAS and LBM is that LCAS uses an
> additional
> > > > explicit
> > > > > indication in the overhead to say "this is the payload" to use.
> LBM
> > > > doesn't
> > > > > change the SDH/SONET overhead, while LCAS changes the SDH/SONET
> overhead
> > > >:-)
> > > > >
> > > > > LCAS uses a new field in the POH (CTRL) to know when the new VC
> > > > transitions
> > > > > to a significant payload. LBM proposes to do the same simply by
> looking
> > > at
> > > > > the C2 (for HOVC) transition - regular SDH/SONET field that will
> change
> > > > > anyway and that is used to indicate the type of payload.
> > > > >
> > > > > To be more precise about LCAS (I copy from the LCAS
> specification,
> > > section
> > > > > 6.3.1): "The first container frame to contain payload data for
> the new
> > > > > member shall be the container frame immediately following the
> container
> > > > > frame that contained the last bit(s) (i.e. the CRC) of the
> control
> > > packet
> > > > > with NORM/EOS message for that member" (the LCAS control
> packet).
> > > > >
> > > > > So, LCAS waits for the last bit of the appropriate LCAS control
> packet
> > > in
> > > > > the POH with the appropriate transition of its CTRL field. LBM
> waits
> > > > simply
> > > > > for the appropriate C2 (for HOVC) or V5 (for LOVC) transition in
> the POH
> > > > > (don't change SDH/SONET).
> > > > >
> > > > > By the way, this is version 0 of the draft and it was just
> posted.
> > > > >
> > > > > Suggestions, technical comments and improvements are welcome.
> > > > >
> > > > > I would appreciate if people could first read and speak before
> shooting
> > > > > directly :-)
> > > > >
> > > > > Kind regards,
> > > > >
> > > > > Eric
> > > > >
> > > > > -----Original Message-----
> > > > > From: Stephen Trowbridge [mailto:[email-masked]]
> > > > > Sent: Friday, November 16, 2001 7:49 PM
> > > > > To: Mannie, Eric
> > > > > Cc: 'Maarten Vissers'; ccamp; q11/15; t1x1.5; Dimitri
> Papadimitriou
> > > > > Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
> > > > >
> > > > > Eric,
> > > > > The point of my earlier email (items again below, this time with
> > > > > numbers) was not to prompt the comment "#3 is out of scope,
> therefore
> > > > > it is a choice between #1 and #2" (my parsing of recent
> statements).
> > > > >
> > > > > The issue (and I think the reason for Maarten's strong reaction)
> is
> > > this:
> > > > > GMPLS-LBM and LCAS are NOT different solutions to the same
> problem.
> > > > > GMPLS-LBM and LCAS ARE solutions to different problems.
> > > > > (I hope this is not too subtle for non-native English speakers).
> > > > >
> > > > > LCAS is a method to hitlessly change the mappings at the two
> > > > > ends of a virtually concatenated trail to increase or decrease
> the
> > > > > bandwidth. It does not say anything about how components to be
> > > > > added or removed from the virtually concatenated "bundle" are
> > > > > set up or taken down.
> > > > >
> > > > > LBM talks about how to set up or take down those added or
> removed
> > > > > components, but not about the details of changing the mapping
> (other
> > > > > than that it is done after the new components are successfully
> > > > > established.
> > > > >
> > > > > If you use LBM and change the mappings at the two ends without
> some
> > > > > coordination such as LCAS, you will have a glitch to the traffic
> > > > > (I think this is simple enough).
> > > > >
> > > > > The compare/contrast discussion of LBM and LCAS is appropriate
> not
> > > > > because LCAS is "sacred", but because you are comparing apples
> to
> > > > > oranges. Statements in this document such as "One drawback of
> LCAS is
> > > .."
> > > > > are unnecessary and inappropriate in this context, since LBM
> does
> > > > > NOT solve the problem LCAS was designed to solve. Perhaps if you
> > > > > were solving the SAME problem better, this would be OK, but this
> > > > > is not the case.
> > > > >
> > > > > Time to try to be constructive:
> > > > > - I think most of the current discussion of LCAS should be
> removed from
> > > > > this document. It is irrelevant since LCAS solves a different
> problem
> > > than
> > > > > LBM. To say that one is "better" than the other would only be
> meaningful
> > > > > if they were solving the same problem (can you really say that
> LBM
> > > solves
> > > > > problem A better than LCAS solves problem B?).
> > > > > - LCAS can be a good informative reference as a way to hitlessly
> modify
> > > > > the size of a virtually concatenated trail.
> > > > > - Clarify in the scope that the current draft describes the use
> of LBM
> > > > > without LCAS, which results in a traffic glitch when bandwidth
> is
> > > > modified.
> > > > > Indicate that the use of LCAS to hitlessly negotiate the changes
> to
> > > > > the size of virtually concatenated pipes after LBM sets up new
> > > > component(s)
> > > > > or before LBM takes down old component(s) is a topic for further
> study
> > > > > and perhaps to be addressed in a future version of the draft.
> > > > >
> > > > > Regards,
> > > > > Steve
> > > > >
> > > > > Steve Trowbridge wrote:
> > > > > > 1. Can you use LBM without LCAS? Yes, if you don't mind a
> glitch to
> > > > > > the traffic.
> > > > > >
> > > > > > 2. Can you use LCAS without LBM? Yes, if you don't care
> whether the
> > > > > > control plane knows that the different LSPs are part of the
> same
> > > > > > circuit.
> > > > > >
> > > > > > 3. Can you use LCAS WITH LBM? Hopefully yes, and this would
> seem to
> > > > > > be the preferred method for many applications.
> > > > >
> > > > > "Mannie, Eric" wrote:
> > > > > >
> > > > > > Hello Maarten,
> > > > > >
> > > > > > >Any sentence in which LCAS and ASON/GMPLS are compared shows
> a lack
> > > of
> > > > > > >understanding of LCAS's objective (my very strong opinion).
> > > > > >
> > > > > > Sorry, do you mean that it is forbidden to speak about your
> LCAS
> > > > document
> > > > > > and to compare GMPLS and LCAS functionalities ?
> > > > > >
> > > > > <snip, to save BW>

Delivery-date: Tue, 11 Dec 2001 16:35:24 -0800
From: "Mannie, Eric" <[email-masked]>
To: 'manoj juneja ' <[email-masked]>,  "[email-masked] '" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>
Subject: RE: Lambda LSP establishment
Date: Wed, 12 Dec 2001 01:26:40 +0100

Hi Manoj,

The SDH/SONET draft has nothing to do with lambdas. The SDH/SONET label is
for SDH/SONET only and doesn't need to care how the TDM is transported. The
lambda LSP is at another layer. The labels between the layers are completely
independent and allocated according to the rules of each respective layer.

Kind regards,

Eric

-----Original Message-----
From: manoj juneja
To: [email-masked]
Cc: [email-masked]
Sent: 12/12/01 12:27 AM
Subject: Re: Lambda LSP establishment

Hi Marteen,
            The concept of FA is mentioned for SDH/SONET in gmpls-sdh
-sonet draft. It says that if u have a HOVC trail as a FA (advertized
as a link) then u can allocate the lower level signals in it by making
the higher bits of label as 0s (i.e. S and U}. This is fine for the same

technology. What about the case where the TDM LSP has to be tunneled
through 
the Lambda LSP ? What will be the form of label (i.e. {SUKLM} or lambda

etc.) ?

Regards,
manoj.

>From: Maarten Vissers <[email-masked]>
>To: manoj juneja <[email-masked]>
>CC: [email-masked]
>Subject: Re: Lambda LSP establishment
>Date: Tue, 11 Dec 2001 15:56:41 +0100
>
>Manoj,
>
>You refer to one wavelength to be available between A-E without
wavelength
>conversion capability. This suggests that you operate at the OCh layer 
>network.
>Then you specify the capacity of the 4 OCh link connections (A-B, B-C,
C-D, 
>D-E)
>to be "C". Say that C is about 10 Gbit/s. You then assume that there is
a
>request for an OCh signal with capacity C/4 (e.g. 2.5 Gbit/s) between C
and 
>E.
>The result is that the OCh link connections C-D and D-E are
transporting 
>the OCh
>signal (of e.g. 2.5G). These OCh link connections are now in service
and 
>not
>longer available to an other OCh connection request. I.e. a request for
an 
>OCh
>connection between A and E will be rejected.
>
>FAs are not applicable in the circuit layers. IF there is a trail in
server
>layer X, then there is a link in its client layer Y. X and Y are thus 
>different
>layer networks and signals.
>
>If C-E is a "FA", then in an OTN the C-E connection would be an OCh
trail
>supporting an ODUk (k=1 if OCh is 2G5) link with a single link
connection.
>
>Note a FA in MPLS creates essentially a MPLS sublayer network. Such is
not
>possible in the SDH/SONET, OTN, PDH or ATM technologies.
>
>Regards,
>
>Maarten
>
>OCh link connections
>
>manoj juneja wrote:
> >
> > Hi All,
> >         If I have 5 nodes A, B, C, D and E connected as shown.
Assume
> > that only one wavelength is available on the path A to E (no
wavelength
> > conversion capability is there on the complete path). Let the
capacity
> > of the wavelength be C. Further assume a request arrives for
connection
> > from node C to E for a line capacity of C/4. This request will be
> > successful as we have available wavelength. Now If another request
> > comes at node A to establish another connection from node A to node
E
> > via nodes {A,B,C,D,E} for a line capacity of C/4. Should this
request
> > be successful as we have already allocated the wavelength ?
> >
> > If the previous connection from C to E of capacity C/4 had been
> > advertised as a FA, in that case will the IInd request succeed ?
> >
> > If the previous connection from C to E of capacity C/4 had not been
> > advertised as FA then what will be the fate of IInd connection ?
> >
> >        A <--> B <---> C <----> D <---> <----> E
> >
> > Regards,
> > manoj.
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at 
>http://explorer.msn.com/intl.asp
><< mvissers.vcf >>

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

Delivery-date: Tue, 11 Dec 2001 16:25:16 -0800
From: "Mannie, Eric" <[email-masked]>
To: 'Stephen Trowbridge ' <[email-masked]>, "'David S. Miller '" <[email-masked]>
Cc: ''Dimitri Papadimitriou' ' <[email-masked]>,  'Steve West ' <[email-masked]>, ''Maarten Vissers' ' <[email-masked]>, 'ccamp ' <[email-masked]>, 'q11/15 ' <[email-masked]>, "'t1x1.5 '" <[email-masked]>
Subject: RE: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
Date: Wed, 12 Dec 2001 01:20:35 +0100

Hi all,

>LBM also does not accomodate removal of non-contiguous components:
e.g., if the 3rd of 10 concatenated VCs fail, I suppose you need
to back down to 2 and then build up ...

Not totally correct, if they are multiple LSPs used for the circuit, you can
remove/add VCs at the end of each LSP separately. However, since each LSP is
protected independently, if "any VC fails" inside, the whole LSP is
protected (so in that case the problem is a not relevant). If you want to
have completely separate VCs, you can have one LSP for each VC. Each LSP/VC
is then provisioned end-to-end, protected (if required) and can be routed
independently. The capability is the same as in LCAS in that case.

Kind regards,

Eric

-----Original Message-----
From: Stephen Trowbridge
To: David S. Miller
Cc: Mannie, Eric; 'Dimitri Papadimitriou'; Steve West; 'Maarten Vissers';
ccamp; q11/15; t1x1.5
Sent: 12/11/01 1:52 AM
Subject: Re: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt

David,
Virtual Concatenation, with or without LCAS accomodates differential
delay for different parts of the payload.

LCAS provides hitless add/remove. Also it provides for removal of
failed components, even when this results in non-contiguous
component numbering.

LBM does not give you hitless add and remove from the payload.
LBM also does not accomodate removal of non-contiguous components:
e.g., if the 3rd of 10 concatenated VCs fail, I suppose you need
to back down to 2 and then build up ...
Steve

"David S. Miller" wrote:
> 
> Am I missing something?
> 
> I thought that LCAS gains 2 things:
> 1) Hitless and and remove of payload (dynamic bandwidth allocation)
> but more importantly
> 2) Differential Delay through the network for differents parts of the
> payload (i.e. diverse routing of network traffic).
> 
> How does GMPLS w/ LBM address the second issue?
> 
> David Miller
> Vitesse Semiconductor
> 
> "Mannie, Eric" wrote:
> >
> > Hello Steve,
> >
> > Just to complement the answer of Dimitri,
> >
> > > You believe that the packet loss rate and robustness of LMB is
> > > similar to LCAS ?
> >
> > LCAS waits for the end of control packet which is multi-framed to
decide
> > when the payload is significant (the "transition"). LBM uses for
instance
> > the C2 byte for the HOVC, since this byte appears directly in the
POH and is
> > not part of a control packet, that should go faster, right ? I.e.
less
> > glitch than with LCAS ?
> >
> > But having a field in the transport plane to indicate a transition
(whatever
> > is the field ) is not the most important issue. Even if you have
that field,
> > you need some time to provision the additional VCs/SPEs in the
network. This
> > is not done by LCAS, and any control plane or management plane will
imply
> > some time for that operation, and the glitch will really come from
that
> > process, not from the way that you detect a transition in the
transport
> > plane.
> >
> > > 4.  LBM is an extension to GMPLS.  GMPLS is required for LBM,
whereas LCAS
> > > could potentially be used with GMPLS or with other control plane
or
> > > management plane mechanisms ?
> >
> > When a distributed control plane is used (e.g. GMPLS or PNNI), using
LCAS
> > implies issues on this control plane. LCAS is a stand-alone solution
that
> > bypass the control plane to change the resource reservation in both
end
> > systems. A control plane maintains states in end systems (e.g. at
the UNI)
> > and in intermediate systems ! So, bandwidth modifications must be
reflected
> > in the control plane otherwise it will become inconsistent.
> >
> > Now, the control plane is natively designed to deal with these
resource
> > reservations including in the source and the destination (with the
UNI).
> > Moreover, GMPLS is natively designed to deal with bandwidth
modification (in
> > the packet world this was one of the major requirements).
Originally, we
> > just wanted to describe how to generalize these bandwidth
modification
> > principles to SDH/SONET and how to interwork with LCAS.
> >
> > Then, we saw that a large part of LCAS was overlapping with GMPLS,
i.e. all
> > the protocol part. The rest was the issue about when to decide that
a VC/SPE
> > contains real user data or not (the transition).
> >
> > Since LCAS added a control message, naturally it used a field in
that
> > control message to indicate that transition. But with GMPLS we
didn't need
> > any new control message, se we looked at what was available *in the
> > transport plane* to detect the fact that a VC/SPE contains now real
user
> > data (i.e the transition). We found natural to use the so-called
SDH/SONET
> > "signal label" (e.g. the C2 byte) (note for the readers: nothing to
do with
> > the GMPLS label :-). So we added these aspects to the draft. This is
the
> > part that we expected to validate with the ITU-T/T1X1 folks, but
flames came
> > first...
> >
> > What we are certainly going to do, is to add in the draft a section
about
> > how GMPLS should work when LCAS is used at the same time. However,
we think
> > that using GMPLS and LCAS at the same time will be more complex than
simply
> > using GMPLS and will not bring something additional. So the natural
> > observation came, "why should we use LCAS with GMPLS and build
something
> > more complex when there is almost no issue to solve when simply
using GMPLS
> > alone". Using GMPLS and LCAS at the same time to modify the
bandwidth
> > implies that we will have two signaling flows between the source and
the
> > destination running in parallel and overlapping. GMPLS will also
speak with
> > the source and the destination to do the same as LCAS, and with a
> > distributed control plane you need GMPLS anyway (or PNNI or etc).
> >
> > We also added a section to explain how several GMPLS LSPs (i.e.
circuits)
> > can be combined together to form a larger virtually concatenated
circuit.
> > This allows to deal with the non co-routing of VCs/SPEs with GMPLS.
> >
> > Kind regards,
> >
> > Eric
> >
> > -----Original Message-----
> > From: Dimitri Papadimitriou
[mailto:[email-masked]]
> > Sent: Sunday, November 18, 2001 3:44 PM
> > To: Steve West
> > Cc: Mannie, Eric; 'Stephen Trowbridge'; 'Maarten Vissers'; ccamp;
> > q11/15; t1x1.5
> > Subject: Re: [T1X1.5] Re: LCAS and
> > draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
> >
> > Hi Steve,
> >
> > Thanks for your comments, see in-line...
> >
> > Steve West wrote:
> > >
> > > Dimitri:
> > >
> > > Please confirm my understanding of your proposal:
> > >
> > > 1.  Your proposal supports hitless link capacity adjustment.
(Capacity
> > > changes that occurs during transmission of a packet will not
corrupt that
> > > packet.)  You believe that the packet loss rate and robustness of
LMB is
> > > similar to LCAS ?
> >
> > It is mentioned in the proposal that the source waits for a
> > confirmation from the destination (i.e. Resv Message). THEN
> > the source "equip" the VC/SPE and sends. After the destination
> > sees in the POH that the VC is "equipped" (transition).
> >
> > So instead of using the transitions proposed in LCAS (based
> > on the H4 CTRL words) we use the ones already available.
> >
> > Since we are the beginning, we were very cautious but we expect to
> > reach more than reasonable robustness and reliability.
> >
> > > 2.  LMB requires hardware coordination between the SONET payload
mapper
> > and
> > > the SONET POH processor (C2 octet insertion/extraction logic) ?
> >
> > At the transport plane level C2 is the field that LBM uses for the
> > transition in the HOVC POH.
> >
> > > 3.  The hardware based synchronization performance requirements
are
> > similar
> > > to those required by LCAS.  Except that LCAS coordinates the
critical
> > > transitions using H4 instead of C2 ?  And that Virtual
Concatenation
> > systems
> > > require to coordinate their payload mappers with bits 1-4 of the
H4 byte
> > to
> > > determine the sequence number anyway ?
> >
> > See above, yes and yes (since we re-use existing VC mechanisms)
> >
> > > 4.  LBM is an extension to GMPLS.  GMPLS is required for LBM,
whereas LCAS
> > > could potentially be used with GMPLS or with other control plane
or
> > > management plane mechanisms ?
> >
> > The scope of this proposal is to use GMPLS-LBM without LCAS. In fact
> > (from what i understand in your question) see it more from transport
> > to control plane impact taking the assumption that you expect some
> > hardware improvement. Let's first determine if this can be achieved
> > and then discuss the implementation issues that can arise from this
> > proposal. In a sense, GMPLS-LBM is a self-consistent solution.
> >
> > Regards,
> > - dimitri.
> >
> > > Thanks,
> > >
> > > Steve
> > >
> > > -----Original Message-----
> > > From: Dimitri Papadimitriou
[mailto:[email-masked]]
> > > Sent: Friday, November 16, 2001 4:09 PM
> > > To: Mannie, Eric; 'Stephen Trowbridge'; 'Maarten Vissers'
> > > Cc: ccamp; q11/15; t1x1.5
> > > Subject: [T1X1.5] Re: LCAS and
draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
> > >
> > > Hi folks,
> > >
> > > What happens... when we start the technical discussion
> > > all guys taking part to the previous one now are gone ?
> > >
> > > We would like to start a technical discussion.. rather
> > > difficult if we stay alone... or everybody agree on
> > > proposal made in the previous e-mail ? (this in order
> > > to refine the mechanism detailed in the GMPLS LBM I-D.)
> > >
> > > Any technical feedback is highly appreciated.
> > >
> > > Cheers,
> > > - dimitri.
> > >
> > > "Mannie, Eric" wrote:
> > > >
> > > > Hello Stephen
> > > >
> > > > > GMPLS-LBM and LCAS ARE solutions to different problems.
> > > >
> > > > No, please see explanations below.
> > > >
> > > > > If you use LBM and change the mappings at the two ends without
some
> > > > coordination such as LCAS, you will have a glitch to the traffic
> > > > (I think this is simple enough).
> > > >
> > > > No, please see below (C2 or V5 transition).
> > > >
> > > > >The compare/contrast discussion of LBM and LCAS is appropriate
not
> > > > >because LCAS is "sacred", but because you are comparing apples
to
> > > > >oranges. Statements in this document such as "One drawback of
LCAS is
> > .."
> > > > >are unnecessary and inappropriate in this context, since LBM
does
> > > > >NOT solve the problem LCAS was designed to solve. Perhaps if
you
> > > > >were solving the SAME problem better, this would be OK, but
this
> > > > >is not the case.
> > > >
> > > > No, please see below.
> > > >
> > > > Simple example:
> > > >
> > > > 1) you first signal an additional VC/SPE to the destination (via
a
> > Path).
> > > > 2) the destination knows exactly which VC/SPE is added (via the
label).
> > > > 3) the new VC is unequipped (indicated in POH C2 (for HOVC)),
> > > >    so the VC/SPE is not yet added to concatenated signal.
> > > > 4) then, you wait at the source for a confirmation from the
destination
> > > > (i.e. Resv).
> > > > 5) the source "equip" the VC/SPE and sends.
> > > > 6) the destination sees in the POH that the VC is "equipped"
> > (transition).
> > > >
> > > > The difference between LCAS and LBM is that LCAS uses an
additional
> > > explicit
> > > > indication in the overhead to say "this is the payload" to use.
LBM
> > > doesn't
> > > > change the SDH/SONET overhead, while LCAS changes the SDH/SONET
overhead
> > >:-)
> > > >
> > > > LCAS uses a new field in the POH (CTRL) to know when the new VC
> > > transitions
> > > > to a significant payload. LBM proposes to do the same simply by
looking
> > at
> > > > the C2 (for HOVC) transition - regular SDH/SONET field that will
change
> > > > anyway and that is used to indicate the type of payload.
> > > >
> > > > To be more precise about LCAS (I copy from the LCAS
specification,
> > section
> > > > 6.3.1): "The first container frame to contain payload data for
the new
> > > > member shall be the container frame immediately following the
container
> > > > frame that contained the last bit(s) (i.e. the CRC) of the
control
> > packet
> > > > with NORM/EOS message for that member" (the LCAS control
packet).
> > > >
> > > > So, LCAS waits for the last bit of the appropriate LCAS control
packet
> > in
> > > > the POH with the appropriate transition of its CTRL field. LBM
waits
> > > simply
> > > > for the appropriate C2 (for HOVC) or V5 (for LOVC) transition in
the POH
> > > > (don't change SDH/SONET).
> > > >
> > > > By the way, this is version 0 of the draft and it was just
posted.
> > > >
> > > > Suggestions, technical comments and improvements are welcome.
> > > >
> > > > I would appreciate if people could first read and speak before
shooting
> > > > directly :-)
> > > >
> > > > Kind regards,
> > > >
> > > > Eric
> > > >
> > > > -----Original Message-----
> > > > From: Stephen Trowbridge [mailto:[email-masked]]
> > > > Sent: Friday, November 16, 2001 7:49 PM
> > > > To: Mannie, Eric
> > > > Cc: 'Maarten Vissers'; ccamp; q11/15; t1x1.5; Dimitri
Papadimitriou
> > > > Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
> > > >
> > > > Eric,
> > > > The point of my earlier email (items again below, this time with
> > > > numbers) was not to prompt the comment "#3 is out of scope,
therefore
> > > > it is a choice between #1 and #2" (my parsing of recent
statements).
> > > >
> > > > The issue (and I think the reason for Maarten's strong reaction)
is
> > this:
> > > > GMPLS-LBM and LCAS are NOT different solutions to the same
problem.
> > > > GMPLS-LBM and LCAS ARE solutions to different problems.
> > > > (I hope this is not too subtle for non-native English speakers).
> > > >
> > > > LCAS is a method to hitlessly change the mappings at the two
> > > > ends of a virtually concatenated trail to increase or decrease
the
> > > > bandwidth. It does not say anything about how components to be
> > > > added or removed from the virtually concatenated "bundle" are
> > > > set up or taken down.
> > > >
> > > > LBM talks about how to set up or take down those added or
removed
> > > > components, but not about the details of changing the mapping
(other
> > > > than that it is done after the new components are successfully
> > > > established.
> > > >
> > > > If you use LBM and change the mappings at the two ends without
some
> > > > coordination such as LCAS, you will have a glitch to the traffic
> > > > (I think this is simple enough).
> > > >
> > > > The compare/contrast discussion of LBM and LCAS is appropriate
not
> > > > because LCAS is "sacred", but because you are comparing apples
to
> > > > oranges. Statements in this document such as "One drawback of
LCAS is
> > .."
> > > > are unnecessary and inappropriate in this context, since LBM
does
> > > > NOT solve the problem LCAS was designed to solve. Perhaps if you
> > > > were solving the SAME problem better, this would be OK, but this
> > > > is not the case.
> > > >
> > > > Time to try to be constructive:
> > > > - I think most of the current discussion of LCAS should be
removed from
> > > > this document. It is irrelevant since LCAS solves a different
problem
> > than
> > > > LBM. To say that one is "better" than the other would only be
meaningful
> > > > if they were solving the same problem (can you really say that
LBM
> > solves
> > > > problem A better than LCAS solves problem B?).
> > > > - LCAS can be a good informative reference as a way to hitlessly
modify
> > > > the size of a virtually concatenated trail.
> > > > - Clarify in the scope that the current draft describes the use
of LBM
> > > > without LCAS, which results in a traffic glitch when bandwidth
is
> > > modified.
> > > > Indicate that the use of LCAS to hitlessly negotiate the changes
to
> > > > the size of virtually concatenated pipes after LBM sets up new
> > > component(s)
> > > > or before LBM takes down old component(s) is a topic for further
study
> > > > and perhaps to be addressed in a future version of the draft.
> > > >
> > > > Regards,
> > > > Steve
> > > >
> > > > Steve Trowbridge wrote:
> > > > > 1. Can you use LBM without LCAS? Yes, if you don't mind a
glitch to
> > > > > the traffic.
> > > > >
> > > > > 2. Can you use LCAS without LBM? Yes, if you don't care
whether the
> > > > > control plane knows that the different LSPs are part of the
same
> > > > > circuit.
> > > > >
> > > > > 3. Can you use LCAS WITH LBM? Hopefully yes, and this would
seem to
> > > > > be the preferred method for many applications.
> > > >
> > > > "Mannie, Eric" wrote:
> > > > >
> > > > > Hello Maarten,
> > > > >
> > > > > >Any sentence in which LCAS and ASON/GMPLS are compared shows
a lack
> > of
> > > > > >understanding of LCAS's objective (my very strong opinion).
> > > > >
> > > > > Sorry, do you mean that it is forbidden to speak about your
LCAS
> > > document
> > > > > and to compare GMPLS and LCAS functionalities ?
> > > > >
> > > > <snip, to save BW>

Delivery-date: Tue, 11 Dec 2001 15:28:27 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Lambda LSP establishment
Date: Tue, 11 Dec 2001 16:27:30 -0700

Hi Marteen,
            The concept of FA is mentioned for SDH/SONET in gmpls-sdh
-sonet draft. It says that if u have a HOVC trail as a FA (advertized
as a link) then u can allocate the lower level signals in it by making
the higher bits of label as 0s (i.e. S and U}. This is fine for the same 
technology. What about the case where the TDM LSP has to be tunneled through 
the Lambda LSP ? What will be the form of label (i.e. {SUKLM} or lambda  
etc.) ?

Regards,
manoj.

>From: Maarten Vissers <[email-masked]>
>To: manoj juneja <[email-masked]>
>CC: [email-masked]
>Subject: Re: Lambda LSP establishment
>Date: Tue, 11 Dec 2001 15:56:41 +0100
>
>Manoj,
>
>You refer to one wavelength to be available between A-E without wavelength
>conversion capability. This suggests that you operate at the OCh layer 
>network.
>Then you specify the capacity of the 4 OCh link connections (A-B, B-C, C-D, 
>D-E)
>to be "C". Say that C is about 10 Gbit/s. You then assume that there is a
>request for an OCh signal with capacity C/4 (e.g. 2.5 Gbit/s) between C and 
>E.
>The result is that the OCh link connections C-D and D-E are transporting 
>the OCh
>signal (of e.g. 2.5G). These OCh link connections are now in service and 
>not
>longer available to an other OCh connection request. I.e. a request for an 
>OCh
>connection between A and E will be rejected.
>
>FAs are not applicable in the circuit layers. IF there is a trail in server
>layer X, then there is a link in its client layer Y. X and Y are thus 
>different
>layer networks and signals.
>
>If C-E is a "FA", then in an OTN the C-E connection would be an OCh trail
>supporting an ODUk (k=1 if OCh is 2G5) link with a single link connection.
>
>Note a FA in MPLS creates essentially a MPLS sublayer network. Such is not
>possible in the SDH/SONET, OTN, PDH or ATM technologies.
>
>Regards,
>
>Maarten
>
>OCh link connections
>
>manoj juneja wrote:
> >
> > Hi All,
> >         If I have 5 nodes A, B, C, D and E connected as shown. Assume
> > that only one wavelength is available on the path A to E (no wavelength
> > conversion capability is there on the complete path). Let the capacity
> > of the wavelength be C. Further assume a request arrives for connection
> > from node C to E for a line capacity of C/4. This request will be
> > successful as we have available wavelength. Now If another request
> > comes at node A to establish another connection from node A to node E
> > via nodes {A,B,C,D,E} for a line capacity of C/4. Should this request
> > be successful as we have already allocated the wavelength ?
> >
> > If the previous connection from C to E of capacity C/4 had been
> > advertised as a FA, in that case will the IInd request succeed ?
> >
> > If the previous connection from C to E of capacity C/4 had not been
> > advertised as FA then what will be the fate of IInd connection ?
> >
> >        A <--> B <---> C <----> D <---> <----> E
> >
> > Regards,
> > manoj.
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at 
>http://explorer.msn.com/intl.asp
><< mvissers.vcf >>

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

Delivery-date: Tue, 11 Dec 2001 15:18:31 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Comments on GMPLS signalling drafts 
Date: Tue, 11 Dec 2001 16:15:10 -0700

Hi All,

1. SE-style supported by GMPLS or not ?
As labels are the resources on the link, one can't allocate different
label to different senders in the same RSVP session.

2. Bandwidth modification for TDM, LSC and FSC LSPs. There is a
separate draft for TDM LSP bandwidth modification but what about the
bandwidth modification for other types of LSPs ? There is no mention of
these in any of the GMPLS drafts.

3. It should be mentioned clearly that waveband section is still not
complete in the drafts.

4. For IF_ID_RSVP_HOP object, there are couple of TLVs defined. What
about the Component_If_Id_Downstream/Upstream TLV ? The revised
bundling draft has removed these 2 TLVs. What about the GMPLS signalling
drafts ?

5. STM-0 label representation using {SUKLM} should be mentioned in the
drafts (because it is a special case).

6. It should be mentioned that bandwidth encoding parameter is useful
for what all type of LSPs i.e. TDM, LSC, FSC, PSC etc.

7. There is an example scenario for contention resolution in case of bi-
directional LSPs. It should be mentioned that  :

"contention resolution is an optimization, not a correctness issue ...
and no procedure can provide optimal resolution in all cases. An implementor 
may do differently to provide better resolution."

The above quotes are extracted from one of the mails from Fong Liaw.

If this is the case then this should be mentioned in the drafts.

8. The LSP hierarchy concept is still not clear. Some days back I posted one 
doubt related to tunneling of TDM LSP over Lambda LSP using the concept of 
forwarding adjacency and different people replied with different thoughts. 
Does this mean this concept is not standardized in GMPLS ?
My question was :

"If there are 4 nodes say A, B, C and D. There is a Lambda FA
established from A to D and if a new TDM LSP request comes to node A
which is to be tunneled through the already established lambda FA-LSP
then the node A sends the Path/label request message directly to node
D. What label the node D will send back to node A in the RESV/label
mapping message since the FA-LSP is just one label (lambda) ? Does it
mean that all the LSPs which are tunneled through the lambda FA-LSP
will be allocated the same label by node D to node A ? If this type of
scenario can't exist in GMPLS then please let me know that too."

Regards,
manoj.

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

Delivery-date: Tue, 11 Dec 2001 12:13:02 -0800
From: John Drake <[email-masked]>
To: Zhi-Wei Lin <[email-masked]>
Cc: Ben Mack-Crane <[email-masked]>, Lou Berger <[email-masked]>, Kireeti Kompella <[email-masked]>,  [email-masked]
Subject: RE: Moving right along ... generalized-signaling-06
Date: Tue, 11 Dec 2001 12:09:14 -0800

As I understand it, discussion is closed.  But to answer your questions:

1) No, it's a policy decision at the intermediate node.

2) No, revertive behavior is a policy decision at the LSP endpoints

3) No, path protection is a policy decision at the LSP endpoints

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Tuesday, December 11, 2001 8:37 AM
To: John Drake
Cc: Ben Mack-Crane; Lou Berger; Kireeti Kompella; [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

Hi,

To further the discussion, would it be possible to add a new flag for 
purpose of identifying whether or not a connection (secondary 
connection) can support extra traffic. A 1:1 connection should be able 
to support extra traffic (if secondary is not used) while a 1+1 would 
not support extra traffic.

Also, we may want to add a flag for whether or not a protection is 
revertive.

Also, current "link flags" is assumed to provide link protection. Maybe 
we can add a new flag for either "link" or "path" protection.

So the total is three new flags using 3 bits, out of the current 25 
reserved bits.

What do you think?
Zhi

John Drake wrote:

> Snipped
> 
> -----Original Message-----
> From: Ben Mack-Crane [mailto:[email-masked]]
> Sent: Tuesday, December 11, 2001 6:38 AM
> To: Lou Berger
> Cc: Kireeti Kompella; [email-masked]
> Subject: Re: Moving right along ... generalized-signaling-06
> 
> 
> 
>>>7) In Protection Information it states "The resources allocated for a
>>>   secondary LSP MAY be used by other LSPs until the primary LSP fails
>>>   over to the secondary LSP."  This may not always be the case.  An
>>>   explicit flag indicating whether or not extra traffic may use the
>>>   secondary path resources is needed.
>>>
>>??? This is the purpose of this bit.
>>
> 
> This is not clear from the definition.  The bit is defined as indicating
> the LSP is a secondary (or protecting) LSP and in 1+1 protection the
> secondary LSP may not be used for extra traffic.
> 
> Perhaps the problem here is that protection features are being defined
> before the protection framework and requirements are done.  Is this
> presupposing some particular outcome of the recovery work in CAMP?
> 
> JD:  I think the definition of the bit is fine.  For both 1+1 and 1:1
> protection, there would be a pair of Primary LSPs between the source
> and destination, rather than a Primary and a Secondary.
> 
> 

Delivery-date: Tue, 11 Dec 2001 11:36:40 -0800
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: Moving right along ... generalized-rsvp-te-05
Date: Tue, 11 Dec 2001 19:31:43 -0000

Hello Ben......you asked a specific question 11 December 2001 14:38
<snipped> 
> > >7) The Notify message is intended to "enable expedited 
> notification of
> > >    failures," but it relies on the IP layer which may be 
> affected by the
> > >    failure that the Notify is reporting.  This could 
> defeat the goal
> > >    of rapid notification.  Without some means of 
> guaranteeing the Notify
> > >    doesn't have to wait for IP routing convergence to be 
> delivered,
> > >    it isn't a satisfactory solution.
> > >
> 
> Well?  Does anyone else have thoughts on this?
NH=> Yes, but these are not 'thoughts', this is what is required and indeed
provided on all transport networks defined by the ITU:

There must be a user-plane Forward Defect Indication (FDI) provided.  The
key reason this is required is to suppress downstream alarms......and this
includes *all* client layer network trails supported above the trail source
of the orginal defect.  Which therefore implies it must have a
server->client FDI mapping specified at the relevant adaptation points, and
note that this requirements recurses through all the layer networks
affected.  This requirement becomes increasingly important for international
(and larger than 1 management domain) trail spans....which, noting the
previous comments, may not be directly obvious to the source layer of
failure, ie in different country/operator/customer domains.

This is a well-known transport network requirement that simply has to be
provided, and I thought everyone knew this?
Note - it will not be satisfactory to assume that this function can be
provided via the control-plane (using any of the protocols supported) or
indeed via the (user-plane) OAM of any other layer network.  The reasons why
are obvious (I hope).

regards, Neil

Delivery-date: Tue, 11 Dec 2001 09:25:54 -0800
Date: Tue, 11 Dec 2001 10:20:15 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: ccamp <[email-masked]>
Subject: URLs from this morning's ITU-T Presentation in CCAMP

All,
The following are the key URLs from my slides this morning:

IESG area for incoming liaisons from other organizations:
http://www.ietf.org/IESG/liaison.html

ITU-T ftp area for information sharing with other Standards
Development Organizations. Note: This is where to download the
documents referenced in the communication statements from ITU-T.
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICATIONS/index.html

ITU-T Study Group 15 Home Page:
http://www.itu.int/ITU-T/studygroups/com15/index.html

For free download of the "Optical Transport Network and Technology
Standardization/Work Plan", follow the following link from the ITU-T
Study Group 15 home page:
Optical Transport Networks & Technologies Project description

Regards,
Steve Trowbridge

Delivery-date: Tue, 11 Dec 2001 08:36:53 -0800
Date: Tue, 11 Dec 2001 11:36:32 -0500
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
CC: Ben Mack-Crane <[email-masked]>, Lou Berger <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

Hi,

To further the discussion, would it be possible to add a new flag for 
purpose of identifying whether or not a connection (secondary 
connection) can support extra traffic. A 1:1 connection should be able 
to support extra traffic (if secondary is not used) while a 1+1 would 
not support extra traffic.

Also, we may want to add a flag for whether or not a protection is 
revertive.

Also, current "link flags" is assumed to provide link protection. Maybe 
we can add a new flag for either "link" or "path" protection.

So the total is three new flags using 3 bits, out of the current 25 
reserved bits.

What do you think?
Zhi

John Drake wrote:

> Snipped
> 
> -----Original Message-----
> From: Ben Mack-Crane [mailto:[email-masked]]
> Sent: Tuesday, December 11, 2001 6:38 AM
> To: Lou Berger
> Cc: Kireeti Kompella; [email-masked]
> Subject: Re: Moving right along ... generalized-signaling-06
> 
> 
> 
>>>7) In Protection Information it states "The resources allocated for a
>>>   secondary LSP MAY be used by other LSPs until the primary LSP fails
>>>   over to the secondary LSP."  This may not always be the case.  An
>>>   explicit flag indicating whether or not extra traffic may use the
>>>   secondary path resources is needed.
>>>
>>??? This is the purpose of this bit.
>>
> 
> This is not clear from the definition.  The bit is defined as indicating
> the LSP is a secondary (or protecting) LSP and in 1+1 protection the
> secondary LSP may not be used for extra traffic.
> 
> Perhaps the problem here is that protection features are being defined
> before the protection framework and requirements are done.  Is this
> presupposing some particular outcome of the recovery work in CAMP?
> 
> JD:  I think the definition of the bit is fine.  For both 1+1 and 1:1
> protection, there would be a pair of Primary LSPs between the source
> and destination, rather than a Primary and a Secondary.
> 
> 

Delivery-date: Tue, 11 Dec 2001 08:15:58 -0800
Date: Tue, 11 Dec 2001 17:15:45 +0100
From: Richard Douville <[email-masked]>
Organization: Alcatel R&I - URP
To: Ben Mack-Crane <[email-masked]>
CC: Lou Berger <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

On the specific section on the waveband switching, we also agree that
further work is required to achieve a consistent definition of waveband
switching in GMPLS.
In
http://www.ietf.org/internet-drafts/draft-douville-ccamp-gmpls-waveband-extensions-00.txt
and
http://www.ietf.org/internet-drafts/draft-dotaro-ipo-multi-granularity-01.txt
, we try to address some of the issues concerning waveband switching,
notably by the introduction of a waveband switch capable interface
(WBSC). We also try to remain as compliant as possible with the current
proposition (GMPLS-SIG) for the proposed enhancements. However, we
encourage that waveband switching issues be restudied before putting it
back on the standard track.
It is clear that an in-depth analysis of the constraints and
requirements for waveband switching could leed to best suited proposals. 
What are the next step : take it off GMPLS-SIG for further work (ad hoc
design team?), other ideas ?

Regards,
Richard Douville et al.

Ben Mack-Crane wrote:
> 
> See comments below.
> 
> Regards,
> Ben
> 
> Lou Berger wrote:
> >
> > At 01:09 PM 10/29/2001, Ben Mack-Crane wrote:
> >
> > >After reviewing draft-ietf-mpls-generalized-signaling-06.txt I have
> > >a few comments and questions:
> > >
> > >1) There seems to be no difference as far as label allocation
> > >    is concerned between LSP Encoding Types Ethernet V2/DIX (2)
> > >    and Ethernet 802.3 (10).  One Encoding type would seem to
> > >    be sufficient.
> >
> > I agree, but some feel that this is needed to properly establish LSPs in
> > systems what would terminate each type differently.
> 
> I don't recall seeing anything on the list about the reasoning about this.
> can someone provide a pointer to where this was described?
> 
> Since LSP Encoding type is intended to describe the LSP for transit nodes
> and G-PID is intended to describe the LSP contents for the purpose of
> terminating it at the ends, information relevant only to termination
> should be conveyed in G-PID.
> 
> Perhaps changing the name of this LSP Encoding Type to "Ethernet Phy"
> would make this clearer.
> 
> >
> > >2) G-PID types (19), (20), and (21) are repeats of (16), (17),
> > >    and (18).
> >
> > see latest draft...
> 
> Thanks for fixing this.  The new (19) should probably be "VC-11 in TU-12."
> 
> >
> > >   Since the Siganl Type will indicate whether the
> > >    LSP is VC-11/VT1.5 or VC-12/VT2, this encoding is redundant.
> >
> > the fields serve different purposes.
> >
> > >3) G-PID type (37) Lambda seems insufficient (too vague) to
> > >    support interoperability.  Is there any practical use for this
> > >    value?
> >
> > yes, it's needed when doing fiber/port switching.
> >
> > >4) In the "Bandwidth Encoding" section it states "For non-packet LSPs, it
> > >    is useful to define discrete values to identify the bandwidth of the
> > >    LSP."  For SONET/SDH this is unnecessary given the Signal Type is
> > >    provided.  For the other non-packet LSP types (Lambda and Fiber)
> > >    it is not clear that all the values cited in the example are relevant
> > >    (for example, a DS0 lambda would seem wasteful...).
> >
> > >    This is confusing, and should be clarified.  In fact, a description of
> > >    exactly why this field is required is needed.
> >
> > We've gone over this text multiple times.  Do you have any suggested wording.
> >
> 
> I would gladly suggest wording if I understood the use for this.  It has no use
> for Packet, PDH, SDH/SONET, or "Digital Wrapper," so I assume it is for Lambda
> or Fiber.  However, several of the examples are not appropriate for this.
> Perhaps this should be moved to a technology specific document since it is
> not really general anyway.
> 
> > >5) The Waveband ID "is selected by the sender and reused in all
> > >    subsequent related messages."  This seems more the sort of thing that
> > >    should be negotiated by LMP rather than during connection setup.
> >
> > The ID has significance within signaling context of the sender. (like
> > message id). I don't think using another layer of complexity for provate
> > information makes sense.
> >
> > >6) The definition of Start Label and End Label in waveband switching seems
> > >    inconsistent with the behavior described in generalized-rsvp-te-05.
> >
> > I don't see this.  Feel free to suggest wording.
> 
> Does anyone else see an inconsistency here?  I would be interested in hearing
> from someone who understands the waveband content.
> 
> I am concerned that the waveband proposal is speculative and not ready to
> progress toward RFC status.  Perhaps the waveband content should be removed
> and the sections marked FFS.
> 
> >
> > >
> > >7) In Protection Information it states "The resources allocated for a
> > >    secondary LSP MAY be used by other LSPs until the primary LSP fails
> > >    over to the secondary LSP."  This may not always be the case.  An
> > >    explicit flag indicating whether or not extra traffic may use the
> > >    secondary path resources is needed.
> >
> > ??? This is the purpose of this bit.
> 
> This is not clear from the definition.  The bit is defined as indicating
> the LSP is a secondary (or protecting) LSP and in 1+1 protection the
> secondary LSP may not be used for extra traffic.
> 
> Perhaps the problem here is that protection features are being defined
> before the protection framework and requirements are done.  Is this
> presupposing some particular outcome of the recovery work in CAMP?
> 
> >
> > >8) The Administrative Status Information includes a bit indicating
> > >    "Administratively down," but there is no reference to a definition
> > >    of this state.  Is this intended to mirror the MIB variable?  If so,
> > >    a reference is needed.  If not, more definition is needed to ensure
> > >    the local behaviors driven by this bit are in some way consistent.
> > >    Whether this state defintion is consistent with current transport
> > >    network operations should also be considered.
> >
> > Per the document:
> >    The actions taken by a node based on a state local decision.
> >
> > >9) In Interface Identification, the IP Address for types 3,4, and 5 is
> > >    described as possibly "an IP address associated with the router ID."
> > >    Is this intended to mean the Router ID or any IP address owned by
> > >    the node?  It seems the Router ID is the simplest solution, but the
> > >    wording is not clear.
> >
> > Text has been reworded in 07. It's any IP address configured on a node.
> >
> > >10)In describing the Interface ID the statement "The special value
> > >    0xFFFFFFFF can be used to indicate the same label is to be valid
> > >    across all component links."  What is the "label" referred to in
> > >    this case?
> >
> > I'll reword in the post IETF last call rev of the document.
> >
> > Lou
> >
> > >Regards,
> > >Ben Mack-Crane

-- 
Richard Douville		[email-masked]
Alcatel Research & Innovation	Photonic Networks Unit, URP
Route de Nozay			Tel: 33-1-69.63.44.31
F-91460 Marcoussis, France.	Fax: 33-1-69.63.18.65

Delivery-date: Tue, 11 Dec 2001 07:39:23 -0800
From: John Drake <[email-masked]>
To: Ben Mack-Crane <[email-masked]>, Lou Berger <[email-masked]>
Cc: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: Moving right along ... generalized-signaling-06
Date: Tue, 11 Dec 2001 07:35:05 -0800

Snipped

-----Original Message-----
From: Ben Mack-Crane [mailto:[email-masked]]
Sent: Tuesday, December 11, 2001 6:38 AM
To: Lou Berger
Cc: Kireeti Kompella; [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

> 
> >
> >7) In Protection Information it states "The resources allocated for a
> >    secondary LSP MAY be used by other LSPs until the primary LSP fails
> >    over to the secondary LSP."  This may not always be the case.  An
> >    explicit flag indicating whether or not extra traffic may use the
> >    secondary path resources is needed.
> 
> ??? This is the purpose of this bit.

This is not clear from the definition.  The bit is defined as indicating
the LSP is a secondary (or protecting) LSP and in 1+1 protection the
secondary LSP may not be used for extra traffic.

Perhaps the problem here is that protection features are being defined
before the protection framework and requirements are done.  Is this
presupposing some particular outcome of the recovery work in CAMP?

JD:  I think the definition of the bit is fine.  For both 1+1 and 1:1
protection, there would be a pair of Primary LSPs between the source
and destination, rather than a Primary and a Secondary.

Delivery-date: Tue, 11 Dec 2001 07:01:56 -0800
From: "Sven Van den Bosch" <[email-masked]>
To: [email-masked]
Subject: ccamp agenda
Date: Tue, 11 Dec 2001 15:52:54 +0100

Hi,

I regret to see that the time constraints for the ccamp agenda were so tight 
that we could not fit all proposals for multi-area TE. Surely, if a design 
team is formed, we can take all proposals into account during the 
discussion.

Sven.

_________________________________________________________________
Download MSN Explorer gratis van http://explorer.msn.nl/intl.asp

Delivery-date: Tue, 11 Dec 2001 06:57:20 -0800
Cc: [email-masked]
Date: Tue, 11 Dec 2001 15:56:41 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: manoj juneja <[email-masked]>
Original-CC: [email-masked]
Subject: Re: Lambda LSP establishment

This is a multi-part message in MIME format.
--------------0D7C41BC8C4651C4FE99D78F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Manoj,

You refer to one wavelength to be available between A-E without wavelength
conversion capability. This suggests that you operate at the OCh layer network.
Then you specify the capacity of the 4 OCh link connections (A-B, B-C, C-D, D-E)
to be "C". Say that C is about 10 Gbit/s. You then assume that there is a
request for an OCh signal with capacity C/4 (e.g. 2.5 Gbit/s) between C and E.
The result is that the OCh link connections C-D and D-E are transporting the OCh
signal (of e.g. 2.5G). These OCh link connections are now in service and not
longer available to an other OCh connection request. I.e. a request for an OCh
connection between A and E will be rejected.

FAs are not applicable in the circuit layers. IF there is a trail in server
layer X, then there is a link in its client layer Y. X and Y are thus different
layer networks and signals. 

If C-E is a "FA", then in an OTN the C-E connection would be an OCh trail
supporting an ODUk (k=1 if OCh is 2G5) link with a single link connection.

Note a FA in MPLS creates essentially a MPLS sublayer network. Such is not
possible in the SDH/SONET, OTN, PDH or ATM technologies.

Regards,

Maarten

OCh link connections

manoj juneja wrote:
> 
> Hi All,
>         If I have 5 nodes A, B, C, D and E connected as shown. Assume
> that only one wavelength is available on the path A to E (no wavelength
> conversion capability is there on the complete path). Let the capacity
> of the wavelength be C. Further assume a request arrives for connection
> from node C to E for a line capacity of C/4. This request will be
> successful as we have available wavelength. Now If another request
> comes at node A to establish another connection from node A to node E
> via nodes {A,B,C,D,E} for a line capacity of C/4. Should this request
> be successful as we have already allocated the wavelength ?
> 
> If the previous connection from C to E of capacity C/4 had been
> advertised as a FA, in that case will the IInd request succeed ?
> 
> If the previous connection from C to E of capacity C/4 had not been
> advertised as FA then what will be the fate of IInd connection ?
> 
>        A <--> B <---> C <----> D <---> <----> E
> 
> Regards,
> manoj.
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
--------------0D7C41BC8C4651C4FE99D78F
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------0D7C41BC8C4651C4FE99D78F--

Delivery-date: Tue, 11 Dec 2001 06:44:07 -0800
Date: Tue, 11 Dec 2001 08:37:51 -0600
From: Ben Mack-Crane <[email-masked]>
To: Lou Berger <[email-masked]>
CC: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... generalized-rsvp-te-05

See comments below.

Regards,
Ben

Lou Berger wrote:
> 
> At 03:08 PM 10/29/2001, Ben Mack-Crane wrote:
> 
> >After reviewing draft-ietf-mpls-generalized-rsvp-te-05.txt
> >I have the following comments and questions:
> >
> >1) In the procedures regarding the Generalized Label Request
> >    object, the statement is made that "The node may either
> >    directly support the LSP or it may use a tunnel (FA),
> >    i.e., another class of switching."
> 
> please see the routing drafts.

Will these tell me that an FA is a type of switching?  I still think
that's not accurate.

> 
> >A Tunnel (FA) is a type
> >    of link, not a class of switching.  This adds to the
> >    confusion I've noted about the need for and use of Switching
> >    Type.

Switching Type continues to be ill-defined.  I have heard that the real
definition is different from that given in the current drafts.  If the 
signaling information is not clearly defined and it's use described, we
can hardly expect interoperability.

> 
> >2) Bandwidth Encoding use of the Intserv Tspec object seems
> >    quite unusual since this use is not consistent with existing
> >    uses of this object, and new uses could easily use a new
> >    C-Type.
> 
> I think either approach work.  This topic was discussed by the authors at
> least 12-18 months. The current approach was decided then.

It was discussed and rejected for TDM.  At least we should clarify the
applicability for this use of the Intserv Tspec.

> 
> >3) In the procedures for Generalized Label it states "If the label is
> >    unacceptable then the recipient MUST generate a ResvErr message with
> >    a "Routing problem/MPLS label allocation failure" indication."
> >    I think "Unacceptable Label Value" would be more appropriate.
> 
> okay.
> 
> >4) In the Waveband Switching section it says "For compatibility reasons,
> >    a new RSVP C-Type (3) is assigned."  What is the compatability
> >    problem this is solving?
> 
> simply to distinguish types.  I remove the text to avoid such confusion in
> the future.
> 
> >5) In the Label Set object, why is the Label Type field 14 bits if
> >    only the low order 8 bits are used?
> 
> for CR-LDP compatibility.
> 
> >6) Some new error strings are defined, "Label Set" and "Unsupported Link
> >    Protection," but no values or placeholders are included. Where are new
> >    error values to be documented?
> 
> As part of IANA assignment.

Is this to be added to the IANA Considerations section or is it a new document?

> 
> >7) The Notify message is intended to "enable expedited notification of
> >    failures," but it relies on the IP layer which may be affected by the
> >    failure that the Notify is reporting.  This could defeat the goal
> >    of rapid notification.  Without some means of guaranteeing the Notify
> >    doesn't have to wait for IP routing convergence to be delivered,
> >    it isn't a satisfactory solution.
> >

Well?  Does anyone else have thoughts on this?

> >8) The description of the C-Type field in the Label ERO subobject suggests
> >    that this subobject contains a Label Object.  Is this the case, or does
> >    the Label ERO subobject simple contain label values, and the C-Type
> >    matches the C-Type that would be used if the same label values were
> >    included in a Label object?
> 
> per the draft:
> 
>        Label: Variable
> 
>           This field identifies the label to be used.  The format of this
>           field is identical to the one used by the Label field in
>           Generalized Label, see Section 3.2.1.
> 
> >9) In deleting an LSP from the egress, the R bit is set in the Admin Status
> >    object.  The ingress responds with a PathTear message.  Does this PathTear
> >    contain the Admin Status object or should the R bit be cleared?
> 
> It's not in the BNF, so no it's not included.
> 

So perhaps we should change 

   1.  The egress node indicates its desire for deletion by inserting
       an Admin Status Object in a Resv message and setting the Reflect (R)
       and Delete (D) bits.

to

   1.  The egress node indicates its desire for deletion by inserting
       an Admin Status Object in a Resv message and setting the
       Delete (D) bit.

> >10)The Notify message may contain a new setting of the Admin Status.
> >    Under what conditions would an intermediate or egress node change
> >    Admin Status?
> 
> It may be used at any time that a PathErr or ResvErr is generated.
> 
> >  What happens if the Notify receiver is not the ingress?
> 
> same action as would be taken if/when the corresponding message is received.
> 
> >11)In Interface Identification it says "Data channels are specified from
> >the view point
> >    of the sender of the Path message."  Is this true even for Resv messages
> >    or should it read "Data channels are specified from the viewpoint
> >    of the sender of the message."?
> 
> current text is correct.
> 
> >12)In Restart_Cap it says "Refreshing of Resv and Path state SHOULD be
> >    suppressed during this waiting period."  I assume this is refreshes
> >    toward the failed neighbor, not to all neighbors for that LSP.  True?
> 
> yes.
> 
> thanks for the comments,
> lou
> 
> >Regards,
> >Ben Mack-Crane

Delivery-date: Tue, 11 Dec 2001 06:43:58 -0800
Date: Tue, 11 Dec 2001 08:37:39 -0600
From: Ben Mack-Crane <[email-masked]>
To: Lou Berger <[email-masked]>
CC: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

See comments below.

Regards,
Ben

Lou Berger wrote:
> 
> At 01:09 PM 10/29/2001, Ben Mack-Crane wrote:
> 
> >After reviewing draft-ietf-mpls-generalized-signaling-06.txt I have
> >a few comments and questions:
> >
> >1) There seems to be no difference as far as label allocation
> >    is concerned between LSP Encoding Types Ethernet V2/DIX (2)
> >    and Ethernet 802.3 (10).  One Encoding type would seem to
> >    be sufficient.
> 
> I agree, but some feel that this is needed to properly establish LSPs in
> systems what would terminate each type differently.

I don't recall seeing anything on the list about the reasoning about this.
can someone provide a pointer to where this was described?

Since LSP Encoding type is intended to describe the LSP for transit nodes
and G-PID is intended to describe the LSP contents for the purpose of
terminating it at the ends, information relevant only to termination
should be conveyed in G-PID.

Perhaps changing the name of this LSP Encoding Type to "Ethernet Phy"
would make this clearer.

> 
> >2) G-PID types (19), (20), and (21) are repeats of (16), (17),
> >    and (18).
> 
> see latest draft...

Thanks for fixing this.  The new (19) should probably be "VC-11 in TU-12."

> 
> >   Since the Siganl Type will indicate whether the
> >    LSP is VC-11/VT1.5 or VC-12/VT2, this encoding is redundant.
> 
> the fields serve different purposes.
> 
> >3) G-PID type (37) Lambda seems insufficient (too vague) to
> >    support interoperability.  Is there any practical use for this
> >    value?
> 
> yes, it's needed when doing fiber/port switching.
> 
> >4) In the "Bandwidth Encoding" section it states "For non-packet LSPs, it
> >    is useful to define discrete values to identify the bandwidth of the
> >    LSP."  For SONET/SDH this is unnecessary given the Signal Type is
> >    provided.  For the other non-packet LSP types (Lambda and Fiber)
> >    it is not clear that all the values cited in the example are relevant
> >    (for example, a DS0 lambda would seem wasteful...).
> 
> >    This is confusing, and should be clarified.  In fact, a description of
> >    exactly why this field is required is needed.
> 
> We've gone over this text multiple times.  Do you have any suggested wording.
> 

I would gladly suggest wording if I understood the use for this.  It has no use
for Packet, PDH, SDH/SONET, or "Digital Wrapper," so I assume it is for Lambda
or Fiber.  However, several of the examples are not appropriate for this.
Perhaps this should be moved to a technology specific document since it is
not really general anyway.

> >5) The Waveband ID "is selected by the sender and reused in all
> >    subsequent related messages."  This seems more the sort of thing that
> >    should be negotiated by LMP rather than during connection setup.
> 
> The ID has significance within signaling context of the sender. (like
> message id). I don't think using another layer of complexity for provate
> information makes sense.
> 
> >6) The definition of Start Label and End Label in waveband switching seems
> >    inconsistent with the behavior described in generalized-rsvp-te-05.
> 
> I don't see this.  Feel free to suggest wording.

Does anyone else see an inconsistency here?  I would be interested in hearing
from someone who understands the waveband content.

I am concerned that the waveband proposal is speculative and not ready to
progress toward RFC status.  Perhaps the waveband content should be removed
and the sections marked FFS.

> 
> >
> >7) In Protection Information it states "The resources allocated for a
> >    secondary LSP MAY be used by other LSPs until the primary LSP fails
> >    over to the secondary LSP."  This may not always be the case.  An
> >    explicit flag indicating whether or not extra traffic may use the
> >    secondary path resources is needed.
> 
> ??? This is the purpose of this bit.

This is not clear from the definition.  The bit is defined as indicating
the LSP is a secondary (or protecting) LSP and in 1+1 protection the
secondary LSP may not be used for extra traffic.

Perhaps the problem here is that protection features are being defined
before the protection framework and requirements are done.  Is this
presupposing some particular outcome of the recovery work in CAMP?

> 
> >8) The Administrative Status Information includes a bit indicating
> >    "Administratively down," but there is no reference to a definition
> >    of this state.  Is this intended to mirror the MIB variable?  If so,
> >    a reference is needed.  If not, more definition is needed to ensure
> >    the local behaviors driven by this bit are in some way consistent.
> >    Whether this state defintion is consistent with current transport
> >    network operations should also be considered.
> 
> Per the document:
>    The actions taken by a node based on a state local decision.
> 
> >9) In Interface Identification, the IP Address for types 3,4, and 5 is
> >    described as possibly "an IP address associated with the router ID."
> >    Is this intended to mean the Router ID or any IP address owned by
> >    the node?  It seems the Router ID is the simplest solution, but the
> >    wording is not clear.
> 
> Text has been reworded in 07. It's any IP address configured on a node.
> 
> >10)In describing the Interface ID the statement "The special value
> >    0xFFFFFFFF can be used to indicate the same label is to be valid
> >    across all component links."  What is the "label" referred to in
> >    this case?
> 
> I'll reword in the post IETF last call rev of the document.
> 
> Lou
> 
> >Regards,
> >Ben Mack-Crane

Delivery-date: Tue, 11 Dec 2001 06:40:47 -0800
Cc: [email-masked]
Date: Tue, 11 Dec 2001 15:37:43 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Jonathan Lang <[email-masked]>
Original-CC: [email-masked]
Subject: Re: Fwd: LSC Interface Doubt ...

This is a multi-part message in MIME format.
--------------59EEFFCF4A7B4144BC9961AB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jonathan,

Jonathan Lang wrote:
> 
> Maarten,
>   Please see inline.
> 
> Thanks,
> Jonathan
> 
> > -----Original Message-----
> > From: Maarten Vissers [mailto:[email-masked]]
> > Sent: Friday, December 07, 2001 1:30 AM
> > To: manoj juneja
> > Cc: [email-masked]
> > Subject: Re: Fwd: LSC Interface Doubt ...
> >
> >
> > Manoj,
> >
> > Are you aware that a PXC can be operated as an ODUk switch or
> > a STM/OC-N switch in addition to an OCh switch?
> >
> > The PXC is a name for an optical fabric equipment. As fabrics are typical
> more
> > transparent than the connected line/trib ports, those latter determine the
> > switching type. E.g. a PXC connected to optical line systems including
> > transponders will not operate at wavelenght level.
> A clarification here is needed.  I agree that a PXC with integrated
> transponders can be TDM capable.  However, if the OLS is a separate piece of
> equipment (most likely not speaking GMPLS), then from a GMPLS perspective,
> the PXC is doing wavelength switching.  Granted the wavelengths actually
> being switched may all be the same wavelength (e.g., 1310), but they are
> still wavelength switched.

The allocation of functions to boxes isn't determining the functionality itself.
The addition of OLI/VBI to the OLS and PXC boxes makes the combination a true
cross connect. I can replace the set of boxes by a single box with an electrical
fabric, and would get the same functionality from the network perspective. As
such the OLS inlcuding 3R transponders makes that the PXC operates as a
STM-N/OC-N/GE switch/cross connect (case of pre-OTN), or as an ODUk switch/cross
connect (case of OTN).

Take another example of bit interleaving... most people are used to this in the
electrical domain; i.e. a parallel/serial converter circuit takes one bit of N
parallel wires and outputs these N bits on a single wire... after this action
the serial signal is these days typically converted into an optical signal... 

The alternative is to use OTDM techniques to perform the bit interleaving... the
signals on the N parallel wires are electrically interleaved into signals onto
e.g. 4 wires... the 4 resulting bit streams are then converted into the optical
signals... then the final bit interleaving uses an OTDM circuit...

As can be seen the functionality hasn't changed despite that a complete
different technology is being deployed.

To me this discussion is very helpful. It shows to me that LSC is an ambiguous
term. As the transport plane doesn't have a "lambda" layer network, I believe
that it is time to convert the  current terminology of LSC and also TDM into the
real transport layer terminology like OCh, ODUk (k=1,2,3), HOVC
(VC-3,4,4-4c,...) and LOVC (VC-3,2,12,11). If GMPLS is intended to support
connection management in the SDH and OTN networks, it should use the terminology
applicable in these networks.

> 
> > The transponders have
> > terminated the wavelengths. Such combination will switch ODUk and/or
> STM/OC-N
> > signals. For the case the line systems do not have transponders, the PXC
> > operates as true OCh (i.e. wavelength) switch.
> agreed, this is an example of 15xx wavelength switching.
> 
> >
> > Most line systems in the core network today deploy 10G wavelengths,
> whereas many
> > service signals are at 2G5 level. Therefore, the transponders in the line
> system
> > may include 4:1 TDM multiplex circuits. With future 40G wavelengths, there
> will
> > be 16:1 TDM mux circuits (case of 2G5 services) and 4:1 TDM mux circuits
> (case
> > of 10G services). Here it is more obvious that the PXC doesn't switch
> "wavelengths".
> I don't see the difference here (except higher rates) from the first
> example.  Again,
> if the PXC is speaking GMPLS, the PXC can be considered to be doing
> wavelength switching since it is switching (e.g., 1310) wavelengths
> transparently.

A wavelength is never switched. A wavelenght is the representation of a
tributary slot within a WDM signal. When the WDM signal terminates (i.e. in an
OLS) the tributary slot ceases to exist. The optical signal transported via the
trib slot is extracted and forwarded to the PXC. If there is a 3R transponder,
the optical signal is terminated in the OLS also. If there is no 3R transponder,
the optical signal is forwarded and the full capability of the PXC (i.e. to
switch optical signals) is deployed.

GMPLS or ASON isn't having any impact on the transport plane functionality of
the PXC. The PXC managed by a NMS will provide the same transport plane
functionality.

Regards,

Maarten

> 
> >
> > Therefore LSC for me is limited to true G.709 OCh switching; i.e. when no
> > transponders are present around the fabric.
> This is not the definition in GMPLS.
> 
> >
> > Regards,
> >
s> > Maarten
> >
> > manoj juneja wrote:
> > >
> > > Hi Marteen,
> > >             I refer to LSC interface as defined in GMPLS architecture
> > > document (i.e. interface which switch data based on the wavelength on
> > > which the data is received e.g. PXC or OXC which operate at the level
> > > of individual wavelength). I don't think it has any thing to do with
> > > Och (G.709).
> > >
> > > Regards,
> > > manoj.
> > >
> > > >From: Maarten Vissers <[email-masked]>
> > > >To: manoj juneja <[email-masked]>
> > > >CC: [email-masked]
> > > >Subject: Re: Fwd: LSC Interface Doubt ...
> > > >Date: Thu, 06 Dec 2001 11:42:02 +0100
> > > >
> > > >Manoj,
> > > >
> > > >I assume you refer to G.709 OCh connections when you use the term "LSC
> > > >LSP". If
> > > >so, then a bi-directional OCh link connection will use the same OCh
> > > >tributary
> > > >slot in both directions; i.e. the same wavelenght is used for go and
> return
> > > >direction.
> > > >
> > > >Regards,
> > > >
> > > >Maarten
> > > >
> > > >manoj juneja wrote:
> > > > >
> > > > > Hi All,
> > > > >         If I need to establish a bi-directional LSC LSP then do I
> > > > > need to configure the remote end wavelengths on an LSC interface ?
> > > > > Is there any case where both the upstream and downstream labels of
> an
> > > > > bi-directional LSC LSP be same ?
> > > > >
> > > > > Regards,
> > > > > manoj.
> > > > >
> > > > >
> > _________________________________________________________________
> > > > > Get your FREE download of MSN Explorer at
> > > >http://explorer.msn.com/intl.asp
> > > ><< mvissers.vcf >>
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at
> > http://explorer.msn.com/intl.asp
> >
--------------59EEFFCF4A7B4144BC9961AB
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------59EEFFCF4A7B4144BC9961AB--

Delivery-date: Tue, 11 Dec 2001 06:38:08 -0800
Cc: [email-masked], [email-masked]
Date: Tue, 11 Dec 2001 15:36:33 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: manoj juneja <[email-masked]>
Original-CC: [email-masked], [email-masked]
Subject: Re: AW: AW: VC-4-64c as forwarding adjacency

This is a multi-part message in MIME format.
--------------34D86F8B439D691F55D043D3
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Manoj,

manoj juneja wrote:
> =

> Hi Marteen,
>             I fully agree with the diagram below. There will be a ATM V=
P
> link (VC-4-64c) between nodes A and D.
> =

> Can u please elaborate more on this one :
> "ATM VP connection controllers in A and D exchange ATM VP labels to
> setup ATM VP connections"
> =

> How will the ATM VP labels be distributed between nodes A and D ? Is it=

> not with in the scope of GMPLS signalling ?

ATM control plane uses PNNI to support ATM VP and ATM VC connection manag=
ement.
But if you consider GMPLS applicable also at these layers, then there wil=
l be an
ATM specific part in GMPLS, which defined VP labels (i.e. based on VPI) a=
nd VC
labels (i.e. based on VCI). Also, AAL2 layer network (supporting voice) w=
ould
have AAL2 labels.

ATM VP connection controllers in nodes A and D would then have a relation=
ship
and pass ATM VP signalling messages.

Besides ATM (with its PNNI/Q.2931 protocol), we will see ethernet with/wi=
thout
VLANs to become part of the transport plane. Ethernet PHYs are more and m=
ore
deployed to connect to the transport plane, and as a result the transport=

equipment is extended with 10M, 100M, 1G and 10G ethernet interfaces. The=

ethernet PHY is terminated immediately after the connector and the ethern=
et
frames are buffered and then forwarded via virtual concatenated VC-n-Xv s=
ignals.
The associated VC-n-Xv trails support Ethernet links. These ethernet link=
s have
trib slots as well, and labels will therefore be present... e.g. with VLA=
N the
VLAN identifier would be the basis for the label. These labels would be
exchanged between two adjacent ethernet switches at the end of an etherne=
t link.

And of course not to forget, MPLS is expected to enter the transport netw=
ork to
support the ethernet transmission over the backbone networks... VLAN id r=
ange is
to restricted and the industry is looking at MPLS to perform the VLAN job=
 in the
backbone. In this case there will be a MPLS link supported by VC-n(-Xv), =
VC-n-Xc
and ODUk(-Xv) trails. In this case MPLS switches in nodes A and D will ex=
change
MPLS labels.
> =

> If I am misinterpreting the concept of LSP hierarchies, please let me k=
now
> that too.

GMPLS as connection management tool for SDH/SONET, OTN and pre-OTN needs =
to
recognise the layer network structure that is defined by these technologi=
es. The
LSP hierarchy terminology is not aligned with the layer networks in these=

technologies. The actual hierarchy in the SDH/SONET/(pre-)OTN transport p=
lane is

	LOVC (VC-11,VC-12,VC-2,VC-3)
	HOVC (VC-3,VC-4,VC-4-4c,VC-4-16c,VC-4-64c, VC-4-256c)
	[STM-N (STM-16, STM-64, STM-256)] =3D=3D> pre-OTN case
	ODU1
	ODU2
	ODU3
	OCh

ATM  VP, Ethernet, MPLS, IP are clients of LOVC, HOVC, ODU1, ODU2, ODU3 l=
ayers.

Regards,

Maarten
> =

> Regards,
> manoj.
> =

> >From: Maarten Vissers <[email-masked]>
> >To: manoj juneja <[email-masked]>
> >CC: [email-masked]
> >Subject: Re: AW: AW: VC-4-64c as forwarding adjacency
> >Date: Fri, 07 Dec 2001 11:00:54 +0100
> >
> >Manoj,
> >
> >When the VC-4-64c is used as "FA" it provides e.g. an ATM VP link to t=
he
> >ATM VP
> >layer network. As such, ATM VP signals are being routed via this ATM V=
P
> >link
> >supported by the VC-4-64c trail. So ATM VP labels will be used between=

> >nodes A
> >and D.
> >
> >      NE A            NE B                 NE C               NE D
> >|<---------->|<---------------->|<------------------->|<--------------=
->|
> >
> >     ||||                                                     ||||
> >ATM VP Fabric                                            ATM VP Fabric=

> >    ||||||                                                 ||||||
> >   VC-4-64c                                               VC-4-64c
> >     port                                                   port
> >      |                                                      |
> >      |                                                      |
> >      |         VC-4-64c Fabric      VC-4-64c Fabric         |
> >      |           |       ||||        ||||       |           |
> >   STM-64      STM-64    STM-256     STM-256   STM-64      STM-64
> >    port        port      port        port      port        port
> >      |           |        |           |         |           |
> >      -------------        -------------         -------------
> >
> >When the ATM equipment at A needs a 10G link with the aTM equipment at=
 D,
> >it
> >requests a regular VC-4-64c connection between A and D. As the connect=
ion
> >terminates at VC-4-64c ports automatically there is an ATM VP link cre=
ated.
> >The
> >ATM VP connection controllers in A and D exchange ATM VP labels to set=
up
> >ATM VP
> >connections.
> >
> >When the Vc-4-64c connection had to be setup, the VC-4-64c connection
> >controllers in A, B, C and D will exchange VC-4-64c labels.
> >
> >When the ATM equipment is in a user domain, the interface between node=
s A
> >and B
> >and nodes C and D are UNIs. In that case the VC-4-64c connection
> >controllers in
> >nodes A and D are replaced by VC-4-64c call controllers. Then the
> >interactions
> >are between calling/called party call controllers (in nodes A and D) a=
nd
> >network
> >call controllers, and network call controller and connection controlle=
rs in
> >nodes B and C.
> >
> >As you see there is no notion of FA needed.
> >
> >Regards,
> >
> >Maarten
> >
> >
> >manoj juneja wrote:
> > >
> > > Hi Marteen,
> > >             Agreed. VC-4-64c connection can be advertised as a FA a=
nd
> > > can carry IP/ATM or ethernet traffic.
> > >
> > > Now take the case where multiple LSPs are to be tunneled through th=
e
> > > VC-4-64c connection (FA-LSP).
> > > What about the label ? What type of label the tail end of VC-4-64c =
FA
> > > -LSP i.e. node D will pass to the node A (i.e. head end of vc-4-64c=
 FA
> > > -LSP) ?
> > > The LSP encoding and switching types are different for FA-LSP and t=
he
> > > LSP which is to be tunneled through the FA-LSP.
> > >
> > > Regards,
> > > manoj.
> > >
> > > >From: Maarten Vissers <[email-masked]>
> > > >To: "'manoj juneja'" <[email-masked]>
> > > >CC: [email-masked]
> > > >Subject: Re: AW: AW: VC-4-64c as forwarding adjacency
> > > >Date: Thu, 06 Dec 2001 12:24:32 +0100
> > > >
> > > >Manoj,
> > > >
> > > >In transport terminology I would refer to this as a VC-4-64c trail=

> > > >supporting an
> > > >IP, ATM or Ethernet link.
> > > >
> > > >Regards,
> > > >
> > > >Maarten
> > > >
> > > >Heiles Juergen wrote:
> > > > >
> > > > > Manoj,
> > > > >
> > > > > this has nothing to do with forwarding adjacency. It is a
> >restriction of
> > > >the transport plane. A VC-4 cannot be transported in a VC-4-64c. A=

> >VC-4-64c
> > > >supports IP, ATM, Ethernet as client signal, but not a VC-4 or
> > > >VC-3/2/12/11.
> > > > > So you can have a VC-4-64c forwarding adjacency for IP, ATM or
> >Ethernet
> > > >clients.
> > > > >
> > > > > Juergen
> > > > >
> > > > > > -----Urspr=FCngliche Nachricht-----
> > > > > > Von: manoj juneja [mailto:[email-masked]]
> > > > > > Gesendet: Mittwoch, 5. Dezember 2001 19:49
> > > > > > An: [email-masked]; [email-masked]
> > > > > > Betreff: Re: AW: VC-4-64c as forwarding adjacency
> > > > > >
> > > > > >
> > > > > > Hi Juergen,
> > > > > >             Does this mean the forwarding adjacency concept i=
s not
> > > > > > applicable to concatenated signals/LSPs ? I hope forwarding
> > > > > > adjacecny of
> > > > > > virtual concatenated LSP should be allowed.
> > > > > >
> > > > > > Regards,
> > > > > > manoj.
> > > > > >
> > > > > >
> > > > > > >From: "Juergen Heiles" <[email-masked]>
> > > > > > >To: "'manoj juneja'" <[email-masked]>,
> > > > > > <[email-masked]>
> > > > > > >Subject: AW: VC-4-64c as forwarding adjacency
> > > > > > >Date: Wed, 5 Dec 2001 10:19:03 +0100
> > > > > > >
> > > > > > >No, that is not possible as you cannot transport a VC-4 in a=

> > > > > > VC-4-64c. A
> > > > > > >VC-4-64c only supports dat clients like ATM, IP, Ethernet.
> > > > > > >
> > > > > > >Juergen
> > > > > > >
> > > > > > > > -----Urspr=FCngliche Nachricht-----
> > > > > > > > Von: manoj juneja [mailto:[email-masked]]
> > > > > > > > Gesendet: Dienstag, 4. Dezember 2001 23:44
> > > > > > > > An: [email-masked]
> > > > > > > > Betreff: VC-4-64c as forwarding adjacency
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi All,
> > > > > > > >          Can I tunnel a request for VC-4 LSP on VC-4-64c
> > > > > > forwarding
> > > > > > > > adjacency ? If yes, then what would be the {suklm} ?
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > manoj
> > > > > > > >
> > > > > > > >
> >_________________________________________________________________
> > > > > > > > Get your FREE download of MSN Explorer at
> > > > > > > > http://explorer.msn.com/intl.asp
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > _____________________________________________________________=
____
> > > > > > Get your FREE download of MSN Explorer at
> > > > > http://explorer.msn.com/intl.asp
> > > ><< mvissers.vcf >>
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at
> >http://explorer.msn.com/intl.asp
> ><< mvissers.vcf >>
> =

> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.=
asp
--------------34D86F8B439D691F55D043D3
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------34D86F8B439D691F55D043D3--

Envelope-to: [email-masked]
Delivery-date: Tue, 11 Dec 2001 00:57:38 -0800
Date: Tue, 11 Dec 2001 00:49:24 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: CCAMP agenda

Sorry, folks, due to a mix-up, the agenda was not published.
Here it is.  Unfortunately, I don't know who will be talking
for some of the slots; please step forward and claim yours.

Kireeti.
-------

Agenda bashing (10 min)
	blue sheets & minute takers
Status update (15 min)
Trowbridge/ITU update (10 min)
Bonica/GTTP Reqts (5 min)
Farrell/GMPLS MIBs (10 min)
	draft-ietf-ccamp-lmp-mib-00.txt
	draft-nadeau-ccamp-gmpls-label-mib-00.txt
	draft-nadeau-ccamp-gmpls-lsr-mib-00.txt
	draft-nadeau-ccamp-gmpls-tc-mib-00.txt
	draft-nadeau-ccamp-gmpls-te-mib-00.txt
Mannie/GMPLS Arch (5 min)
	draft-ietf-ccamp-gmpls-architecture-01.txt
Mannie/SONET-SDH (5 min)
	draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
	draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
Mannie/GMPLS LBM (10 min)
	draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
Papadimitriou/GMPLS for G.709 (10 min)
Lang/LMP (5 min)
Fredette/LMP-WDM (5 min)
Papadimitriou/LMP for SONET-SDH (5 min)
	draft-ansorge-ccamp-lmp-sonet-sdh-00.txt
Lee/Path Request (5 min)
	draft-lee-mpls-path-request-02.txt
Vasseur/Computation RSVP (5 min)
Farrell/Crankback (5 min)
	draft-iwata-mpls-crankback-02.txt
Lang/Recovery (5 min)
	draft-lang-ccamp-recovery-01.txt
?/Protection Restoration Signaling (5 min)
	draft-bala-protection-restoration-signaling-00.txt
?/Shared Mesh Restoration (5 min)
	draft-li-shared-mesh-restoration-01.txt
?/SRG (5 min)
	draft-many-ccamp-srg-01.txt

Status Update
1) Most (if not all) issues on the signaling drafts addressed
	Base signaling: Lou sent mail yesterday
		draft-ietf-mpls-generalized-signaling-07.txt 
		draft-ietf-mpls-generalized-rsvp-te-06.txt 
		draft-ietf-mpls-generalized-crldp-05.txt
	SONET-SDH signaling:	label issue resolved
				group signals resolved
		draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
		draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt

    Chairs' reading: we have rough consensus for IETF Last Call
    If you think there are issues that have been raised and not
    addressed, please send email to the list stating *specific*
    issue and date first raised by Tuesday Dec 18th and the
    editors will reply with their resolution.

2) Architecture document will catch up, then we'll seek consensus
    for a WG Last Call.

3) LMP Last Call done.
4) Discussions with ITU representatives; outcome: IETF will work
    on LMP-WDM for pre-OTN networks.  ITU-T will work on VBI
    architecture for OTN, at which point LMP *may* be used for OTN.

5) Routing documents lagging.  Will seek consensus for WG Last
    Call by year end.
6) MIBs under way.

7) Protection restoration work starts now
8) Single carrier, multi-area work starts now.  Multiple carrier/domain
    out of scope.
9) May form design teams for the above two tasks.

Delivery-date: Tue, 11 Dec 2001 00:41:42 -0800
Date: Tue, 11 Dec 2001 14:12:02 +0530
From: Rajaraman B <[email-masked]>
To: Lou Berger <[email-masked]>, [email-masked]
Subject: Re: Comments on RSVP-TE-06

--------------90DD5B327ED18CB6022972E2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,
    But, When the label set is received in a Path message, that incoming Label
Set is Compared(intersection-as given in the draft) against the downstream
interface's set of label. That means, Incoming Label Set is compared with set
of labels of the interface through which the Path message has come so that it
can be used later while selecting a label for GENERALIZED_LABEL object in the
corresponding Resv message which is sent through the interface the
corresponding Path message has come already.

Is it correct?

Thanks,
Rajaraman.B

Lou Berger wrote:

> At 02:15 AM 12/11/2001, Rajaraman B wrote:
> >Hi,
> >     In the rsvp-te-06 draft, it has been written that "On reception of a
> > Path message, the Label Set represented in the message is compared
> > against the set of available labels at the downstream interface and the
> > resulting intersecting Label Set is forwarded in a Path message.".
> >
> >My doubts are,
> >1. Whether Downstream interface is with respect to Control Flow direction
> >(direction of the Path message - Initiator to Terminator) or with respect
> >to Data Flow direction (Terminator to Initiator - that is, direction of
> >LSP path from Terminator to Initiator in the case of bidirectional LSP set
> >up using UPSTREAM_LABEL)
>
> upstream (as always) = towards sender of path message
>
> >2. if the terminalogy "upstream and downstream" is with respect to Control
> >Message flow direction, then whether Label Set object is used to restrict
> >the Label Range for establishing upstream LSP(from Terminator to
> >Initiator) path using UPSTREAM_LABEL or only for downstream LSP(Initiator
> >to Terminator) path using GENERALIZED_LABEL or Both (for upstream LSP and
> >downstream LSP)
>
> generalized label.  upstream label is selected by the upstream node, so
> such restriction makes no sense.
>
> Lou
>
> >Thanks,
> >Rajaraman. B
> >

--------------90DD5B327ED18CB6022972E2
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi,
<br>&nbsp;&nbsp;&nbsp; But, When the label set is received in a Path message,
that incoming Label Set is Compared(intersection-as given in the draft)
against the downstream interface's set of label. That means, Incoming Label
Set is compared with <b>set of labels of the interface through which the
Path message has come </b>so that it can be used later while selecting
a label for GENERALIZED_LABEL object in the corresponding Resv message
which is sent through the interface the corresponding Path message has
come already.
<p>Is it correct?
<p>Thanks,
<br>Rajaraman.B
<p>Lou Berger wrote:
<blockquote TYPE=CITE>At 02:15 AM 12/11/2001, Rajaraman B wrote:
<br>>Hi,
<br>>&nbsp;&nbsp;&nbsp;&nbsp; In the rsvp-te-06 draft, it has been written
that "On reception of a
<br>> Path message, the Label Set represented in the message is compared
<br>> against the set of available labels at the downstream interface and
the
<br>> resulting intersecting Label Set is forwarded in a Path message.".
<br>>
<br>>My doubts are,
<br>>1. Whether Downstream interface is with respect to Control Flow direction
<br>>(direction of the Path message - Initiator to Terminator) or with
respect
<br>>to Data Flow direction (Terminator to Initiator - that is, direction
of
<br>>LSP path from Terminator to Initiator in the case of bidirectional
LSP set
<br>>up using UPSTREAM_LABEL)
<p>upstream (as always) = towards sender of path message
<p>>2. if the terminalogy "upstream and downstream" is with respect to
Control
<br>>Message flow direction, then whether Label Set object is used to restrict
<br>>the Label Range for establishing upstream LSP(from Terminator to
<br>>Initiator) path using UPSTREAM_LABEL or only for downstream LSP(Initiator
<br>>to Terminator) path using GENERALIZED_LABEL or Both (for upstream
LSP and
<br>>downstream LSP)
<p>generalized label.&nbsp; upstream label is selected by the upstream
node, so
<br>such restriction makes no sense.
<p>Lou
<p>>Thanks,
<br>>Rajaraman. B
<br>></blockquote>
</html>

--------------90DD5B327ED18CB6022972E2--

Delivery-date: Tue, 11 Dec 2001 00:05:44 -0800
Date: Tue, 11 Dec 2001 03:04:43 -0500
To: "Rajaraman B" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: Comments on RSVP-TE-06
Cc: <[email-masked]>

At 02:15 AM 12/11/2001, Rajaraman B wrote:
>Hi,
>     In the rsvp-te-06 draft, it has been written that "On reception of a 
> Path message, the Label Set represented in the message is compared 
> against the set of available labels at the downstream interface and the 
> resulting intersecting Label Set is forwarded in a Path message.".
>
>My doubts are,
>1. Whether Downstream interface is with respect to Control Flow direction 
>(direction of the Path message - Initiator to Terminator) or with respect 
>to Data Flow direction (Terminator to Initiator - that is, direction of 
>LSP path from Terminator to Initiator in the case of bidirectional LSP set 
>up using UPSTREAM_LABEL)

upstream (as always) = towards sender of path message

>2. if the terminalogy "upstream and downstream" is with respect to Control 
>Message flow direction, then whether Label Set object is used to restrict 
>the Label Range for establishing upstream LSP(from Terminator to 
>Initiator) path using UPSTREAM_LABEL or only for downstream LSP(Initiator 
>to Terminator) path using GENERALIZED_LABEL or Both (for upstream LSP and 
>downstream LSP)

generalized label.  upstream label is selected by the upstream node, so 
such restriction makes no sense.

Lou

>Thanks,
>Rajaraman. B
>

Delivery-date: Mon, 10 Dec 2001 23:14:12 -0800
Date: Tue, 11 Dec 2001 12:45:06 +0530
From: Rajaraman B <[email-masked]>
To: [email-masked]
Subject: Comments on RSVP-TE-06

--------------53080405A72C91465EF36370
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,
    In the rsvp-te-06 draft, it has been written that "On reception of a
Path message, the Label Set represented in the message is compared
against the set of available labels at the downstream interface and the
resulting intersecting Label Set is forwarded in a Path message.".

My doubts are,
1. Whether Downstream interface is with respect to Control Flow
direction (direction of the Path message - Initiator to Terminator) or
with respect to Data Flow direction (Terminator to Initiator - that is,
direction of LSP path from Terminator to Initiator in the case of
bidirectional LSP set up using UPSTREAM_LABEL)

2. if the terminalogy "upstream and downstream" is with respect to
Control Message flow direction, then whether Label Set object is used to
restrict the Label Range for establishing upstream LSP(from Terminator
to Initiator) path using UPSTREAM_LABEL or only for downstream
LSP(Initiator to Terminator) path using GENERALIZED_LABEL or Both (for
upstream LSP and downstream LSP)

Thanks,
Rajaraman. B

--------------53080405A72C91465EF36370
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi,
<br>&nbsp;&nbsp;&nbsp; In the rsvp-te-06 draft, it has been written that
<b>"On
reception of a Path message, the Label Set represented in the message is
compared against the set of available labels at the downstream interface
and the resulting intersecting Label Set is forwarded in a Path message.".</b>
<p>My doubts are,
<br>1. Whether Downstream interface is with respect to Control Flow direction
<b>(</b>direction
of the Path message - <b>Initiator to Terminator)</b> or with respect to
Data Flow direction <b>(Terminator to Initiator</b> - that is, direction
of LSP path from Terminator to Initiator in the case of bidirectional LSP
set up using UPSTREAM_LABEL<b>)</b>
<p>2. if the terminalogy <b>"upstream and downstream"</b> is with respect
to Control Message flow direction, then whether Label Set object is used
to restrict the Label Range for establishing upstream LSP<b>(</b>from Terminator
to Initiator<b>)</b> path using UPSTREAM_LABEL <b>or</b> only for downstream
LSP<b>(</b>Initiator to Terminator<b>)</b> path using GENERALIZED_LABEL

<b>or</b> Both <b>(</b>for upstream LSP and downstream LSP<b>)</b><b></b>
<p>Thanks,
<br>Rajaraman. B
<br><b></b>&nbsp;</html>

--------------53080405A72C91465EF36370--

Delivery-date: Mon, 10 Dec 2001 17:01:44 -0800
Date: Mon, 10 Dec 2001 17:52:18 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: "David S. Miller" <[email-masked]>
CC: "Mannie, Eric" <[email-masked]>, "'Dimitri Papadimitriou'" <[email-masked]>, Steve West <[email-masked]>, "'Maarten Vissers'" <[email-masked]>, ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: Re: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt

David,
Virtual Concatenation, with or without LCAS accomodates differential
delay for different parts of the payload.

LCAS provides hitless add/remove. Also it provides for removal of
failed components, even when this results in non-contiguous
component numbering.

LBM does not give you hitless add and remove from the payload.
LBM also does not accomodate removal of non-contiguous components:
e.g., if the 3rd of 10 concatenated VCs fail, I suppose you need
to back down to 2 and then build up ...
Steve

"David S. Miller" wrote:
> 
> Am I missing something?
> 
> I thought that LCAS gains 2 things:
> 1) Hitless and and remove of payload (dynamic bandwidth allocation)
> but more importantly
> 2) Differential Delay through the network for differents parts of the
> payload (i.e. diverse routing of network traffic).
> 
> How does GMPLS w/ LBM address the second issue?
> 
> David Miller
> Vitesse Semiconductor
> 
> "Mannie, Eric" wrote:
> >
> > Hello Steve,
> >
> > Just to complement the answer of Dimitri,
> >
> > > You believe that the packet loss rate and robustness of LMB is
> > > similar to LCAS ?
> >
> > LCAS waits for the end of control packet which is multi-framed to decide
> > when the payload is significant (the "transition"). LBM uses for instance
> > the C2 byte for the HOVC, since this byte appears directly in the POH and is
> > not part of a control packet, that should go faster, right ? I.e. less
> > glitch than with LCAS ?
> >
> > But having a field in the transport plane to indicate a transition (whatever
> > is the field ) is not the most important issue. Even if you have that field,
> > you need some time to provision the additional VCs/SPEs in the network. This
> > is not done by LCAS, and any control plane or management plane will imply
> > some time for that operation, and the glitch will really come from that
> > process, not from the way that you detect a transition in the transport
> > plane.
> >
> > > 4.  LBM is an extension to GMPLS.  GMPLS is required for LBM, whereas LCAS
> > > could potentially be used with GMPLS or with other control plane or
> > > management plane mechanisms ?
> >
> > When a distributed control plane is used (e.g. GMPLS or PNNI), using LCAS
> > implies issues on this control plane. LCAS is a stand-alone solution that
> > bypass the control plane to change the resource reservation in both end
> > systems. A control plane maintains states in end systems (e.g. at the UNI)
> > and in intermediate systems ! So, bandwidth modifications must be reflected
> > in the control plane otherwise it will become inconsistent.
> >
> > Now, the control plane is natively designed to deal with these resource
> > reservations including in the source and the destination (with the UNI).
> > Moreover, GMPLS is natively designed to deal with bandwidth modification (in
> > the packet world this was one of the major requirements). Originally, we
> > just wanted to describe how to generalize these bandwidth modification
> > principles to SDH/SONET and how to interwork with LCAS.
> >
> > Then, we saw that a large part of LCAS was overlapping with GMPLS, i.e. all
> > the protocol part. The rest was the issue about when to decide that a VC/SPE
> > contains real user data or not (the transition).
> >
> > Since LCAS added a control message, naturally it used a field in that
> > control message to indicate that transition. But with GMPLS we didn't need
> > any new control message, se we looked at what was available *in the
> > transport plane* to detect the fact that a VC/SPE contains now real user
> > data (i.e the transition). We found natural to use the so-called SDH/SONET
> > "signal label" (e.g. the C2 byte) (note for the readers: nothing to do with
> > the GMPLS label :-). So we added these aspects to the draft. This is the
> > part that we expected to validate with the ITU-T/T1X1 folks, but flames came
> > first...
> >
> > What we are certainly going to do, is to add in the draft a section about
> > how GMPLS should work when LCAS is used at the same time. However, we think
> > that using GMPLS and LCAS at the same time will be more complex than simply
> > using GMPLS and will not bring something additional. So the natural
> > observation came, "why should we use LCAS with GMPLS and build something
> > more complex when there is almost no issue to solve when simply using GMPLS
> > alone". Using GMPLS and LCAS at the same time to modify the bandwidth
> > implies that we will have two signaling flows between the source and the
> > destination running in parallel and overlapping. GMPLS will also speak with
> > the source and the destination to do the same as LCAS, and with a
> > distributed control plane you need GMPLS anyway (or PNNI or etc).
> >
> > We also added a section to explain how several GMPLS LSPs (i.e. circuits)
> > can be combined together to form a larger virtually concatenated circuit.
> > This allows to deal with the non co-routing of VCs/SPEs with GMPLS.
> >
> > Kind regards,
> >
> > Eric
> >
> > -----Original Message-----
> > From: Dimitri Papadimitriou [mailto:[email-masked]]
> > Sent: Sunday, November 18, 2001 3:44 PM
> > To: Steve West
> > Cc: Mannie, Eric; 'Stephen Trowbridge'; 'Maarten Vissers'; ccamp;
> > q11/15; t1x1.5
> > Subject: Re: [T1X1.5] Re: LCAS and
> > draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
> >
> > Hi Steve,
> >
> > Thanks for your comments, see in-line...
> >
> > Steve West wrote:
> > >
> > > Dimitri:
> > >
> > > Please confirm my understanding of your proposal:
> > >
> > > 1.  Your proposal supports hitless link capacity adjustment. (Capacity
> > > changes that occurs during transmission of a packet will not corrupt that
> > > packet.)  You believe that the packet loss rate and robustness of LMB is
> > > similar to LCAS ?
> >
> > It is mentioned in the proposal that the source waits for a
> > confirmation from the destination (i.e. Resv Message). THEN
> > the source "equip" the VC/SPE and sends. After the destination
> > sees in the POH that the VC is "equipped" (transition).
> >
> > So instead of using the transitions proposed in LCAS (based
> > on the H4 CTRL words) we use the ones already available.
> >
> > Since we are the beginning, we were very cautious but we expect to
> > reach more than reasonable robustness and reliability.
> >
> > > 2.  LMB requires hardware coordination between the SONET payload mapper
> > and
> > > the SONET POH processor (C2 octet insertion/extraction logic) ?
> >
> > At the transport plane level C2 is the field that LBM uses for the
> > transition in the HOVC POH.
> >
> > > 3.  The hardware based synchronization performance requirements are
> > similar
> > > to those required by LCAS.  Except that LCAS coordinates the critical
> > > transitions using H4 instead of C2 ?  And that Virtual Concatenation
> > systems
> > > require to coordinate their payload mappers with bits 1-4 of the H4 byte
> > to
> > > determine the sequence number anyway ?
> >
> > See above, yes and yes (since we re-use existing VC mechanisms)
> >
> > > 4.  LBM is an extension to GMPLS.  GMPLS is required for LBM, whereas LCAS
> > > could potentially be used with GMPLS or with other control plane or
> > > management plane mechanisms ?
> >
> > The scope of this proposal is to use GMPLS-LBM without LCAS. In fact
> > (from what i understand in your question) see it more from transport
> > to control plane impact taking the assumption that you expect some
> > hardware improvement. Let's first determine if this can be achieved
> > and then discuss the implementation issues that can arise from this
> > proposal. In a sense, GMPLS-LBM is a self-consistent solution.
> >
> > Regards,
> > - dimitri.
> >
> > > Thanks,
> > >
> > > Steve
> > >
> > > -----Original Message-----
> > > From: Dimitri Papadimitriou [mailto:[email-masked]]
> > > Sent: Friday, November 16, 2001 4:09 PM
> > > To: Mannie, Eric; 'Stephen Trowbridge'; 'Maarten Vissers'
> > > Cc: ccamp; q11/15; t1x1.5
> > > Subject: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
> > >
> > > Hi folks,
> > >
> > > What happens... when we start the technical discussion
> > > all guys taking part to the previous one now are gone ?
> > >
> > > We would like to start a technical discussion.. rather
> > > difficult if we stay alone... or everybody agree on
> > > proposal made in the previous e-mail ? (this in order
> > > to refine the mechanism detailed in the GMPLS LBM I-D.)
> > >
> > > Any technical feedback is highly appreciated.
> > >
> > > Cheers,
> > > - dimitri.
> > >
> > > "Mannie, Eric" wrote:
> > > >
> > > > Hello Stephen
> > > >
> > > > > GMPLS-LBM and LCAS ARE solutions to different problems.
> > > >
> > > > No, please see explanations below.
> > > >
> > > > > If you use LBM and change the mappings at the two ends without some
> > > > coordination such as LCAS, you will have a glitch to the traffic
> > > > (I think this is simple enough).
> > > >
> > > > No, please see below (C2 or V5 transition).
> > > >
> > > > >The compare/contrast discussion of LBM and LCAS is appropriate not
> > > > >because LCAS is "sacred", but because you are comparing apples to
> > > > >oranges. Statements in this document such as "One drawback of LCAS is
> > .."
> > > > >are unnecessary and inappropriate in this context, since LBM does
> > > > >NOT solve the problem LCAS was designed to solve. Perhaps if you
> > > > >were solving the SAME problem better, this would be OK, but this
> > > > >is not the case.
> > > >
> > > > No, please see below.
> > > >
> > > > Simple example:
> > > >
> > > > 1) you first signal an additional VC/SPE to the destination (via a
> > Path).
> > > > 2) the destination knows exactly which VC/SPE is added (via the label).
> > > > 3) the new VC is unequipped (indicated in POH C2 (for HOVC)),
> > > >    so the VC/SPE is not yet added to concatenated signal.
> > > > 4) then, you wait at the source for a confirmation from the destination
> > > > (i.e. Resv).
> > > > 5) the source "equip" the VC/SPE and sends.
> > > > 6) the destination sees in the POH that the VC is "equipped"
> > (transition).
> > > >
> > > > The difference between LCAS and LBM is that LCAS uses an additional
> > > explicit
> > > > indication in the overhead to say "this is the payload" to use. LBM
> > > doesn't
> > > > change the SDH/SONET overhead, while LCAS changes the SDH/SONET overhead
> > >:-)
> > > >
> > > > LCAS uses a new field in the POH (CTRL) to know when the new VC
> > > transitions
> > > > to a significant payload. LBM proposes to do the same simply by looking
> > at
> > > > the C2 (for HOVC) transition - regular SDH/SONET field that will change
> > > > anyway and that is used to indicate the type of payload.
> > > >
> > > > To be more precise about LCAS (I copy from the LCAS specification,
> > section
> > > > 6.3.1): "The first container frame to contain payload data for the new
> > > > member shall be the container frame immediately following the container
> > > > frame that contained the last bit(s) (i.e. the CRC) of the control
> > packet
> > > > with NORM/EOS message for that member" (the LCAS control packet).
> > > >
> > > > So, LCAS waits for the last bit of the appropriate LCAS control packet
> > in
> > > > the POH with the appropriate transition of its CTRL field. LBM waits
> > > simply
> > > > for the appropriate C2 (for HOVC) or V5 (for LOVC) transition in the POH
> > > > (don't change SDH/SONET).
> > > >
> > > > By the way, this is version 0 of the draft and it was just posted.
> > > >
> > > > Suggestions, technical comments and improvements are welcome.
> > > >
> > > > I would appreciate if people could first read and speak before shooting
> > > > directly :-)
> > > >
> > > > Kind regards,
> > > >
> > > > Eric
> > > >
> > > > -----Original Message-----
> > > > From: Stephen Trowbridge [mailto:[email-masked]]
> > > > Sent: Friday, November 16, 2001 7:49 PM
> > > > To: Mannie, Eric
> > > > Cc: 'Maarten Vissers'; ccamp; q11/15; t1x1.5; Dimitri Papadimitriou
> > > > Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
> > > >
> > > > Eric,
> > > > The point of my earlier email (items again below, this time with
> > > > numbers) was not to prompt the comment "#3 is out of scope, therefore
> > > > it is a choice between #1 and #2" (my parsing of recent statements).
> > > >
> > > > The issue (and I think the reason for Maarten's strong reaction) is
> > this:
> > > > GMPLS-LBM and LCAS are NOT different solutions to the same problem.
> > > > GMPLS-LBM and LCAS ARE solutions to different problems.
> > > > (I hope this is not too subtle for non-native English speakers).
> > > >
> > > > LCAS is a method to hitlessly change the mappings at the two
> > > > ends of a virtually concatenated trail to increase or decrease the
> > > > bandwidth. It does not say anything about how components to be
> > > > added or removed from the virtually concatenated "bundle" are
> > > > set up or taken down.
> > > >
> > > > LBM talks about how to set up or take down those added or removed
> > > > components, but not about the details of changing the mapping (other
> > > > than that it is done after the new components are successfully
> > > > established.
> > > >
> > > > If you use LBM and change the mappings at the two ends without some
> > > > coordination such as LCAS, you will have a glitch to the traffic
> > > > (I think this is simple enough).
> > > >
> > > > The compare/contrast discussion of LBM and LCAS is appropriate not
> > > > because LCAS is "sacred", but because you are comparing apples to
> > > > oranges. Statements in this document such as "One drawback of LCAS is
> > .."
> > > > are unnecessary and inappropriate in this context, since LBM does
> > > > NOT solve the problem LCAS was designed to solve. Perhaps if you
> > > > were solving the SAME problem better, this would be OK, but this
> > > > is not the case.
> > > >
> > > > Time to try to be constructive:
> > > > - I think most of the current discussion of LCAS should be removed from
> > > > this document. It is irrelevant since LCAS solves a different problem
> > than
> > > > LBM. To say that one is "better" than the other would only be meaningful
> > > > if they were solving the same problem (can you really say that LBM
> > solves
> > > > problem A better than LCAS solves problem B?).
> > > > - LCAS can be a good informative reference as a way to hitlessly modify
> > > > the size of a virtually concatenated trail.
> > > > - Clarify in the scope that the current draft describes the use of LBM
> > > > without LCAS, which results in a traffic glitch when bandwidth is
> > > modified.
> > > > Indicate that the use of LCAS to hitlessly negotiate the changes to
> > > > the size of virtually concatenated pipes after LBM sets up new
> > > component(s)
> > > > or before LBM takes down old component(s) is a topic for further study
> > > > and perhaps to be addressed in a future version of the draft.
> > > >
> > > > Regards,
> > > > Steve
> > > >
> > > > Steve Trowbridge wrote:
> > > > > 1. Can you use LBM without LCAS? Yes, if you don't mind a glitch to
> > > > > the traffic.
> > > > >
> > > > > 2. Can you use LCAS without LBM? Yes, if you don't care whether the
> > > > > control plane knows that the different LSPs are part of the same
> > > > > circuit.
> > > > >
> > > > > 3. Can you use LCAS WITH LBM? Hopefully yes, and this would seem to
> > > > > be the preferred method for many applications.
> > > >
> > > > "Mannie, Eric" wrote:
> > > > >
> > > > > Hello Maarten,
> > > > >
> > > > > >Any sentence in which LCAS and ASON/GMPLS are compared shows a lack
> > of
> > > > > >understanding of LCAS's objective (my very strong opinion).
> > > > >
> > > > > Sorry, do you mean that it is forbidden to speak about your LCAS
> > > document
> > > > > and to compare GMPLS and LCAS functionalities ?
> > > > >
> > > > <snip, to save BW>

Delivery-date: Mon, 10 Dec 2001 15:30:10 -0800
Date: Mon, 10 Dec 2001 17:01:20 -0500
From: "David S. Miller" <[email-masked]>
To: "Mannie, Eric" <[email-masked]>
CC: "'Dimitri Papadimitriou'" <[email-masked]>, Steve West <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>, "'Maarten Vissers'" <[email-masked]>, ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: Re: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt

Am I missing something?

I thought that LCAS gains 2 things:
1) Hitless and and remove of payload (dynamic bandwidth allocation)
but more importantly
2) Differential Delay through the network for differents parts of the
payload (i.e. diverse routing of network traffic).

How does GMPLS w/ LBM address the second issue?

David Miller
Vitesse Semiconductor

"Mannie, Eric" wrote:
> 
> Hello Steve,
> 
> Just to complement the answer of Dimitri,
> 
> > You believe that the packet loss rate and robustness of LMB is
> > similar to LCAS ?
> 
> LCAS waits for the end of control packet which is multi-framed to decide
> when the payload is significant (the "transition"). LBM uses for instance
> the C2 byte for the HOVC, since this byte appears directly in the POH and is
> not part of a control packet, that should go faster, right ? I.e. less
> glitch than with LCAS ?
> 
> But having a field in the transport plane to indicate a transition (whatever
> is the field ) is not the most important issue. Even if you have that field,
> you need some time to provision the additional VCs/SPEs in the network. This
> is not done by LCAS, and any control plane or management plane will imply
> some time for that operation, and the glitch will really come from that
> process, not from the way that you detect a transition in the transport
> plane.
> 
> > 4.  LBM is an extension to GMPLS.  GMPLS is required for LBM, whereas LCAS
> > could potentially be used with GMPLS or with other control plane or
> > management plane mechanisms ?
> 
> When a distributed control plane is used (e.g. GMPLS or PNNI), using LCAS
> implies issues on this control plane. LCAS is a stand-alone solution that
> bypass the control plane to change the resource reservation in both end
> systems. A control plane maintains states in end systems (e.g. at the UNI)
> and in intermediate systems ! So, bandwidth modifications must be reflected
> in the control plane otherwise it will become inconsistent.
> 
> Now, the control plane is natively designed to deal with these resource
> reservations including in the source and the destination (with the UNI).
> Moreover, GMPLS is natively designed to deal with bandwidth modification (in
> the packet world this was one of the major requirements). Originally, we
> just wanted to describe how to generalize these bandwidth modification
> principles to SDH/SONET and how to interwork with LCAS.
> 
> Then, we saw that a large part of LCAS was overlapping with GMPLS, i.e. all
> the protocol part. The rest was the issue about when to decide that a VC/SPE
> contains real user data or not (the transition).
> 
> Since LCAS added a control message, naturally it used a field in that
> control message to indicate that transition. But with GMPLS we didn't need
> any new control message, se we looked at what was available *in the
> transport plane* to detect the fact that a VC/SPE contains now real user
> data (i.e the transition). We found natural to use the so-called SDH/SONET
> "signal label" (e.g. the C2 byte) (note for the readers: nothing to do with
> the GMPLS label :-). So we added these aspects to the draft. This is the
> part that we expected to validate with the ITU-T/T1X1 folks, but flames came
> first...
> 
> What we are certainly going to do, is to add in the draft a section about
> how GMPLS should work when LCAS is used at the same time. However, we think
> that using GMPLS and LCAS at the same time will be more complex than simply
> using GMPLS and will not bring something additional. So the natural
> observation came, "why should we use LCAS with GMPLS and build something
> more complex when there is almost no issue to solve when simply using GMPLS
> alone". Using GMPLS and LCAS at the same time to modify the bandwidth
> implies that we will have two signaling flows between the source and the
> destination running in parallel and overlapping. GMPLS will also speak with
> the source and the destination to do the same as LCAS, and with a
> distributed control plane you need GMPLS anyway (or PNNI or etc).
> 
> We also added a section to explain how several GMPLS LSPs (i.e. circuits)
> can be combined together to form a larger virtually concatenated circuit.
> This allows to deal with the non co-routing of VCs/SPEs with GMPLS.
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Dimitri Papadimitriou [mailto:[email-masked]]
> Sent: Sunday, November 18, 2001 3:44 PM
> To: Steve West
> Cc: Mannie, Eric; 'Stephen Trowbridge'; 'Maarten Vissers'; ccamp;
> q11/15; t1x1.5
> Subject: Re: [T1X1.5] Re: LCAS and
> draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
> 
> Hi Steve,
> 
> Thanks for your comments, see in-line...
> 
> Steve West wrote:
> >
> > Dimitri:
> >
> > Please confirm my understanding of your proposal:
> >
> > 1.  Your proposal supports hitless link capacity adjustment. (Capacity
> > changes that occurs during transmission of a packet will not corrupt that
> > packet.)  You believe that the packet loss rate and robustness of LMB is
> > similar to LCAS ?
> 
> It is mentioned in the proposal that the source waits for a
> confirmation from the destination (i.e. Resv Message). THEN
> the source "equip" the VC/SPE and sends. After the destination
> sees in the POH that the VC is "equipped" (transition).
> 
> So instead of using the transitions proposed in LCAS (based
> on the H4 CTRL words) we use the ones already available.
> 
> Since we are the beginning, we were very cautious but we expect to
> reach more than reasonable robustness and reliability.
> 
> > 2.  LMB requires hardware coordination between the SONET payload mapper
> and
> > the SONET POH processor (C2 octet insertion/extraction logic) ?
> 
> At the transport plane level C2 is the field that LBM uses for the
> transition in the HOVC POH.
> 
> > 3.  The hardware based synchronization performance requirements are
> similar
> > to those required by LCAS.  Except that LCAS coordinates the critical
> > transitions using H4 instead of C2 ?  And that Virtual Concatenation
> systems
> > require to coordinate their payload mappers with bits 1-4 of the H4 byte
> to
> > determine the sequence number anyway ?
> 
> See above, yes and yes (since we re-use existing VC mechanisms)
> 
> > 4.  LBM is an extension to GMPLS.  GMPLS is required for LBM, whereas LCAS
> > could potentially be used with GMPLS or with other control plane or
> > management plane mechanisms ?
> 
> The scope of this proposal is to use GMPLS-LBM without LCAS. In fact
> (from what i understand in your question) see it more from transport
> to control plane impact taking the assumption that you expect some
> hardware improvement. Let's first determine if this can be achieved
> and then discuss the implementation issues that can arise from this
> proposal. In a sense, GMPLS-LBM is a self-consistent solution.
> 
> Regards,
> - dimitri.
> 
> > Thanks,
> >
> > Steve
> >
> > -----Original Message-----
> > From: Dimitri Papadimitriou [mailto:[email-masked]]
> > Sent: Friday, November 16, 2001 4:09 PM
> > To: Mannie, Eric; 'Stephen Trowbridge'; 'Maarten Vissers'
> > Cc: ccamp; q11/15; t1x1.5
> > Subject: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
> >
> > Hi folks,
> >
> > What happens... when we start the technical discussion
> > all guys taking part to the previous one now are gone ?
> >
> > We would like to start a technical discussion.. rather
> > difficult if we stay alone... or everybody agree on
> > proposal made in the previous e-mail ? (this in order
> > to refine the mechanism detailed in the GMPLS LBM I-D.)
> >
> > Any technical feedback is highly appreciated.
> >
> > Cheers,
> > - dimitri.
> >
> > "Mannie, Eric" wrote:
> > >
> > > Hello Stephen
> > >
> > > > GMPLS-LBM and LCAS ARE solutions to different problems.
> > >
> > > No, please see explanations below.
> > >
> > > > If you use LBM and change the mappings at the two ends without some
> > > coordination such as LCAS, you will have a glitch to the traffic
> > > (I think this is simple enough).
> > >
> > > No, please see below (C2 or V5 transition).
> > >
> > > >The compare/contrast discussion of LBM and LCAS is appropriate not
> > > >because LCAS is "sacred", but because you are comparing apples to
> > > >oranges. Statements in this document such as "One drawback of LCAS is
> .."
> > > >are unnecessary and inappropriate in this context, since LBM does
> > > >NOT solve the problem LCAS was designed to solve. Perhaps if you
> > > >were solving the SAME problem better, this would be OK, but this
> > > >is not the case.
> > >
> > > No, please see below.
> > >
> > > Simple example:
> > >
> > > 1) you first signal an additional VC/SPE to the destination (via a
> Path).
> > > 2) the destination knows exactly which VC/SPE is added (via the label).
> > > 3) the new VC is unequipped (indicated in POH C2 (for HOVC)),
> > >    so the VC/SPE is not yet added to concatenated signal.
> > > 4) then, you wait at the source for a confirmation from the destination
> > > (i.e. Resv).
> > > 5) the source "equip" the VC/SPE and sends.
> > > 6) the destination sees in the POH that the VC is "equipped"
> (transition).
> > >
> > > The difference between LCAS and LBM is that LCAS uses an additional
> > explicit
> > > indication in the overhead to say "this is the payload" to use. LBM
> > doesn't
> > > change the SDH/SONET overhead, while LCAS changes the SDH/SONET overhead
> >:-)
> > >
> > > LCAS uses a new field in the POH (CTRL) to know when the new VC
> > transitions
> > > to a significant payload. LBM proposes to do the same simply by looking
> at
> > > the C2 (for HOVC) transition - regular SDH/SONET field that will change
> > > anyway and that is used to indicate the type of payload.
> > >
> > > To be more precise about LCAS (I copy from the LCAS specification,
> section
> > > 6.3.1): "The first container frame to contain payload data for the new
> > > member shall be the container frame immediately following the container
> > > frame that contained the last bit(s) (i.e. the CRC) of the control
> packet
> > > with NORM/EOS message for that member" (the LCAS control packet).
> > >
> > > So, LCAS waits for the last bit of the appropriate LCAS control packet
> in
> > > the POH with the appropriate transition of its CTRL field. LBM waits
> > simply
> > > for the appropriate C2 (for HOVC) or V5 (for LOVC) transition in the POH
> > > (don't change SDH/SONET).
> > >
> > > By the way, this is version 0 of the draft and it was just posted.
> > >
> > > Suggestions, technical comments and improvements are welcome.
> > >
> > > I would appreciate if people could first read and speak before shooting
> > > directly :-)
> > >
> > > Kind regards,
> > >
> > > Eric
> > >
> > > -----Original Message-----
> > > From: Stephen Trowbridge [mailto:[email-masked]]
> > > Sent: Friday, November 16, 2001 7:49 PM
> > > To: Mannie, Eric
> > > Cc: 'Maarten Vissers'; ccamp; q11/15; t1x1.5; Dimitri Papadimitriou
> > > Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
> > >
> > > Eric,
> > > The point of my earlier email (items again below, this time with
> > > numbers) was not to prompt the comment "#3 is out of scope, therefore
> > > it is a choice between #1 and #2" (my parsing of recent statements).
> > >
> > > The issue (and I think the reason for Maarten's strong reaction) is
> this:
> > > GMPLS-LBM and LCAS are NOT different solutions to the same problem.
> > > GMPLS-LBM and LCAS ARE solutions to different problems.
> > > (I hope this is not too subtle for non-native English speakers).
> > >
> > > LCAS is a method to hitlessly change the mappings at the two
> > > ends of a virtually concatenated trail to increase or decrease the
> > > bandwidth. It does not say anything about how components to be
> > > added or removed from the virtually concatenated "bundle" are
> > > set up or taken down.
> > >
> > > LBM talks about how to set up or take down those added or removed
> > > components, but not about the details of changing the mapping (other
> > > than that it is done after the new components are successfully
> > > established.
> > >
> > > If you use LBM and change the mappings at the two ends without some
> > > coordination such as LCAS, you will have a glitch to the traffic
> > > (I think this is simple enough).
> > >
> > > The compare/contrast discussion of LBM and LCAS is appropriate not
> > > because LCAS is "sacred", but because you are comparing apples to
> > > oranges. Statements in this document such as "One drawback of LCAS is
> .."
> > > are unnecessary and inappropriate in this context, since LBM does
> > > NOT solve the problem LCAS was designed to solve. Perhaps if you
> > > were solving the SAME problem better, this would be OK, but this
> > > is not the case.
> > >
> > > Time to try to be constructive:
> > > - I think most of the current discussion of LCAS should be removed from
> > > this document. It is irrelevant since LCAS solves a different problem
> than
> > > LBM. To say that one is "better" than the other would only be meaningful
> > > if they were solving the same problem (can you really say that LBM
> solves
> > > problem A better than LCAS solves problem B?).
> > > - LCAS can be a good informative reference as a way to hitlessly modify
> > > the size of a virtually concatenated trail.
> > > - Clarify in the scope that the current draft describes the use of LBM
> > > without LCAS, which results in a traffic glitch when bandwidth is
> > modified.
> > > Indicate that the use of LCAS to hitlessly negotiate the changes to
> > > the size of virtually concatenated pipes after LBM sets up new
> > component(s)
> > > or before LBM takes down old component(s) is a topic for further study
> > > and perhaps to be addressed in a future version of the draft.
> > >
> > > Regards,
> > > Steve
> > >
> > > Steve Trowbridge wrote:
> > > > 1. Can you use LBM without LCAS? Yes, if you don't mind a glitch to
> > > > the traffic.
> > > >
> > > > 2. Can you use LCAS without LBM? Yes, if you don't care whether the
> > > > control plane knows that the different LSPs are part of the same
> > > > circuit.
> > > >
> > > > 3. Can you use LCAS WITH LBM? Hopefully yes, and this would seem to
> > > > be the preferred method for many applications.
> > >
> > > "Mannie, Eric" wrote:
> > > >
> > > > Hello Maarten,
> > > >
> > > > >Any sentence in which LCAS and ASON/GMPLS are compared shows a lack
> of
> > > > >understanding of LCAS's objective (my very strong opinion).
> > > >
> > > > Sorry, do you mean that it is forbidden to speak about your LCAS
> > document
> > > > and to compare GMPLS and LCAS functionalities ?
> > > >
> > > <snip, to save BW>

Delivery-date: Mon, 10 Dec 2001 13:27:15 -0800
Date: Mon, 10 Dec 2001 16:05:28 -0500
To: [email-masked]
From: Lou Berger <[email-masked]>
Subject: GMPLS signaling documents updated per last calls
Cc: [email-masked],[email-masked]

All,
	As was discussed in this morning's SUB-IP session, the GMPLS signaling 
documents have been updated to reflect comments received during the 
extended last call.  If you believe an issue that you have previously 
raised has not been addressed in the drafts, please send a message to the 
list.  (We'll respond with either how the issue was addressed or if it was 
missed.)

Here's a summary of changes:

draft-ietf-mpls-generalized-signaling-07.txt
see http://www.labn.net/docs/diff-sig-06-07.txt for change bar version.
o changes were primarily in the area of GPID values.
	(Juergen has a couple of additions that we'll incorporate in next rev.)

draft-ietf-mpls-generalized-rsvp-te-06.txt
see http://www.labn.net/docs/diff-rsvp-05-06.txt
o Minor editorial changes and clarifications based on comments from list

draft-ietf-mpls-generalized-cr-ldp-05.txt
http://www.labn.net/docs/diff-ldp-04-05.txt
o Brings cr-ldp functionally in line with rsvp-te
o Revised Admin Status Usage (per comments and also removed potential race 
condition)
o Clarified text related to interface bundling (To be consistent with 
updated bundling draft.)
o Added IANA Considerations
o Minor editorial changes and clarifications

Lou

Delivery-date: Mon, 10 Dec 2001 12:41:32 -0800
Date: Mon, 10 Dec 2001 15:35:51 -0500
To: "Zhi-Wei Lin" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: comments on rsvp-te-06
Cc: "Berger, Lou" <[email-masked]>,<[email-masked]>

At 02:14 PM 12/10/2001, Zhi-Wei Lin wrote:

>Hi Lou, See in-line
>
>Lou Berger wrote:
>
> >> In section 7.2.1, both step 3 are the same description.
> >
> >
> > yes, this is intentional!
> >
>
>But then what you're saying is that for ingress-initiated teardown, the
>flow is:
>(1) Path
>(2) Resv
>(3) PathTear
>
>While egress initiated it is:
>(1) Resv
>(2) PathTear

this is correct.

>This means that ingress-initiated takes 3 message passes. In OIF UNI
>1.0, a different message flow is defined for ingress-initiated, that of:
>(1) Path
>(2) PathErr (with Path_State_Removed flag set)

how nice...

>Is this latter message flow allowed, and if not, why not?

Note that the defined procedures say "SHOULD" not "MUST".

> >> Based on the
> >> flow of description, I think the first step 3 should read:
> >> "Upon receiving the Admin Status Object with the Delete (D) bit set in
> >> the Path message, the egress node sends a PathErr message (with
> >>      ^^^^              ^^^^^^              ^^^^^^^         ^^^^^
> >> Path_State_Removed flag set) upstream to remove the LSP and normal RSVP
> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> processing takes place."

> >
> >
> > The egress triggers the ingress to do the delete.
> >
>
>See above. Actually, based on the original text, the ingress triggers
>the egress which then triggers the ingress to do the delete...seems like
>extra level of message...I thought that's one reason for defining the
>Path_State_Removed flag for PathErr...
>
> >> In section 9.1, a statement under "recovery time":
> >>         A value of 0xffffffff indicates that resynchronization may
> >>           occur at a rate selected by the receiver.
> >> while in section 9.5.2, the following statement is made:
> >>         A Recovery Time value of 0xffffffff indicates that the
> >>         Recovery Period is effectively infinite.
> >> which is correct? or am I misinterpreting this?
> >
> >
> > These statements are mutually consistent.  If you'd like, I can just
> > remove the text, but I think most will find the comment useful.
> >
>
>I see the consistency now. You should keep the text.

Glad to hear we're now in sync.

Lou

>Thanks
>Zhi

Delivery-date: Mon, 10 Dec 2001 11:35:54 -0800
Date: Mon, 10 Dec 2001 14:14:18 -0500
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Lou Berger <[email-masked]>
CC: [email-masked]
Subject: Re: comments on rsvp-te-06

Hi Lou, See in-line

Lou Berger wrote:

>> In section 7.2.1, both step 3 are the same description.
> 
> 
> yes, this is intentional!
> 

But then what you're saying is that for ingress-initiated teardown, the 
flow is:
(1) Path
(2) Resv
(3) PathTear

While egress initiated it is:
(1) Resv
(2) PathTear

This means that ingress-initiated takes 3 message passes. In OIF UNI 
1.0, a different message flow is defined for ingress-initiated, that of:
(1) Path
(2) PathErr (with Path_State_Removed flag set)

Is this latter message flow allowed, and if not, why not?

>> Based on the
>> flow of description, I think the first step 3 should read:
>> "Upon receiving the Admin Status Object with the Delete (D) bit set in
>> the Path message, the egress node sends a PathErr message (with
>>      ^^^^              ^^^^^^              ^^^^^^^         ^^^^^
>> Path_State_Removed flag set) upstream to remove the LSP and normal RSVP
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> processing takes place."
> 
> 
> The egress triggers the ingress to do the delete.
> 

See above. Actually, based on the original text, the ingress triggers 
the egress which then triggers the ingress to do the delete...seems like 
extra level of message...I thought that's one reason for defining the 
Path_State_Removed flag for PathErr...

>> In section 9.1, a statement under "recovery time":
>>         A value of 0xffffffff indicates that resynchronization may
>>           occur at a rate selected by the receiver.
>> while in section 9.5.2, the following statement is made:
>>         A Recovery Time value of 0xffffffff indicates that the
>>         Recovery Period is effectively infinite.
>> which is correct? or am I misinterpreting this?
> 
> 
> These statements are mutually consistent.  If you'd like, I can just 
> remove the text, but I think most will find the comment useful.
> 

I see the consistency now. You should keep the text.

Thanks
Zhi

Delivery-date: Mon, 10 Dec 2001 10:52:36 -0800
Date: Mon, 10 Dec 2001 13:22:00 -0500
To: Ben Mack-Crane <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: Moving right along ... generalized-rsvp-te-05
Cc: Kireeti Kompella <[email-masked]>,[email-masked]

At 03:08 PM 10/29/2001, Ben Mack-Crane wrote:

>After reviewing draft-ietf-mpls-generalized-rsvp-te-05.txt
>I have the following comments and questions:
>
>1) In the procedures regarding the Generalized Label Request
>    object, the statement is made that "The node may either
>    directly support the LSP or it may use a tunnel (FA),
>    i.e., another class of switching."

please see the routing drafts.

>A Tunnel (FA) is a type
>    of link, not a class of switching.  This adds to the
>    confusion I've noted about the need for and use of Switching
>    Type.

>2) Bandwidth Encoding use of the Intserv Tspec object seems
>    quite unusual since this use is not consistent with existing
>    uses of this object, and new uses could easily use a new
>    C-Type.

I think either approach work.  This topic was discussed by the authors at 
least 12-18 months. The current approach was decided then.

>3) In the procedures for Generalized Label it states "If the label is
>    unacceptable then the recipient MUST generate a ResvErr message with
>    a "Routing problem/MPLS label allocation failure" indication."
>    I think "Unacceptable Label Value" would be more appropriate.

okay.

>4) In the Waveband Switching section it says "For compatibility reasons,
>    a new RSVP C-Type (3) is assigned."  What is the compatability
>    problem this is solving?

simply to distinguish types.  I remove the text to avoid such confusion in 
the future.

>5) In the Label Set object, why is the Label Type field 14 bits if
>    only the low order 8 bits are used?

for CR-LDP compatibility.

>6) Some new error strings are defined, "Label Set" and "Unsupported Link
>    Protection," but no values or placeholders are included. Where are new
>    error values to be documented?

As part of IANA assignment.

>7) The Notify message is intended to "enable expedited notification of
>    failures," but it relies on the IP layer which may be affected by the
>    failure that the Notify is reporting.  This could defeat the goal
>    of rapid notification.  Without some means of guaranteeing the Notify
>    doesn't have to wait for IP routing convergence to be delivered,
>    it isn't a satisfactory solution.
>
>8) The description of the C-Type field in the Label ERO subobject suggests
>    that this subobject contains a Label Object.  Is this the case, or does
>    the Label ERO subobject simple contain label values, and the C-Type
>    matches the C-Type that would be used if the same label values were
>    included in a Label object?

per the draft:

       Label: Variable

          This field identifies the label to be used.  The format of this
          field is identical to the one used by the Label field in
          Generalized Label, see Section 3.2.1.

>9) In deleting an LSP from the egress, the R bit is set in the Admin Status
>    object.  The ingress responds with a PathTear message.  Does this PathTear
>    contain the Admin Status object or should the R bit be cleared?

It's not in the BNF, so no it's not included.

>10)The Notify message may contain a new setting of the Admin Status.
>    Under what conditions would an intermediate or egress node change
>    Admin Status?

It may be used at any time that a PathErr or ResvErr is generated.

>  What happens if the Notify receiver is not the ingress?

same action as would be taken if/when the corresponding message is received.

>11)In Interface Identification it says "Data channels are specified from 
>the view point
>    of the sender of the Path message."  Is this true even for Resv messages
>    or should it read "Data channels are specified from the viewpoint
>    of the sender of the message."?

current text is correct.

>12)In Restart_Cap it says "Refreshing of Resv and Path state SHOULD be
>    suppressed during this waiting period."  I assume this is refreshes
>    toward the failed neighbor, not to all neighbors for that LSP.  True?

yes.

thanks for the comments,
lou

>Regards,
>Ben Mack-Crane

Delivery-date: Mon, 10 Dec 2001 09:50:57 -0800
From: "Michael I Mandelberg(Isaac)" <[email-masked]>
To: [email-masked]
Subject: LMP message length too small?
Date: Mon, 10 Dec 2001 12:40:27 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C181A1.C12F39E0
Content-Type: text/plain;
	charset="iso-8859-1"

Since the LMP message length field is only two bytes, this limits the length
of a message to 2^16 bytes. Consider the link summary message.
The length of this message is:
 
      8          +           8          +          16          +
N*28
Header Sz          Msg ID Sz          TE Link Sz          N * Data Link Sz
 
At best then, there can be 2338 data links in a TE link. This is assuming
4-byte addresses. If we allow for IPv6 addresses, it becomes:
 
      8          +           8          +          40          +
N*60
Header Sz          Msg ID Sz          TE Link Sz          N * Data Link Sz
 
so there can be 1091data links in a TE link.
 
I am wondering if this is too restrictive. I think it is very possible that
this would force some large scale TE links to be broken down into multiple
TE links to run LMP on them. What do others think?
 
Michael Mandelberg

------_=_NextPart_001_01C181A1.C12F39E0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN class=792222517-10122001>Since the LMP 
message length field is only two bytes, this limits the length of a message to 
2^16 bytes. Consider the link summary message.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=792222517-10122001>The length of this 
message is:</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=792222517-10122001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=792222517-10122001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  
8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; 
16&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
N*28</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=792222517-10122001>Header 
Sz&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Msg 
ID&nbsp;Sz&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;TE 
Link&nbsp;Sz&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;N * Data 
Link Sz</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=792222517-10122001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=792222517-10122001>At best then, there 
can be 2338 data links in a TE link. This is assuming 4-byte addresses. If we 
allow for IPv6 addresses, it becomes:</SPAN></FONT></DIV>
<DIV><SPAN class=792222517-10122001>
<DIV><SPAN class=792222517-10122001></SPAN><FONT face=Arial 
size=2>&nbsp;</FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=792222517-10122001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;40&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
N*60</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=792222517-10122001>Header 
Sz&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Msg 
ID&nbsp;Sz&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;TE 
Link&nbsp;Sz&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;N * Data 
Link Sz</SPAN></FONT></DIV>
<DIV><SPAN class=792222517-10122001></SPAN><FONT face=Arial 
size=2>&nbsp;</FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=792222517-10122001>so there can be 
1091data links in a TE link.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=792222517-10122001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=792222517-10122001>I am wondering if 
this is too restrictive. I think it is very possible that this would force some 
large scale TE links to be broken down into multiple TE links to run LMP on 
them. What do others think?</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=792222517-10122001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=792222517-10122001>Michael 
Mandelberg</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=792222517-10122001></SPAN></FONT>&nbsp;</DIV></SPAN></DIV></BODY></HTML>

------_=_NextPart_001_01C181A1.C12F39E0--

Delivery-date: Mon, 10 Dec 2001 09:41:11 -0800
Date: Mon, 10 Dec 2001 12:00:38 -0500
To: Ben Mack-Crane <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: Moving right along ... generalized-signaling-06
Cc: Kireeti Kompella <[email-masked]>,[email-masked]

At 01:09 PM 10/29/2001, Ben Mack-Crane wrote:

>After reviewing draft-ietf-mpls-generalized-signaling-06.txt I have
>a few comments and questions:
>
>1) There seems to be no difference as far as label allocation
>    is concerned between LSP Encoding Types Ethernet V2/DIX (2)
>    and Ethernet 802.3 (10).  One Encoding type would seem to
>    be sufficient.

I agree, but some feel that this is needed to properly establish LSPs in 
systems what would terminate each type differently.

>2) G-PID types (19), (20), and (21) are repeats of (16), (17),
>    and (18).

see latest draft...

>   Since the Siganl Type will indicate whether the
>    LSP is VC-11/VT1.5 or VC-12/VT2, this encoding is redundant.

the fields serve different purposes.

>3) G-PID type (37) Lambda seems insufficient (too vague) to
>    support interoperability.  Is there any practical use for this
>    value?

yes, it's needed when doing fiber/port switching.

>4) In the "Bandwidth Encoding" section it states "For non-packet LSPs, it
>    is useful to define discrete values to identify the bandwidth of the
>    LSP."  For SONET/SDH this is unnecessary given the Signal Type is
>    provided.  For the other non-packet LSP types (Lambda and Fiber)
>    it is not clear that all the values cited in the example are relevant
>    (for example, a DS0 lambda would seem wasteful...).

>    This is confusing, and should be clarified.  In fact, a description of
>    exactly why this field is required is needed.

We've gone over this text multiple times.  Do you have any suggested wording.

>5) The Waveband ID "is selected by the sender and reused in all
>    subsequent related messages."  This seems more the sort of thing that
>    should be negotiated by LMP rather than during connection setup.

The ID has significance within signaling context of the sender. (like 
message id). I don't think using another layer of complexity for provate 
information makes sense.

>6) The definition of Start Label and End Label in waveband switching seems
>    inconsistent with the behavior described in generalized-rsvp-te-05.

I don't see this.  Feel free to suggest wording.

>
>7) In Protection Information it states "The resources allocated for a
>    secondary LSP MAY be used by other LSPs until the primary LSP fails
>    over to the secondary LSP."  This may not always be the case.  An
>    explicit flag indicating whether or not extra traffic may use the
>    secondary path resources is needed.

??? This is the purpose of this bit.

>8) The Administrative Status Information includes a bit indicating
>    "Administratively down," but there is no reference to a definition
>    of this state.  Is this intended to mirror the MIB variable?  If so,
>    a reference is needed.  If not, more definition is needed to ensure
>    the local behaviors driven by this bit are in some way consistent.
>    Whether this state defintion is consistent with current transport
>    network operations should also be considered.

Per the document:
   The actions taken by a node based on a state local decision.

>9) In Interface Identification, the IP Address for types 3,4, and 5 is
>    described as possibly "an IP address associated with the router ID."
>    Is this intended to mean the Router ID or any IP address owned by
>    the node?  It seems the Router ID is the simplest solution, but the
>    wording is not clear.

Text has been reworded in 07. It's any IP address configured on a node.

>10)In describing the Interface ID the statement "The special value
>    0xFFFFFFFF can be used to indicate the same label is to be valid
>    across all component links."  What is the "label" referred to in
>    this case?

I'll reword in the post IETF last call rev of the document.

Lou

>Regards,
>Ben Mack-Crane

Delivery-date: Mon, 10 Dec 2001 09:41:01 -0800
Date: Mon, 10 Dec 2001 12:23:39 -0500
To: "Zhi-Wei Lin" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: comments on rsvp-te-06
Cc: <[email-masked]>

per today's discussion:

At 10:14 AM 11/30/2001, Zhi-Wei Lin wrote:

>Hi folks,
>
>In rsvp-te-06, IANA consideration section, the Notify message message
>type also needs to be assigned by IANA.

agreed.  there is no change to the document here.

>Also, several error codes/values
>were introduced in the document. I believe these also need to be
>identified and assigned (e.g., routing problem/switching type, routing
>problem/unsupported link protection)

agreed.  This will be part of the IANA assignment request.  (Which will be 
forthcoming soon.)

>In section 9.3, two error messages were defined:
>         "Control Channel Degraded State"
>         "Control Channel Active State"
>Are these both new error codes, or a single error code with two error
>values, or part of an existing error code?

yes.  will be part of the IANA assignment.

>Also, the text says "inform other nodes of the restoration via a
>PathErr...". What are the other nodes? Is it all RSVP-aware nodes, all
>nodes where a LSP passes through the failed node, etc. ?
>

sorry, it should say "upstream" rather than "other".
(It'll be this way in the post IETF last call rev.)

>In section 4.3.1, reference to RFC2205 for error codes and values is
>insufficient. Many of the relevant error codes are also in the RSVP-TE I-D.

The reference is to the error_spec definition, which is rfc2205.

>In section 7.2.1, both step 3 are the same description.

yes, this is intentional!

>Based on the
>flow of description, I think the first step 3 should read:
>"Upon receiving the Admin Status Object with the Delete (D) bit set in
>the Path message, the egress node sends a PathErr message (with
>      ^^^^              ^^^^^^              ^^^^^^^         ^^^^^
>Path_State_Removed flag set) upstream to remove the LSP and normal RSVP
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>processing takes place."

The egress triggers the ingress to do the delete.

>In section 9.1, a statement under "recovery time":
>         A value of 0xffffffff indicates that resynchronization may
>           occur at a rate selected by the receiver.
>while in section 9.5.2, the following statement is made:
>         A Recovery Time value of 0xffffffff indicates that the
>         Recovery Period is effectively infinite.
>which is correct? or am I misinterpreting this?

These statements are mutually consistent.  If you'd like, I can just remove 
the text, but I think most will find the comment useful.

Lou

>Looking forward to comments...
>
>Zhi

Delivery-date: Mon, 10 Dec 2001 09:10:50 -0800
Date: Mon, 10 Dec 2001 11:00:27 -0600
From: Jonathan Sadler <[email-masked]>
Reply-To: [email-masked]
To: "Pagan, Joe" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: IP over DCC

Joe -

Standardization of IP over the DCC has just been completed within the
ITU.  You can find the spec a part of G.7712.  I have attached the
message originally sent by Kiretti on this subject.

Jonathan Sadler

----- Original Email -----
Hi All,

IETF'ers now have access to the ITU-T Study Group 15's communication
statements to the IETF; the following email has the details.

Please note that these documents are copyrighted by the ITU; please
respect their copyrights, and use appropriate care in duplicating and
distributing these materials.

ITU Copyright Information:

    "Access to databases of the International Telecommunication Union
    (ITU) for consultation of documents and/or information retrieval
    is permitted by the ITU subject to the user's acceptance of ITU's
    provisions and conditions of copyright contained within each
document
    which obliges the user not to duplicate the document or parts
thereof
    for distribution or sale external to the user's organization.  Such
    information may be utilised in the receiving organization, as
    required, to further the work of the ITU or any standards body
    developing related standards, to provide guidance for product or
    service development and implementation and to serve as support
    documentation associated with a product or service."

Many thanks to Steven Trowbridge and others who made access possible.

Also please note http://www.ietf.org/IESG/liaison.html which has the
IETF liaison statements with other standards bodies, among them the
ITU-T.

Kireeti.

-------------- Forwarded Mail ----------------

Scott, Kireeti, and Lyndon,
I am pleased to inform you that we finally have some concensus
within ITU-T that gives us a way to share the files related to
the Study Group 15 communications statements with IETF participants.
This mechanism will likely evolve in the future (more about this
below), but at least for now we have a way to share these files
with IETF participants.

The relevant communications include two to ccamp:
- SDH Signal and Group Structures
- New Recommendations for Automatically Switched Optical Netorks
and one to sigtran:
- Draft Recommendation G.799.1 on interconnecting GSTN and IP Networks

The information may be accessed via a web browser using the following
URL (from an ITU-T ftp server):

ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICATIONS/index.html

In the future, the Telecommunications Standardization Bureau will likely
provide a way for IETF participants who wish to collaborate with ITU-T
to request their own logins and passwords to access this site, but for
now, all can access the information using the common ID and password
that
you see embedded in the URL.

The structure of the information is as follows:

Main Page
   |
   |-->ccamp-->copyright---->Communication on SDH Signal Structures
   |                      |
   |                      -->Communication on ASON Recs
   |                                |
   |                                |-->G.8080_Y.1304.pdf
   |                                |-->G.7713_Y.1704.pdf
   |                                |-->G.7714_Y.1705.pdf
   |                                --->G.7712_Y.1703.pdf
   |
   --->sigtran-->copyright-->Communication on G.799.1 (GSTN and IP)
                                    |
                                    --->G.799-1-DRAFT-V6.pdf

Please request that your members enter at the main page - this will
help insure that those who access the documents will be aware of the
ITU-T copyright restrictions.

(rest clipped)

"Pagan, Joe" wrote:
> 
> Hi all,
> 
> Before submitting a draft, I'd like to see if there's been any work on the standardization of transporting IP over SONET DCCs.
> 
> I know that there was some kind of draft submitted to the Network and Services Integration Forum(?). Don't know its status but it doesn't address multiple DCC usage. Can someone please let me know if there's been any standards work in this area?
> 
> Thanks,
> Joe

Delivery-date: Sun, 09 Dec 2001 12:25:51 -0800
Date: Sun, 09 Dec 2001 13:23:39 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: "Pagan, Joe" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [IP-Optical] IP over DCC

Joe,
Please see ITU-T Recommendation G.7712/Y.1703, "Architecture and Specification of Data
Communication Network", just approved from the October 2001 meeting of ITU-T Study
Group 15. If you are not an ITU-T member, this Recommendation was the subject
of a communication from ITU-T to IETF ccamp, and can be obtained through the "ccamp"
links from:
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICATIONS/index.html
This new Recommendation deals with use of IP only, OSI only, and mixed IP/OSI data
communications networks. This should be relevant to SONET, as SONET is one of the
regional flavors of SDH.
Regards,
Steve Trowbridge
Vice-Chair, ITU-T Study Group 15

> "Pagan, Joe" wrote:
> 
> Hi all,
> 
> Before submitting a draft, I'd like to see if there's been any work on the standardization of transporting IP over SONET DCCs.
> 
> I know that there was some kind of draft submitted to the Network and Services Integration Forum(?). Don't know its status but it doesn't address multiple DCC usage. Can someone please let me know
> if there's been any standards work in this area?
> 
> Thanks,
> Joe
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> end
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> The information contained in this e-mail including any attachments may constitute Corvis Corporation Proprietary Information that is subject to Non-Disclosure Agreement and cannot be disclosed to
> any other party without the express consent of Corvis Corporation.
> 
> If you are neither the intended recipient of this e-mail nor responsible for delivering this e-mail to the intended recipient, note that any dissemination, distribution, copying, or retention of
> this e-mail is prohibited.
> 
> If you believe you have received this e-mail in error, we request that you notify the sender by return e-mail and then delete this e-mail and any return e-mail immediately.

Delivery-date: Sun, 09 Dec 2001 12:04:19 -0800
From: "Vipul Sharma" <[email-masked]>
To: <[email-masked]>
Subject: RE: agenda
Date: Sun, 9 Dec 2001 14:55:49 -0500

Is there an agenda for SLC yet??

Vip

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of [email-masked]
Sent: Friday, December 07, 2001 3:38 PM
To: [email-masked]; [email-masked]
Subject: agenda

Any idea when the agenda will come for SLC meeting?

Delivery-date: Sat, 08 Dec 2001 04:58:15 -0800
From: "Pagan, Joe" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>,  [email-masked], [email-masked]
Subject: IP over DCC
Date: Sat, 8 Dec 2001 08:12:47 -0500 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C17FEA.07D551E0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi all,

Before submitting a draft, I'd like to see if there's been any work on the
standardization of transporting IP over SONET DCCs. 

I know that there was some kind of draft submitted to the Network and
Services Integration Forum(?). Don't know its status but it doesn't address
multiple DCC usage. Can someone please let me know if there's been any
standards work in this area?

Thanks, 
Joe 

 

 

 

 

 

 

 

 

 

end

 

 

 

 

 

 

 

 

 

 

 

 

 

The information contained in this e-mail including any attachments may
constitute Corvis Corporation Proprietary Information that is subject to
Non-Disclosure Agreement and cannot be disclosed to any other party without
the express consent of  Corvis Corporation. 
If you are neither the intended recipient of this e-mail nor responsible for
delivering this e-mail to the intended recipient, note that any
dissemination, distribution, copying, or retention of this e-mail is
prohibited. 
If you believe you have received this e-mail in error, we request that you
notify the sender by return e-mail and then delete this e-mail  and any
return e-mail immediately. 

------_=_NextPart_001_01C17FEA.07D551E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">

<META content=3D"MSHTML 5.00.3314.2100" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>
<P><FONT size=3D3>Hi all,</FONT></P>
<P><FONT size=3D3>Before submitting a draft, I'd like to see if there's =
been any=20
work on the<SPAN =
class=3D991013017-07122001>&nbsp;</SPAN>standardization of=20
transporting IP over SONET DCCs. </FONT></P>
<P><FONT size=3D3>I know that there was<SPAN =
class=3D991013017-07122001> </SPAN>some=20
kind of draft submitted to the Network and Services Integration =
Forum(?). Don't=20
know its status but it doesn't address multi<SPAN =
class=3D991013017-07122001>ple=20
</SPAN>DCC usage. Can someone please let me know if there's been =
any&nbsp;<SPAN=20
class=3D991013017-07122001>standards </SPAN>work in this=20
area?</FONT></P></FONT></DIV>
<P><FONT face=3DArial size=3D2>Thanks,</FONT> <BR><FONT face=3DArial =
size=3D2>Joe=20
</FONT></P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P><FONT face=3DArial size=3D2><SPAN =
class=3D991013017-07122001>end</SPAN></FONT></P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<DIV>&nbsp;</DIV></BODY></HTML>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">The information contained in this =
e-mail including any attachments may constitute Corvis Corporation =
Proprietary Information that is subject to Non-Disclosure Agreement and =
cannot be disclosed to any other party without the express consent of  =
Corvis Corporation. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">If you are neither the intended =
recipient of this e-mail nor responsible for delivering this e-mail to =
the intended recipient, note that any dissemination, distribution, =
copying, or retention of this e-mail is prohibited. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">If you believe you have received this =
e-mail in error, we request that you notify the sender by return e-mail =
and then delete this e-mail  and any return e-mail immediately. =
</FONT></P>

------_=_NextPart_001_01C17FEA.07D551E0--

Delivery-date: Fri, 07 Dec 2001 17:10:35 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Lambda LSP establishment
Date: Fri, 07 Dec 2001 18:08:59 -0700

Hi All,
        If I have 5 nodes A, B, C, D and E connected as shown. Assume
that only one wavelength is available on the path A to E (no wavelength
conversion capability is there on the complete path). Let the capacity
of the wavelength be C. Further assume a request arrives for connection
from node C to E for a line capacity of C/4. This request will be
successful as we have available wavelength. Now If another request
comes at node A to establish another connection from node A to node E
via nodes {A,B,C,D,E} for a line capacity of C/4. Should this request
be successful as we have already allocated the wavelength ?

If the previous connection from C to E of capacity C/4 had been
advertised as a FA, in that case will the IInd request succeed ?

If the previous connection from C to E of capacity C/4 had not been
advertised as FA then what will be the fate of IInd connection ?

       A <--> B <---> C <----> D <---> <----> E

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Fri, 07 Dec 2001 15:54:42 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: Fwd: Re: AW: AW: VC-4-64c as forwarding adjacency
Date: Fri, 07 Dec 2001 15:38:41 -0700

Hi All,
          I think the authors of GMPLS drafts should clarify the label 
allocation for the following scenario. If this scenario is not possible to 
establish through GMPLS then please point that too.

Regards,
manoj.

Hi Marteen,
            I fully agree with the diagram below. There will be a
ATM VP
link (VC-4-64c) between nodes A and D.

Can u please elaborate more on this one :
"ATM VP connection controllers in A and D exchange ATM VP labels to
setup ATM VP connections"

How will the ATM VP labels be distributed between nodes A and D ? Is
it not with in the scope of GMPLS signalling ?

If I am misinterpreting the concept of LSP hierarchies, please let
me know that too.

Regards,
manoj.

>>From: Maarten Vissers <[email-masked]>
>>To: manoj juneja <[email-masked]>
>>CC: [email-masked]
>>Subject: Re: AW: AW: VC-4-64c as forwarding adjacency
>>Date: Fri, 07 Dec 2001 11:00:54 +0100
>>
>>Manoj,
>>
>>When the VC-4-64c is used as "FA" it provides e.g. an ATM VP link to the
>>ATM VP
>>layer network. As such, ATM VP signals are being routed via this ATM VP
>>link
>>supported by the VC-4-64c trail. So ATM VP labels will be used between
>>nodes A
>>and D.
>>
>>      NE A            NE B                 NE C               NE D
>>|<---------->|<---------------->|<------------------->|<--------------->|
>>
>>     ||||                                                     ||||
>>ATM VP Fabric                                            ATM VP Fabric
>>    ||||||                                                 ||||||
>>   VC-4-64c                                               VC-4-64c
>>     port                                                   port
>>      |                                                      |
>>      |                                                      |
>>      |         VC-4-64c Fabric      VC-4-64c Fabric         |
>>      |           |       ||||        ||||       |           |
>>   STM-64      STM-64    STM-256     STM-256   STM-64      STM-64
>>    port        port      port        port      port        port
>>      |           |        |           |         |           |
>>      -------------        -------------         -------------
>>
>>When the ATM equipment at A needs a 10G link with the aTM equipment at D,
>>it
>>requests a regular VC-4-64c connection between A and D. As the connection
>>terminates at VC-4-64c ports automatically there is an ATM VP link 
>>created.
>>The
>>ATM VP connection controllers in A and D exchange ATM VP labels to setup
>>ATM VP
>>connections.
>>
>>When the Vc-4-64c connection had to be setup, the VC-4-64c connection
>>controllers in A, B, C and D will exchange VC-4-64c labels.
>>
>>When the ATM equipment is in a user domain, the interface between nodes A
>>and B
>>and nodes C and D are UNIs. In that case the VC-4-64c connection
>>controllers in
>>nodes A and D are replaced by VC-4-64c call controllers. Then the
>>interactions
>>are between calling/called party call controllers (in nodes A and D) and
>>network
>>call controllers, and network call controller and connection controllers 
>>in
>>nodes B and C.
>>
>>As you see there is no notion of FA needed.
>>
>>Regards,
>>
>>Maarten
>>
>>
>>manoj juneja wrote:
>> >
>> > Hi Marteen,
>> >             Agreed. VC-4-64c connection can be advertised as a FA and
>> > can carry IP/ATM or ethernet traffic.
>> >
>> > Now take the case where multiple LSPs are to be tunneled through the
>> > VC-4-64c connection (FA-LSP).
>> > What about the label ? What type of label the tail end of VC-4-64c FA
>> > -LSP i.e. node D will pass to the node A (i.e. head end of vc-4-64c FA
>> > -LSP) ?
>> > The LSP encoding and switching types are different for FA-LSP and the
>> > LSP which is to be tunneled through the FA-LSP.
>> >
>> > Regards,
>> > manoj.
>> >
>> > >From: Maarten Vissers <[email-masked]>
>> > >To: "'manoj juneja'" <[email-masked]>
>> > >CC: [email-masked]
>> > >Subject: Re: AW: AW: VC-4-64c as forwarding adjacency
>> > >Date: Thu, 06 Dec 2001 12:24:32 +0100
>> > >
>> > >Manoj,
>> > >
>> > >In transport terminology I would refer to this as a VC-4-64c trail
>> > >supporting an
>> > >IP, ATM or Ethernet link.
>> > >
>> > >Regards,
>> > >
>> > >Maarten
>> > >
>> > >Heiles Juergen wrote:
>> > > >
>> > > > Manoj,
>> > > >
>> > > > this has nothing to do with forwarding adjacency. It is a
>>restriction of
>> > >the transport plane. A VC-4 cannot be transported in a VC-4-64c. A
>>VC-4-64c
>> > >supports IP, ATM, Ethernet as client signal, but not a VC-4 or
>> > >VC-3/2/12/11.
>> > > > So you can have a VC-4-64c forwarding adjacency for IP, ATM or
>>Ethernet
>> > >clients.
>> > > >
>> > > > Juergen
>> > > >
>> > > > > -----Ursprüngliche Nachricht-----
>> > > > > Von: manoj juneja [mailto:[email-masked]]
>> > > > > Gesendet: Mittwoch, 5. Dezember 2001 19:49
>> > > > > An: [email-masked]; [email-masked]
>> > > > > Betreff: Re: AW: VC-4-64c as forwarding adjacency
>> > > > >
>> > > > >
>> > > > > Hi Juergen,
>> > > > >             Does this mean the forwarding adjacency concept is 
>>not
>> > > > > applicable to concatenated signals/LSPs ? I hope forwarding
>> > > > > adjacecny of
>> > > > > virtual concatenated LSP should be allowed.
>> > > > >
>> > > > > Regards,
>> > > > > manoj.
>> > > > >
>> > > > >
>> > > > > >From: "Juergen Heiles" <[email-masked]>
>> > > > > >To: "'manoj juneja'" <[email-masked]>,
>> > > > > <[email-masked]>
>> > > > > >Subject: AW: VC-4-64c as forwarding adjacency
>> > > > > >Date: Wed, 5 Dec 2001 10:19:03 +0100
>> > > > > >
>> > > > > >No, that is not possible as you cannot transport a VC-4 in a
>> > > > > VC-4-64c. A
>> > > > > >VC-4-64c only supports dat clients like ATM, IP, Ethernet.
>> > > > > >
>> > > > > >Juergen
>> > > > > >
>> > > > > > > -----Ursprüngliche Nachricht-----
>> > > > > > > Von: manoj juneja [mailto:[email-masked]]
>> > > > > > > Gesendet: Dienstag, 4. Dezember 2001 23:44
>> > > > > > > An: [email-masked]
>> > > > > > > Betreff: VC-4-64c as forwarding adjacency
>> > > > > > >
>> > > > > > >
>> > > > > > > Hi All,
>> > > > > > >          Can I tunnel a request for VC-4 LSP on VC-4-64c
>> > > > > forwarding
>> > > > > > > adjacency ? If yes, then what would be the {suklm} ?
>> > > > > > >
>> > > > > > > Regards,
>> > > > > > > manoj
>> > > > > > >
>> > > > > > >
>>_________________________________________________________________
>> > > > > > > Get your FREE download of MSN Explorer at
>> > > > > > > http://explorer.msn.com/intl.asp
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > > > _________________________________________________________________
>> > > > > Get your FREE download of MSN Explorer at
>> > > > http://explorer.msn.com/intl.asp
>> > ><< mvissers.vcf >>
>> >
>> > _________________________________________________________________
>> > Get your FREE download of MSN Explorer at
>>http://explorer.msn.com/intl.asp
>><< mvissers.vcf >>
>
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Fri, 07 Dec 2001 15:36:42 -0800
To: [email-masked]
Date: Fri, 07 Dec 2001 15:35:20 -0800
From: "mitali J" <[email-masked]>
Reply-To: [email-masked]
Subject: Optical Equipment Vendors Input Required
Organization: Lycos Mail  (http://mail.lycos.com:80)
Content-Length: 455

Hi All,
         My question is directed towards optical vendors. If a
optical vendor gets GMPLS software stack from some portable software
company where would u like to keep the GMPLS label allocation
(resource allocation) module ?

Whether the optical vendor would like the signalling module doing the
label allocation or would like to keep the control of label
allocation with itself ? 

Your Input will be appreciated.

Thanks,
mitali.

Delivery-date: Fri, 07 Dec 2001 12:41:53 -0800
From: [email-masked]
Date: Fri, 7 Dec 2001 14:38:08 -0600
Subject: agenda
TO: [email-masked]

Any idea when the agenda will come for SLC meeting?

Delivery-date: Fri, 07 Dec 2001 12:11:47 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: Re: AW: AW: VC-4-64c as forwarding adjacency
Date: Fri, 07 Dec 2001 13:10:15 -0700

Hi Marteen,
            I fully agree with the diagram below. There will be a ATM VP 
link (VC-4-64c) between nodes A and D.

Can u please elaborate more on this one :
"ATM VP connection controllers in A and D exchange ATM VP labels to
setup ATM VP connections"

How will the ATM VP labels be distributed between nodes A and D ? Is it
not with in the scope of GMPLS signalling ?

If I am misinterpreting the concept of LSP hierarchies, please let me know 
that too.

Regards,
manoj.

>From: Maarten Vissers <[email-masked]>
>To: manoj juneja <[email-masked]>
>CC: [email-masked]
>Subject: Re: AW: AW: VC-4-64c as forwarding adjacency
>Date: Fri, 07 Dec 2001 11:00:54 +0100
>
>Manoj,
>
>When the VC-4-64c is used as "FA" it provides e.g. an ATM VP link to the 
>ATM VP
>layer network. As such, ATM VP signals are being routed via this ATM VP 
>link
>supported by the VC-4-64c trail. So ATM VP labels will be used between 
>nodes A
>and D.
>
>      NE A            NE B                 NE C               NE D
>|<---------->|<---------------->|<------------------->|<--------------->|
>
>     ||||                                                     ||||
>ATM VP Fabric                                            ATM VP Fabric
>    ||||||                                                 ||||||
>   VC-4-64c                                               VC-4-64c
>     port                                                   port
>      |                                                      |
>      |                                                      |
>      |         VC-4-64c Fabric      VC-4-64c Fabric         |
>      |           |       ||||        ||||       |           |
>   STM-64      STM-64    STM-256     STM-256   STM-64      STM-64
>    port        port      port        port      port        port
>      |           |        |           |         |           |
>      -------------        -------------         -------------
>
>When the ATM equipment at A needs a 10G link with the aTM equipment at D, 
>it
>requests a regular VC-4-64c connection between A and D. As the connection
>terminates at VC-4-64c ports automatically there is an ATM VP link created. 
>The
>ATM VP connection controllers in A and D exchange ATM VP labels to setup 
>ATM VP
>connections.
>
>When the Vc-4-64c connection had to be setup, the VC-4-64c connection
>controllers in A, B, C and D will exchange VC-4-64c labels.
>
>When the ATM equipment is in a user domain, the interface between nodes A 
>and B
>and nodes C and D are UNIs. In that case the VC-4-64c connection 
>controllers in
>nodes A and D are replaced by VC-4-64c call controllers. Then the 
>interactions
>are between calling/called party call controllers (in nodes A and D) and 
>network
>call controllers, and network call controller and connection controllers in
>nodes B and C.
>
>As you see there is no notion of FA needed.
>
>Regards,
>
>Maarten
>
>
>manoj juneja wrote:
> >
> > Hi Marteen,
> >             Agreed. VC-4-64c connection can be advertised as a FA and
> > can carry IP/ATM or ethernet traffic.
> >
> > Now take the case where multiple LSPs are to be tunneled through the
> > VC-4-64c connection (FA-LSP).
> > What about the label ? What type of label the tail end of VC-4-64c FA
> > -LSP i.e. node D will pass to the node A (i.e. head end of vc-4-64c FA
> > -LSP) ?
> > The LSP encoding and switching types are different for FA-LSP and the
> > LSP which is to be tunneled through the FA-LSP.
> >
> > Regards,
> > manoj.
> >
> > >From: Maarten Vissers <[email-masked]>
> > >To: "'manoj juneja'" <[email-masked]>
> > >CC: [email-masked]
> > >Subject: Re: AW: AW: VC-4-64c as forwarding adjacency
> > >Date: Thu, 06 Dec 2001 12:24:32 +0100
> > >
> > >Manoj,
> > >
> > >In transport terminology I would refer to this as a VC-4-64c trail
> > >supporting an
> > >IP, ATM or Ethernet link.
> > >
> > >Regards,
> > >
> > >Maarten
> > >
> > >Heiles Juergen wrote:
> > > >
> > > > Manoj,
> > > >
> > > > this has nothing to do with forwarding adjacency. It is a 
>restriction of
> > >the transport plane. A VC-4 cannot be transported in a VC-4-64c. A 
>VC-4-64c
> > >supports IP, ATM, Ethernet as client signal, but not a VC-4 or
> > >VC-3/2/12/11.
> > > > So you can have a VC-4-64c forwarding adjacency for IP, ATM or 
>Ethernet
> > >clients.
> > > >
> > > > Juergen
> > > >
> > > > > -----Ursprüngliche Nachricht-----
> > > > > Von: manoj juneja [mailto:[email-masked]]
> > > > > Gesendet: Mittwoch, 5. Dezember 2001 19:49
> > > > > An: [email-masked]; [email-masked]
> > > > > Betreff: Re: AW: VC-4-64c as forwarding adjacency
> > > > >
> > > > >
> > > > > Hi Juergen,
> > > > >             Does this mean the forwarding adjacency concept is not
> > > > > applicable to concatenated signals/LSPs ? I hope forwarding
> > > > > adjacecny of
> > > > > virtual concatenated LSP should be allowed.
> > > > >
> > > > > Regards,
> > > > > manoj.
> > > > >
> > > > >
> > > > > >From: "Juergen Heiles" <[email-masked]>
> > > > > >To: "'manoj juneja'" <[email-masked]>,
> > > > > <[email-masked]>
> > > > > >Subject: AW: VC-4-64c as forwarding adjacency
> > > > > >Date: Wed, 5 Dec 2001 10:19:03 +0100
> > > > > >
> > > > > >No, that is not possible as you cannot transport a VC-4 in a
> > > > > VC-4-64c. A
> > > > > >VC-4-64c only supports dat clients like ATM, IP, Ethernet.
> > > > > >
> > > > > >Juergen
> > > > > >
> > > > > > > -----Ursprüngliche Nachricht-----
> > > > > > > Von: manoj juneja [mailto:[email-masked]]
> > > > > > > Gesendet: Dienstag, 4. Dezember 2001 23:44
> > > > > > > An: [email-masked]
> > > > > > > Betreff: VC-4-64c as forwarding adjacency
> > > > > > >
> > > > > > >
> > > > > > > Hi All,
> > > > > > >          Can I tunnel a request for VC-4 LSP on VC-4-64c
> > > > > forwarding
> > > > > > > adjacency ? If yes, then what would be the {suklm} ?
> > > > > > >
> > > > > > > Regards,
> > > > > > > manoj
> > > > > > >
> > > > > > > 
>_________________________________________________________________
> > > > > > > Get your FREE download of MSN Explorer at
> > > > > > > http://explorer.msn.com/intl.asp
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > _________________________________________________________________
> > > > > Get your FREE download of MSN Explorer at
> > > > http://explorer.msn.com/intl.asp
> > ><< mvissers.vcf >>
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at 
>http://explorer.msn.com/intl.asp
><< mvissers.vcf >>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Fri, 07 Dec 2001 09:55:33 -0800
From: Jonathan Lang <[email-masked]>
To: 'Maarten Vissers' <[email-masked]>, manoj juneja <[email-masked]>
Cc: [email-masked]
Subject: RE: Fwd: LSC Interface Doubt ...
Date: Fri, 7 Dec 2001 09:46:14 -0800 

Maarten,
  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Friday, December 07, 2001 1:30 AM
> To: manoj juneja
> Cc: [email-masked]
> Subject: Re: Fwd: LSC Interface Doubt ...
> 
> 
> Manoj,
> 
> Are you aware that a PXC can be operated as an ODUk switch or 
> a STM/OC-N switch in addition to an OCh switch?
> 
> The PXC is a name for an optical fabric equipment. As fabrics are typical
more
> transparent than the connected line/trib ports, those latter determine the
> switching type. E.g. a PXC connected to optical line systems including
> transponders will not operate at wavelenght level. 
A clarification here is needed.  I agree that a PXC with integrated
transponders can be TDM capable.  However, if the OLS is a separate piece of
equipment (most likely not speaking GMPLS), then from a GMPLS perspective,
the PXC is doing wavelength switching.  Granted the wavelengths actually
being switched may all be the same wavelength (e.g., 1310), but they are
still wavelength switched.

> The transponders have
> terminated the wavelengths. Such combination will switch ODUk and/or
STM/OC-N
> signals. For the case the line systems do not have transponders, the PXC
> operates as true OCh (i.e. wavelength) switch.
agreed, this is an example of 15xx wavelength switching.

> 
> Most line systems in the core network today deploy 10G wavelengths,
whereas many
> service signals are at 2G5 level. Therefore, the transponders in the line
system
> may include 4:1 TDM multiplex circuits. With future 40G wavelengths, there
will
> be 16:1 TDM mux circuits (case of 2G5 services) and 4:1 TDM mux circuits
(case
> of 10G services). Here it is more obvious that the PXC doesn't switch
"wavelengths".
I don't see the difference here (except higher rates) from the first
example.  Again,
if the PXC is speaking GMPLS, the PXC can be considered to be doing
wavelength switching since it is switching (e.g., 1310) wavelengths
transparently.

> 
> Therefore LSC for me is limited to true G.709 OCh switching; i.e. when no
> transponders are present around the fabric.
This is not the definition in GMPLS.

> 
> Regards,
> 
> Maarten
> 
> manoj juneja wrote:
> > 
> > Hi Marteen,
> >             I refer to LSC interface as defined in GMPLS architecture
> > document (i.e. interface which switch data based on the wavelength on
> > which the data is received e.g. PXC or OXC which operate at the level
> > of individual wavelength). I don't think it has any thing to do with
> > Och (G.709).
> > 
> > Regards,
> > manoj.
> > 
> > >From: Maarten Vissers <[email-masked]>
> > >To: manoj juneja <[email-masked]>
> > >CC: [email-masked]
> > >Subject: Re: Fwd: LSC Interface Doubt ...
> > >Date: Thu, 06 Dec 2001 11:42:02 +0100
> > >
> > >Manoj,
> > >
> > >I assume you refer to G.709 OCh connections when you use the term "LSC
> > >LSP". If
> > >so, then a bi-directional OCh link connection will use the same OCh
> > >tributary
> > >slot in both directions; i.e. the same wavelenght is used for go and
return
> > >direction.
> > >
> > >Regards,
> > >
> > >Maarten
> > >
> > >manoj juneja wrote:
> > > >
> > > > Hi All,
> > > >         If I need to establish a bi-directional LSC LSP then do I
> > > > need to configure the remote end wavelengths on an LSC interface ?
> > > > Is there any case where both the upstream and downstream labels of
an
> > > > bi-directional LSC LSP be same ?
> > > >
> > > > Regards,
> > > > manoj.
> > > >
> > > > 
> _________________________________________________________________
> > > > Get your FREE download of MSN Explorer at
> > >http://explorer.msn.com/intl.asp
> > ><< mvissers.vcf >>
> > 
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at 
> http://explorer.msn.com/intl.asp
> 

Delivery-date: Fri, 07 Dec 2001 03:49:58 -0800
Date: Fri, 07 Dec 2001 17:19:38 +0530
From: S Ramesh <[email-masked]>
Organization: HCL Technologies Limited
To: Jonathan Lang <[email-masked]>
CC: "'Murugan .A'" <[email-masked]>, [email-masked]
Subject: Re: [IP-Optical] LMP: Link verification procedure suggestions.

Hi Jonathan,

Thanks for your kind explanation on this procedure. Finally we have got the
procedure. Also my kind request is can you please
add this explanation in the draft which will be helpful to the reader.

Thanks,
Ramesh
Murugan

---<snipped>---

> This is where you are misunderstanding the process.  If you can only receive
> over one interface at a time, then you need to cycle through your interfaces
> before declaring the test failed.  Hence, the VerifyDeadInterval must be
> long enough for you to check all potential data links.  This is why the
> receiver determines the VerifyDeadInterval.

-----<snipped>----

Delivery-date: Fri, 07 Dec 2001 02:15:56 -0800
Cc: [email-masked]
Date: Fri, 07 Dec 2001 11:15:18 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Sergio Belotti <[email-masked]>
Original-CC: [email-masked]
Subject: Re: Lambda LSP Forwarding Adjacency Doubt

This is a multi-part message in MIME format.
--------------3E1F2A8285EEDEDD9ECD7EEE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sergio,

You are correct that the Link Resource Manager (LRM) or Managers get involved. 
When the Routing Controller (RC) has determined the link, the Connection
Controller (CC) will query the associated LRM for a specific link connection
within the link. 
Depending on the "SNPP link case" (refer to 7.3.3/G.8080) the local LRM (LRMA)
can select the link connection independent of far end LRM (LRMZ) (case 1), or
there is negotiation necessary between LRMA and LRMZ to select the link
connection (case 2).

Regards,

Maarten

Sergio Belotti wrote:
> 
> Hello Marteen,
> I read your examples just now and I have only one question regarding the sentence
> referred to the fact that "The ODUk link is created as part of network planning
> and/or (distributed) network engineering" . I agreebut, Shouldn't be a negotiation
> phase between the Link Manager at both side before the CC could be able to perform
> the connection ?
> Thank you
> 
> Sergio
> 
> [email-masked] wrote:
> 
> > Manoj,
> >
> > The transport plane is a multi layer network as described in G.805 and its
> > technology specific recommendations G.803, G.872 and I.326. Each layer network
> > operates independent from each other layer network. Each layer network uses the
> > transport service provided by its server layer networks, and represents this
> > transport service as (G.805) links within its own layer network.
> >
> > In your example with nodes A, B, C and D, nodes A and D could operate on the
> > ODUk layer network (i.e. having an ODUk fabric) and nodes B and C would operate
> > on the OCh layer network (i.e. having an OCh fabric). Nodes A and D may have
> > also OCh fabrics, but this is not necessary; OCh termination points would
> > already be sufficient.
> >
> > Let me give a 3 node example (4 nodes don't fit the page width in this email) in
> > which a STM-N signal is to be transported through A, B and C. At C the STM-N
> > signal leaves the network within an OTM-0.m signal.
> >
> >       node A                    node B                      node C
> >   |<----------->|<------------------------------>|<------------------------->|
> >
> > STM-N ----
> >          |
> >        ------
> >        |ODUk|
> >        |port|
> >        ------
> >          |
> >    --------------                                      --------------------
> >    |   ODUk     |                                      |      ODUk        |
> >    |  Fabric    |                                      |     Fabric       |
> >    --------------                                      --------------------
> >     ||...|....|||                                      |||...|....||...|...
> >        ------                                              ------    ------
> >        |OTUk|                                              |OTUk|    |OTUk|
> >        |OCh |                                              |OCh |    |Och |
> >        |port|                                              |port|    |port|
> >        ------                                              ------    ------
> >          |                                              ||....|...|     |
> >          |          ----------------------------       -------------    |
> >          |          |         OCh              |       |    OCh    |    |
> >          |          |        Fabric            |       |   Fabric  |    |
> >          |          ----------------------------       -------------    |
> >     |||||||||||       |||||||||||   |||||||||            |||||||||      |
> >     -----------       -----------   ---------            ---------   -------
> >     |  OTM-n  |       |  OTM-n  |   | OTM-n |            | OTM-n |   |OTM-0|
> >     |  port   |       |  port   |   | port  |            | port  |   |port |
> >     -----------       -----------   ---------            ---------   -------
> >          |                 |            |                    |          |
> >          |                 |            |                    |          |
> >          -------------------            ----------------------          ------
> >
> > The above network can be represented by means of its ODUk and OCh layer networks
> > as follows:
> >
> >       node A                    node B                      node C
> >   |<----------->|<------------------------------>|<------------------------->|
> >
> > STM-N ----
> >          |
> >        ------
> >        |ODUk|
> >        |port|
> >        ------
> >          |
> >    --------------                                      --------------------
> >    |   ODUk     |                                      |      ODUk        |
> >    |  Fabric    |                                      |     Fabric       |
> >    --------------                                      --------------------
> >    |||| |||||||||                                      ||||||||||  ||||||
> >    |  | |       |                                      |        |  |    |
> >   --  | |       ----------------------------------------        |  |    ------
> >       | |                  ODUk Link                            |  | ODUk Link
> >   ----- ---------------------------------------------------------  -----------
> >
> > As you can see at the ODUk layer network, nodes A and C are neighbors. The
> > intermediate node B is totally invisible. ODUk signalling takes place therefore
> > between nodes A and C. The ODUk Connection Controllers (CC) (refer to G.8080) in
> > nodes A and C are connected with each other via the signalling communication
> > network.
> >
> >          |                                                   |         |
> >        ------                                              ------    ------
> >        |OTUk|                                              |OTUk|    |OTUk|
> >        |OCh |                                              |OCh |    |Och |
> >        |port|                                              |port|    |port|
> >        ------                                              ------    ------
> >          |                                              ||....|...|     |
> >          |          ----------------------------       -------------    |
> >          |          |         OCh              |       |    OCh    |    |
> >          |          |        Fabric            |       |   Fabric  |    |
> >          |          ----------------------------       -------------    |
> >     ||| |||||||       |||||||||     |||||||||            |||||||||    ||||||
> >     | | |     |       |       |     |       |            |       |    |    |
> >   --  | |     ---------       |     |       --------------       |    |    ---
> >       | |     OCh Link        |     |           OCh Link         |    |
> >   ----- -----------------------     ------------------------------    --------
> >
> > As you can see at the OCh layer network, nodes A and B and nodes B and C are
> > neighbors. OCh signalling takes place therefore between nodes A, B and C. The
> > OCh CCs in nodes A, B and C are connected with each other for this purpose via
> > the signalling communication network.
> >
> > In the above 3-node example network, you will be able to setup ODUk connections
> > when the ODUk link is setup first. The ODUk link is created as part of network
> > planning and/or (distributed) network engineering. The ODUk link will exist when
> > one or more OCh trails are setup in the OCh layer network.
> >
> > So when you want to setup an ODUk [i.e. a TDM LSP] connection you can ignore the
> > Lambda level.
> >
> > Same principles apply of course to the SDH/SONET layer networks... i.e. you will
> > have a LOVC/VT layer with LOVC/VT links and a HOVC/STS layer with HOVC/STS
> > links.
> >
> > This multi-layer principle doesn't require to stack labels.
> >
> > Regards,
> >
> > Maarten
> >
> > manoj juneja wrote:
> > >
> > > Hi All,
> > >          If there are 4 nodes say A, B, C and D. There is a Lambda FA
> > > established from A to D and if a new TDM LSP request comes to node A
> > > which is to be tunneled through the already established lambda FA-LSP
> > > then the node A sends the Path/label request message directly to node
> > > D. What label the node D will send back to node A in the RESV/label
> > > mapping message since the FA-LSP is just one label (lambda) ? Does it
> > > mean that all the LSPs which are tunneled through the lambda FA-LSP
> > > will be allocated the same label by node D to node A ?
> > >
> > > Please help.
> > >
> > > Regards,
> > > manoj.
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
--------------3E1F2A8285EEDEDD9ECD7EEE
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------3E1F2A8285EEDEDD9ECD7EEE--

Delivery-date: Fri, 07 Dec 2001 02:01:29 -0800
Cc: [email-masked]
Date: Fri, 07 Dec 2001 11:00:54 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: manoj juneja <[email-masked]>
Original-CC: [email-masked]
Subject: Re: AW: AW: VC-4-64c as forwarding adjacency

This is a multi-part message in MIME format.
--------------7793EECE02FF90D79ABCD0CE
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Manoj,

When the VC-4-64c is used as "FA" it provides e.g. an ATM VP link to the =
ATM VP
layer network. As such, ATM VP signals are being routed via this ATM VP l=
ink
supported by the VC-4-64c trail. So ATM VP labels will be used between no=
des A
and D.

     NE A            NE B                 NE C               NE D
|<---------->|<---------------->|<------------------->|<--------------->|=

    ||||                                                     ||||
ATM VP Fabric                                            ATM VP Fabric
   ||||||                                                 ||||||
  VC-4-64c                                               VC-4-64c
    port                                                   port
     |                                                      |
     |                                                      |
     |         VC-4-64c Fabric      VC-4-64c Fabric         |
     |           |       ||||        ||||       |           |
  STM-64      STM-64    STM-256     STM-256   STM-64      STM-64
   port        port      port        port      port        port
     |           |        |           |         |           |
     -------------        -------------         -------------

When the ATM equipment at A needs a 10G link with the aTM equipment at D,=
 it
requests a regular VC-4-64c connection between A and D. As the connection=

terminates at VC-4-64c ports automatically there is an ATM VP link create=
d. The
ATM VP connection controllers in A and D exchange ATM VP labels to setup =
ATM VP
connections.

When the Vc-4-64c connection had to be setup, the VC-4-64c connection
controllers in A, B, C and D will exchange VC-4-64c labels. =

When the ATM equipment is in a user domain, the interface between nodes A=
 and B
and nodes C and D are UNIs. In that case the VC-4-64c connection controll=
ers in
nodes A and D are replaced by VC-4-64c call controllers. Then the interac=
tions
are between calling/called party call controllers (in nodes A and D) and =
network
call controllers, and network call controller and connection controllers =
in
nodes B and C.

As you see there is no notion of FA needed.

Regards,

Maarten

manoj juneja wrote:
> =

> Hi Marteen,
>             Agreed. VC-4-64c connection can be advertised as a FA and
> can carry IP/ATM or ethernet traffic.
> =

> Now take the case where multiple LSPs are to be tunneled through the
> VC-4-64c connection (FA-LSP).
> What about the label ? What type of label the tail end of VC-4-64c FA
> -LSP i.e. node D will pass to the node A (i.e. head end of vc-4-64c FA
> -LSP) ?
> The LSP encoding and switching types are different for FA-LSP and the
> LSP which is to be tunneled through the FA-LSP.
> =

> Regards,
> manoj.
> =

> >From: Maarten Vissers <[email-masked]>
> >To: "'manoj juneja'" <[email-masked]>
> >CC: [email-masked]
> >Subject: Re: AW: AW: VC-4-64c as forwarding adjacency
> >Date: Thu, 06 Dec 2001 12:24:32 +0100
> >
> >Manoj,
> >
> >In transport terminology I would refer to this as a VC-4-64c trail
> >supporting an
> >IP, ATM or Ethernet link.
> >
> >Regards,
> >
> >Maarten
> >
> >Heiles Juergen wrote:
> > >
> > > Manoj,
> > >
> > > this has nothing to do with forwarding adjacency. It is a restricti=
on of
> >the transport plane. A VC-4 cannot be transported in a VC-4-64c. A VC-=
4-64c
> >supports IP, ATM, Ethernet as client signal, but not a VC-4 or
> >VC-3/2/12/11.
> > > So you can have a VC-4-64c forwarding adjacency for IP, ATM or Ethe=
rnet
> >clients.
> > >
> > > Juergen
> > >
> > > > -----Urspr=FCngliche Nachricht-----
> > > > Von: manoj juneja [mailto:[email-masked]]
> > > > Gesendet: Mittwoch, 5. Dezember 2001 19:49
> > > > An: [email-masked]; [email-masked]
> > > > Betreff: Re: AW: VC-4-64c as forwarding adjacency
> > > >
> > > >
> > > > Hi Juergen,
> > > >             Does this mean the forwarding adjacency concept is no=
t
> > > > applicable to concatenated signals/LSPs ? I hope forwarding
> > > > adjacecny of
> > > > virtual concatenated LSP should be allowed.
> > > >
> > > > Regards,
> > > > manoj.
> > > >
> > > >
> > > > >From: "Juergen Heiles" <[email-masked]>
> > > > >To: "'manoj juneja'" <[email-masked]>,
> > > > <[email-masked]>
> > > > >Subject: AW: VC-4-64c as forwarding adjacency
> > > > >Date: Wed, 5 Dec 2001 10:19:03 +0100
> > > > >
> > > > >No, that is not possible as you cannot transport a VC-4 in a
> > > > VC-4-64c. A
> > > > >VC-4-64c only supports dat clients like ATM, IP, Ethernet.
> > > > >
> > > > >Juergen
> > > > >
> > > > > > -----Urspr=FCngliche Nachricht-----
> > > > > > Von: manoj juneja [mailto:[email-masked]]
> > > > > > Gesendet: Dienstag, 4. Dezember 2001 23:44
> > > > > > An: [email-masked]
> > > > > > Betreff: VC-4-64c as forwarding adjacency
> > > > > >
> > > > > >
> > > > > > Hi All,
> > > > > >          Can I tunnel a request for VC-4 LSP on VC-4-64c
> > > > forwarding
> > > > > > adjacency ? If yes, then what would be the {suklm} ?
> > > > > >
> > > > > > Regards,
> > > > > > manoj
> > > > > >
> > > > > > _____________________________________________________________=
____
> > > > > > Get your FREE download of MSN Explorer at
> > > > > > http://explorer.msn.com/intl.asp
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > _________________________________________________________________=

> > > > Get your FREE download of MSN Explorer at
> > > http://explorer.msn.com/intl.asp
> ><< mvissers.vcf >>
> =

> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.=
asp
--------------7793EECE02FF90D79ABCD0CE
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------7793EECE02FF90D79ABCD0CE--

Delivery-date: Fri, 07 Dec 2001 01:59:01 -0800
From: Heiles Juergen <[email-masked]>
To: "'Maarten Vissers'" <[email-masked]>, manoj juneja <[email-masked]>
Cc: [email-masked]
Subject: RE: Fwd: LSC Interface Doubt ...
Date: Fri, 7 Dec 2001 10:57:29 +0100 

Maarten,

when using the name transponder we should be more specific. In your answer you talk about 3-R transponders which terminate the OCh.
For pure wavelength conversion one could use an analog o-e-o transponder. In this case the OCh (as it is the baseband signal without a wavelength assigned) is not terminated.
Normally when speaking about transponders people mean 3-R transponders as they are most common today.

Juergen

> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Friday, December 07, 2001 10:30 AM
> To: manoj juneja
> Cc: [email-masked]
> Subject: Re: Fwd: LSC Interface Doubt ...
> 
> 
> Manoj,
> 
> Are you aware that a PXC can be operated as an ODUk switch or 
> a STM/OC-N switch
> in addition to an OCh switch?
> 
> The PXC is a name for an optical fabric equipment. As fabrics 
> are typical more
> transparent than the connected line/trib ports, those latter 
> determine the
> switching type. E.g. a PXC connected to optical line systems including
> transponders will not operate at wavelenght level. The 
> transponders have
> terminated the wavelenghts. Such combination will switch ODUk 
> and/or STM/OC-N
> signals. For the case the line systems do not have 
> transponders, the PXC
> operates as true OCh (i.e. wavelength) switch.
> 
> Most line systems in the core network today deploy 10G 
> wavelengths, whereas many
> service signals are at 2G5 level. Therefore, the transponders 
> in the line system
> may include 4:1 TDM multiplex circuits. With future 40G 
> wavelengths, there will
> be 16:1 TDM mux circuits (case of 2G5 services) and 4:1 TDM 
> mux circuits (case
> of 10G services). Here it is more obvious that the PXC doesn't switch
> "wavelenghts".
> 
> Therefore LSC for me is limited to true G.709 OCh switching; 
> i.e. when no
> transponders are present around the fabric.
> 
> Regards,
> 
> Maarten
> 
> manoj juneja wrote:
> > 
> > Hi Marteen,
> >             I refer to LSC interface as defined in GMPLS 
> architecture
> > document (i.e. interface which switch data based on the 
> wavelength on
> > which the data is received e.g. PXC or OXC which operate at 
> the level
> > of individual wavelength). I don't think it has any thing to do with
> > Och (G.709).
> > 
> > Regards,
> > manoj.
> > 
> > >From: Maarten Vissers <[email-masked]>
> > >To: manoj juneja <[email-masked]>
> > >CC: [email-masked]
> > >Subject: Re: Fwd: LSC Interface Doubt ...
> > >Date: Thu, 06 Dec 2001 11:42:02 +0100
> > >
> > >Manoj,
> > >
> > >I assume you refer to G.709 OCh connections when you use 
> the term "LSC
> > >LSP". If
> > >so, then a bi-directional OCh link connection will use the same OCh
> > >tributary
> > >slot in both directions; i.e. the same wavelenght is used 
> for go and return
> > >direction.
> > >
> > >Regards,
> > >
> > >Maarten
> > >
> > >manoj juneja wrote:
> > > >
> > > > Hi All,
> > > >         If I need to establish a bi-directional LSC LSP 
> then do I
> > > > need to configure the remote end wavelengths on an LSC 
> interface ?
> > > > Is there any case where both the upstream and 
> downstream labels of an
> > > > bi-directional LSC LSP be same ?
> > > >
> > > > Regards,
> > > > manoj.
> > > >
> > > > 
> _________________________________________________________________
> > > > Get your FREE download of MSN Explorer at
> > >http://explorer.msn.com/intl.asp
> > ><< mvissers.vcf >>
> > 
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at 
http://explorer.msn.com/intl.asp

Delivery-date: Fri, 07 Dec 2001 01:35:53 -0800
Cc: [email-masked]
Date: Fri, 07 Dec 2001 10:29:37 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: manoj juneja <[email-masked]>
Original-CC: [email-masked]
Subject: Re: Fwd: LSC Interface Doubt ...

This is a multi-part message in MIME format.
--------------5AE51935B2C0DF2564A58A73
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Manoj,

Are you aware that a PXC can be operated as an ODUk switch or a STM/OC-N switch
in addition to an OCh switch?

The PXC is a name for an optical fabric equipment. As fabrics are typical more
transparent than the connected line/trib ports, those latter determine the
switching type. E.g. a PXC connected to optical line systems including
transponders will not operate at wavelenght level. The transponders have
terminated the wavelenghts. Such combination will switch ODUk and/or STM/OC-N
signals. For the case the line systems do not have transponders, the PXC
operates as true OCh (i.e. wavelength) switch.

Most line systems in the core network today deploy 10G wavelengths, whereas many
service signals are at 2G5 level. Therefore, the transponders in the line system
may include 4:1 TDM multiplex circuits. With future 40G wavelengths, there will
be 16:1 TDM mux circuits (case of 2G5 services) and 4:1 TDM mux circuits (case
of 10G services). Here it is more obvious that the PXC doesn't switch
"wavelenghts".

Therefore LSC for me is limited to true G.709 OCh switching; i.e. when no
transponders are present around the fabric.

Regards,

Maarten

manoj juneja wrote:
> 
> Hi Marteen,
>             I refer to LSC interface as defined in GMPLS architecture
> document (i.e. interface which switch data based on the wavelength on
> which the data is received e.g. PXC or OXC which operate at the level
> of individual wavelength). I don't think it has any thing to do with
> Och (G.709).
> 
> Regards,
> manoj.
> 
> >From: Maarten Vissers <[email-masked]>
> >To: manoj juneja <[email-masked]>
> >CC: [email-masked]
> >Subject: Re: Fwd: LSC Interface Doubt ...
> >Date: Thu, 06 Dec 2001 11:42:02 +0100
> >
> >Manoj,
> >
> >I assume you refer to G.709 OCh connections when you use the term "LSC
> >LSP". If
> >so, then a bi-directional OCh link connection will use the same OCh
> >tributary
> >slot in both directions; i.e. the same wavelenght is used for go and return
> >direction.
> >
> >Regards,
> >
> >Maarten
> >
> >manoj juneja wrote:
> > >
> > > Hi All,
> > >         If I need to establish a bi-directional LSC LSP then do I
> > > need to configure the remote end wavelengths on an LSC interface ?
> > > Is there any case where both the upstream and downstream labels of an
> > > bi-directional LSC LSP be same ?
> > >
> > > Regards,
> > > manoj.
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at
> >http://explorer.msn.com/intl.asp
> ><< mvissers.vcf >>
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
--------------5AE51935B2C0DF2564A58A73
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------5AE51935B2C0DF2564A58A73--

Delivery-date: Fri, 07 Dec 2001 01:01:38 -0800
Date: Fri, 07 Dec 2001 09:39:49 +0100
From: Sergio Belotti <[email-masked]>
Organization: ALCATEL TND
To: [email-masked]
CC: [email-masked]
Subject: Re: Lambda LSP Forwarding Adjacency Doubt

This is a multi-part message in MIME format.
--------------FF1F6A860B7864600806327D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello Marteen,
I read your examples just now and I have only one question regarding the sentence
referred to the fact that "The ODUk link is created as part of network planning
and/or (distributed) network engineering" . I agreebut, Shouldn't be a negotiation
phase between the Link Manager at both side before the CC could be able to perform
the connection ?
Thank you

Sergio

[email-masked] wrote:

> Manoj,
>
> The transport plane is a multi layer network as described in G.805 and its
> technology specific recommendations G.803, G.872 and I.326. Each layer network
> operates independent from each other layer network. Each layer network uses the
> transport service provided by its server layer networks, and represents this
> transport service as (G.805) links within its own layer network.
>
> In your example with nodes A, B, C and D, nodes A and D could operate on the
> ODUk layer network (i.e. having an ODUk fabric) and nodes B and C would operate
> on the OCh layer network (i.e. having an OCh fabric). Nodes A and D may have
> also OCh fabrics, but this is not necessary; OCh termination points would
> already be sufficient.
>
> Let me give a 3 node example (4 nodes don't fit the page width in this email) in
> which a STM-N signal is to be transported through A, B and C. At C the STM-N
> signal leaves the network within an OTM-0.m signal.
>
>       node A                    node B                      node C
>   |<----------->|<------------------------------>|<------------------------->|
>
> STM-N ----
>          |
>        ------
>        |ODUk|
>        |port|
>        ------
>          |
>    --------------                                      --------------------
>    |   ODUk     |                                      |      ODUk        |
>    |  Fabric    |                                      |     Fabric       |
>    --------------                                      --------------------
>     ||...|....|||                                      |||...|....||...|...
>        ------                                              ------    ------
>        |OTUk|                                              |OTUk|    |OTUk|
>        |OCh |                                              |OCh |    |Och |
>        |port|                                              |port|    |port|
>        ------                                              ------    ------
>          |                                              ||....|...|     |
>          |          ----------------------------       -------------    |
>          |          |         OCh              |       |    OCh    |    |
>          |          |        Fabric            |       |   Fabric  |    |
>          |          ----------------------------       -------------    |
>     |||||||||||       |||||||||||   |||||||||            |||||||||      |
>     -----------       -----------   ---------            ---------   -------
>     |  OTM-n  |       |  OTM-n  |   | OTM-n |            | OTM-n |   |OTM-0|
>     |  port   |       |  port   |   | port  |            | port  |   |port |
>     -----------       -----------   ---------            ---------   -------
>          |                 |            |                    |          |
>          |                 |            |                    |          |
>          -------------------            ----------------------          ------
>
> The above network can be represented by means of its ODUk and OCh layer networks
> as follows:
>
>       node A                    node B                      node C
>   |<----------->|<------------------------------>|<------------------------->|
>
> STM-N ----
>          |
>        ------
>        |ODUk|
>        |port|
>        ------
>          |
>    --------------                                      --------------------
>    |   ODUk     |                                      |      ODUk        |
>    |  Fabric    |                                      |     Fabric       |
>    --------------                                      --------------------
>    |||| |||||||||                                      ||||||||||  ||||||
>    |  | |       |                                      |        |  |    |
>   --  | |       ----------------------------------------        |  |    ------
>       | |                  ODUk Link                            |  | ODUk Link
>   ----- ---------------------------------------------------------  -----------
>
> As you can see at the ODUk layer network, nodes A and C are neighbors. The
> intermediate node B is totally invisible. ODUk signalling takes place therefore
> between nodes A and C. The ODUk Connection Controllers (CC) (refer to G.8080) in
> nodes A and C are connected with each other via the signalling communication
> network.
>
>          |                                                   |         |
>        ------                                              ------    ------
>        |OTUk|                                              |OTUk|    |OTUk|
>        |OCh |                                              |OCh |    |Och |
>        |port|                                              |port|    |port|
>        ------                                              ------    ------
>          |                                              ||....|...|     |
>          |          ----------------------------       -------------    |
>          |          |         OCh              |       |    OCh    |    |
>          |          |        Fabric            |       |   Fabric  |    |
>          |          ----------------------------       -------------    |
>     ||| |||||||       |||||||||     |||||||||            |||||||||    ||||||
>     | | |     |       |       |     |       |            |       |    |    |
>   --  | |     ---------       |     |       --------------       |    |    ---
>       | |     OCh Link        |     |           OCh Link         |    |
>   ----- -----------------------     ------------------------------    --------
>
> As you can see at the OCh layer network, nodes A and B and nodes B and C are
> neighbors. OCh signalling takes place therefore between nodes A, B and C. The
> OCh CCs in nodes A, B and C are connected with each other for this purpose via
> the signalling communication network.
>
> In the above 3-node example network, you will be able to setup ODUk connections
> when the ODUk link is setup first. The ODUk link is created as part of network
> planning and/or (distributed) network engineering. The ODUk link will exist when
> one or more OCh trails are setup in the OCh layer network.
>
> So when you want to setup an ODUk [i.e. a TDM LSP] connection you can ignore the
> Lambda level.
>
> Same principles apply of course to the SDH/SONET layer networks... i.e. you will
> have a LOVC/VT layer with LOVC/VT links and a HOVC/STS layer with HOVC/STS
> links.
>
> This multi-layer principle doesn't require to stack labels.
>
> Regards,
>
> Maarten
>
> manoj juneja wrote:
> >
> > Hi All,
> >          If there are 4 nodes say A, B, C and D. There is a Lambda FA
> > established from A to D and if a new TDM LSP request comes to node A
> > which is to be tunneled through the already established lambda FA-LSP
> > then the node A sends the Path/label request message directly to node
> > D. What label the node D will send back to node A in the RESV/label
> > mapping message since the FA-LSP is just one label (lambda) ? Does it
> > mean that all the LSPs which are tunneled through the lambda FA-LSP
> > will be allocated the same label by node D to node A ?
> >
> > Please help.
> >
> > Regards,
> > manoj.
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

--------------FF1F6A860B7864600806327D
Content-Type: text/x-vcard; charset=us-ascii;
 name="sergio.belotti.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Sergio Belotti
Content-Disposition: attachment;
 filename="sergio.belotti.vcf"

begin:vcard 
n:Belotti;Sergio
tel;fax:Alcanet (2210)4185 or +(39) 039-6864185
tel;home:+(39) 039 6081786
tel;work:Alcanet (2210)3033 or +(39) 039-6863033
x-mozilla-html:FALSE
org:<IMG SRC="http://www.usa.alcatel.com/images/logo/alcatel.gif">;Optics Group
version:2.1
email;internet:[email-masked]
title:Network Management System Design
adr;quoted-printable:;;via Trento 30 =0D=0A;vimercate;Italy;20059;
fn:Sergio Belotti
end:vcard

--------------FF1F6A860B7864600806327D--

Delivery-date: Thu, 06 Dec 2001 23:51:04 -0800
From: Heiles Juergen <[email-masked]>
To: "'manoj juneja'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Fwd: LSC Interface Doubt ...
Date: Fri, 7 Dec 2001 08:49:22 +0100 

Manoj,

that is exactly what the G.709 OCh does.
In addition to the optical signal it has specific overhead functionality (transported via the OSC) assigned.

Juergen

> -----Original Message-----
> From: manoj juneja [mailto:[email-masked]]
> Sent: Thursday, December 06, 2001 7:24 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Fwd: LSC Interface Doubt ...
> 
> 
> Hi Marteen,
>             I refer to LSC interface as defined in GMPLS architecture
> document (i.e. interface which switch data based on the wavelength on
> which the data is received e.g. PXC or OXC which operate at the level
> of individual wavelength). I don't think it has any thing to do with
> Och (G.709).
> 
> Regards,
> manoj.
> 
> 
> >From: Maarten Vissers <[email-masked]>
> >To: manoj juneja <[email-masked]>
> >CC: [email-masked]
> >Subject: Re: Fwd: LSC Interface Doubt ...
> >Date: Thu, 06 Dec 2001 11:42:02 +0100
> >
> >Manoj,
> >
> >I assume you refer to G.709 OCh connections when you use the 
> term "LSC 
> >LSP". If
> >so, then a bi-directional OCh link connection will use the same OCh 
> >tributary
> >slot in both directions; i.e. the same wavelenght is used 
> for go and return
> >direction.
> >
> >Regards,
> >
> >Maarten
> >
> >manoj juneja wrote:
> > >
> > > Hi All,
> > >         If I need to establish a bi-directional LSC LSP then do I
> > > need to configure the remote end wavelengths on an LSC interface ?
> > > Is there any case where both the upstream and downstream 
> labels of an
> > > bi-directional LSC LSP be same ?
> > >
> > > Regards,
> > > manoj.
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at 
> >http://explorer.msn.com/intl.asp
> ><< mvissers.vcf >>
> 
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at 
> http://explorer.msn.com/intl.asp
> 
> 

Delivery-date: Thu, 06 Dec 2001 22:19:13 -0800
Date: Fri, 07 Dec 2001 11:48:01 +0530
From: S Ramesh <[email-masked]>
Organization: HCL Technologies Limited
To: Jonathan Lang <[email-masked]>
CC: "'Murugan .A'" <[email-masked]>, [email-masked]
Subject: Re: [IP-Optical] LMP: Link verification procedure suggestions.

Hi Jonathan,

As you said the Verify Dead interval is for "each" Test message and it is to be
determined by the receiver side, based on the capability of the receiver of Test
message. Agreed.

Now suppose the receiver choosed a large Verify Deadinterval ( since it is going
to listen on a single interface at a time ) and it needs to cycle through the
potential data links ( as you said ). On what basis does it switches , listening
from one interface to the next in the process of cycling through the
interfaces.( since one can be listened at a time ).

If you say that this timeout period is the VerifyDeadinterval for that datalink
means the case what Murugan mentioned is a possible one. How that can be solved
by choosing a large value of VerifyDead Interval.

Now VerifyDeadInterval is the one upto which the sender will send the Test
messages through the same interface. am i right. . But what is the timeout to
listen on a single interface. On what basis the receiver will switch to the next
interface and start lsitening on it. If this timeout is also equal to the
VerifyDeadInterval what is the use of selecting a large value of
VerifyDeadInterval timer. Then the case what Murugan mentioned is always
possible. Kindly clarify me( if possible with the same example of Murugan's).

Thanks,
Ramesh

----<snipped>---

> This is where you are misunderstanding the process.  If you can only receive
> over one interface at a time, then you need to cycle through your interfaces
> before declaring the test failed.  Hence, the VerifyDeadInterval must be
> long enough for you to check all potential data links.  This is why the
> receiver determines the VerifyDeadInterval.
>

---- <snipped>---------

> > > No. The VerifyDeadInterval is set for *each* Test message.
> > This is
> > > configured at the receiving node and indicates that if a
> > Test message is not
> > > seen within the VerifyDeadInterval, the Test procedure has
> > failed for that
> > > data link. In your above example, once the receiver sees a
> > Test message, it
> > > sends a TestStatusSuccess message to the sender.  If
> > instead, the
> > > VerifyDeadInterval is reached without receiving a Test
> > message, A
> > > TestStatusFailure message is sent.  At this point, the
> > sender can transmit a
> > > new Test message down the next data link.

----<snipped>---------

Delivery-date: Thu, 06 Dec 2001 10:55:23 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: AW: AW: VC-4-64c as forwarding adjacency
Date: Thu, 06 Dec 2001 11:49:23 -0700

Hi Marteen,
            Agreed. VC-4-64c connection can be advertised as a FA and
can carry IP/ATM or ethernet traffic.

Now take the case where multiple LSPs are to be tunneled through the 
VC-4-64c connection (FA-LSP).
What about the label ? What type of label the tail end of VC-4-64c FA
-LSP i.e. node D will pass to the node A (i.e. head end of vc-4-64c FA
-LSP) ?
The LSP encoding and switching types are different for FA-LSP and the
LSP which is to be tunneled through the FA-LSP.

Regards,
manoj.

>From: Maarten Vissers <[email-masked]>
>To: "'manoj juneja'" <[email-masked]>
>CC: [email-masked]
>Subject: Re: AW: AW: VC-4-64c as forwarding adjacency
>Date: Thu, 06 Dec 2001 12:24:32 +0100
>
>Manoj,
>
>In transport terminology I would refer to this as a VC-4-64c trail 
>supporting an
>IP, ATM or Ethernet link.
>
>Regards,
>
>Maarten
>
>Heiles Juergen wrote:
> >
> > Manoj,
> >
> > this has nothing to do with forwarding adjacency. It is a restriction of 
>the transport plane. A VC-4 cannot be transported in a VC-4-64c. A VC-4-64c 
>supports IP, ATM, Ethernet as client signal, but not a VC-4 or 
>VC-3/2/12/11.
> > So you can have a VC-4-64c forwarding adjacency for IP, ATM or Ethernet 
>clients.
> >
> > Juergen
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: manoj juneja [mailto:[email-masked]]
> > > Gesendet: Mittwoch, 5. Dezember 2001 19:49
> > > An: [email-masked]; [email-masked]
> > > Betreff: Re: AW: VC-4-64c as forwarding adjacency
> > >
> > >
> > > Hi Juergen,
> > >             Does this mean the forwarding adjacency concept is not
> > > applicable to concatenated signals/LSPs ? I hope forwarding
> > > adjacecny of
> > > virtual concatenated LSP should be allowed.
> > >
> > > Regards,
> > > manoj.
> > >
> > >
> > > >From: "Juergen Heiles" <[email-masked]>
> > > >To: "'manoj juneja'" <[email-masked]>,
> > > <[email-masked]>
> > > >Subject: AW: VC-4-64c as forwarding adjacency
> > > >Date: Wed, 5 Dec 2001 10:19:03 +0100
> > > >
> > > >No, that is not possible as you cannot transport a VC-4 in a
> > > VC-4-64c. A
> > > >VC-4-64c only supports dat clients like ATM, IP, Ethernet.
> > > >
> > > >Juergen
> > > >
> > > > > -----Ursprüngliche Nachricht-----
> > > > > Von: manoj juneja [mailto:[email-masked]]
> > > > > Gesendet: Dienstag, 4. Dezember 2001 23:44
> > > > > An: [email-masked]
> > > > > Betreff: VC-4-64c as forwarding adjacency
> > > > >
> > > > >
> > > > > Hi All,
> > > > >          Can I tunnel a request for VC-4 LSP on VC-4-64c
> > > forwarding
> > > > > adjacency ? If yes, then what would be the {suklm} ?
> > > > >
> > > > > Regards,
> > > > > manoj
> > > > >
> > > > > _________________________________________________________________
> > > > > Get your FREE download of MSN Explorer at
> > > > > http://explorer.msn.com/intl.asp
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at
> > http://explorer.msn.com/intl.asp
><< mvissers.vcf >>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Thu, 06 Dec 2001 10:25:09 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Fwd: LSC Interface Doubt ...
Date: Thu, 06 Dec 2001 11:23:46 -0700

Hi Marteen,
            I refer to LSC interface as defined in GMPLS architecture
document (i.e. interface which switch data based on the wavelength on
which the data is received e.g. PXC or OXC which operate at the level
of individual wavelength). I don't think it has any thing to do with
Och (G.709).

Regards,
manoj.

>From: Maarten Vissers <[email-masked]>
>To: manoj juneja <[email-masked]>
>CC: [email-masked]
>Subject: Re: Fwd: LSC Interface Doubt ...
>Date: Thu, 06 Dec 2001 11:42:02 +0100
>
>Manoj,
>
>I assume you refer to G.709 OCh connections when you use the term "LSC 
>LSP". If
>so, then a bi-directional OCh link connection will use the same OCh 
>tributary
>slot in both directions; i.e. the same wavelenght is used for go and return
>direction.
>
>Regards,
>
>Maarten
>
>manoj juneja wrote:
> >
> > Hi All,
> >         If I need to establish a bi-directional LSC LSP then do I
> > need to configure the remote end wavelengths on an LSC interface ?
> > Is there any case where both the upstream and downstream labels of an
> > bi-directional LSC LSP be same ?
> >
> > Regards,
> > manoj.
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at 
>http://explorer.msn.com/intl.asp
><< mvissers.vcf >>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Thu, 06 Dec 2001 09:35:46 -0800
From: Jonathan Lang <[email-masked]>
To: "'Murugan .A'" <[email-masked]>, [email-masked]
Subject: RE: [IP-Optical] LMP: Link verification procedure suggestions.
Date: Thu, 6 Dec 2001 09:25:35 -0800 

Murugan,
  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: Murugan .A [mailto:[email-masked]]
> Sent: Wednesday, December 05, 2001 11:11 PM
> To: Jonathan Lang; [email-masked]
> Subject: Re: [IP-Optical] LMP: Link verification procedure 
> suggestions.
> 
> 
> Hi Jonathan Lang,
>     When mappings are not known, the procedure to find mappings are not
that straight forward.
>      Some other pocedure over the LMP procedure is needed to find the
mappings, which are not
>     efficient and straight forward(this i have discussed in "IETF:"
section of my earlier mail).
>     Hence i have proposed some changes to LMP procedure itself(this i have
discussed in
>     "My suggestion:"  section in my earlier  mail).
> 
>     Let me take an example where LMP procedure fails.
>     Both sender and receiver are capable of sending and receiving test
messages sequentially ONLY.
>     Let us have 4 interfaces in each side.  Both the nodes dont know the
interface mappings.
> 
>     The internal order in which the sender is going to send test messages
is as follows
>     S_interface_1   (using prefix S to denote sender)
>     S_interface_2
>     S_interface_3
>     S_interface_4
> 
>     The internal order in which the reciver is going to wait
> for receiving  test messages is as follows
>     R_interface_4  (using prefix R to denote Receiver)
>     R_interface_3
>     R_interface_2
>     R_interface_1
> 
>     The  physical connection is as follows( in both directions)
>     S_interface_1    <->    R_interface_1
>     S_interface_2    <->    R_interface_2
>     S_interface_3    <->    R_interface_3
>     S_interface_4    <->    R_interface_4
> 
> Now let us see what happens when testing is started with "Number of Data
Links" set to 4.
> Receiver is waiting in R_interface_4 upto VerifyDeadInterval, but the
sender sends test messages in
> S_interface_1 repearedly.
This is where you are misunderstanding the process.  If you can only receive
over one interface at a time, then you need to cycle through your interfaces
before declaring the test failed.  Hence, the VerifyDeadInterval must be
long enough for you to check all potential data links.  This is why the
receiver determines the VerifyDeadInterval.

>  The physical connection is between "S_interface_1    <->
> R_interface_1"
> At the end of  VerifyDeadInterval the receriver sends
> TestStatusFailure, now the sender will send
> estStatusAck( and move to the second link)..
> The Recever receives TestStatusAck( and move to the next
> link to listen)
> 
> Now The Sender moves to S_interface_2, the receiver moves to
> R_interface_3.
> But the physical conenction  is  between   "S_interface_2
> <->    R_interface_2".
> Hence this also fails.
> 
> Now The Sender moves to S_interface_3, the receiver moves to
> R_interface_2.
> But the physical conenction is  between   "S_interface_3
> <->    R_interface_3".
> Hence this also fails.
> 
> Now The Sender moves to S_interface_4, the receiver moves to
> R_interface_1.
> But the physical conenction is  between   "S_interface_4
> <->    R_interface_4".
> Hence this also fails.
> 
> The sender has received TestStatusFailure for all its four
> interfaces. Similarly the receiver has not received
> test messages in any of the interfaces as per the internal
> ordering in which it waited.
> Mapping is not found for any of the interfaces and the links
> state is down.
> 
> If the internal ordering of sending and receiving test
> messages are configured  as per the physical
> connection then the above procedure succeeds. But this is
> eqivalent to user/"any one"  configuring the interface
> mapping.
> The LMP procedure doesnot find the interface mappings, it
> only check if the interface mappings  provided by the user
> is correct or not
> 
> Let me know if i have missed some thing.
> 
> Thanks,
> Murugan
> Ramesh
> 
> > >Hi,
> > > Giving below the test procedures followed by the IETF
> draft and my
> > suggestions for them.
> > > Both nodes exchange their testing
> capabilites(sequential/simultaneous)
> > through BeginVerify
> > > and BeginVerifyAck.
> > There is no notion of exchanging sequential/simultaneous
> testing
> > capabilities. The protocol is designed to support both
> capabilities without
> > negotiation.
> >
> > >
> > > The local node also sends if it has the interface
> mappings(not know
> > intially) in BeginVerify.
> > > When the mappings are known, if both nodes support's
> simultaneous testing,
> > simultaneous
> > > testing is done.
> > >
> > >If only one node support's simultaneous testing, then
> both nodes do
> > sequential testing with
> > >the know ordering.
> > >
> > >
> > >1) sender testing capability:sequential, receiver testing
> > capability:simultaneous, mappings
> > > are not known.
> > > IETF:
> > > Verification procedure is started with number of links
> to be tested equal
> > to all links in
> > > the TE/data set. Sender sends test message in one of the
> links(as per its
> > internal ordering).
> > > Receiver waits in all the links.
> > >
> > > Receiver may receive test message in just one of the
> links, for all other
> > links it will not
> > > receive test message within VerifyDeadInterval. At the
> end of
> > VerifyDeadInterval the remtoe
> > > node would have send TestStatusSuccess or
> TestStatusFailure for all the
> > links.
> > >
> > > The sender sends TestStatusAck for all the links. The
> verification
> > procedure is completed.
> > >
> > > At the end of this verification procedure mapping is
> found out for only
> > one link(provided
> > > beginVeryAck is received).
> > > The above procedure has to be repeated again and again
> unitl mapping is
> > found for all links.
> > No. The VerifyDeadInterval is set for *each* Test message.
> This is
> > configured at the receiving node and indicates that if a
> Test message is not
> > seen within the VerifyDeadInterval, the Test procedure has
> failed for that
> > data link. In your above example, once the receiver sees a
> Test message, it
> > sends a TestStatusSuccess message to the sender.  If
> instead, the
> > VerifyDeadInterval is reached without receiving a Test
> message, A
> > TestStatusFailure message is sent.  At this point, the
> sender can transmit a
> > new Test message down the next data link.
> >
> > >
> > >My suggestion:
> > > The sender informs the receiving side that it is capable
> of testing
> > sequentially only. It also
> > > informs the remote node that it doesnot have interface
> mappings. Receiver
> > sends BeginVerifyAck,
> > > with VerifyDeadInterval set to "locally configured
> VerifyDeadInterval for
> > single data link"
> > > * "no of links to be tested".
> > > The local node will send test messages in a interface
> sequentially for
> > every verify interval
> > > and the number of retries for an interface will be
> stopped based on local
> > configuration
> > >( retransmission count or timer).
> > >
> > > Remote node is waiting for "VerifyDeadInterval for
> single data link" * "no
> > of links to be
> > > tested" for all interfaces. This time is enough to
> receive test message
> > send in any order
> > > over the links.
> > >
> > > 2) sender testing capability:sequential, receiver
> testing
> > capability:sequential, mappings are
> > > not known.
> > >
> > >IETF:
> > > Not clear how testing is done in this case. Since sender
> follows its own
> > ordering for sending
> > > test messages over different interfaces, where as the
> receiver follows its
> > own ordering
> > > waiting to receive test messages over interfaces. There
> is no correllation
> > of the ordering
> > > between the two.
> > The LMP procedure is the same as I described above.
> >
> > >
> > >My suggestion:
> > > The sender informs the receiving side that it is capable
> of testing
> > sequentially only. It also
> > > informs the remote node that it doesnot have interface
> mappings.
> > >
> > > The receiver also informs the sender that it is capable
> of doing testing
> > sequentially and sets
> > > VerifyDeadInterval to "locally configured
> VerifyDeadInterval for single
> > data link" * "no of
> > > links to be tested".
> > >
> > > Remote node is waiting for "VerifyDeadInterval for
> single data link" * "no
> > of links to be
> > > tested" for one interface. After the end of this period
> it waits in the
> > next interface.
> > >
> > > The local node will send test messages in a interface
> sequentially for
> > every verify interval
> > > and the number of retries for an interface will be
> stopped based on local
> > configuration
> > > ( retransmission count or timer). At the end of this
> period it may know
> > mapping for just
> > > one link. Since the local node know that the remote node
> is only capable
> > of sequential testing
> > > the above procedure has to be repated.
> > >
> > >Thanks,
> > >Murugan
> > >Ramesh
> >
> 
> 

Delivery-date: Thu, 06 Dec 2001 09:35:32 -0800
From: Jonathan Lang <[email-masked]>
To: 'Fugui Wang' <[email-masked]>, "'Murugan .A'" <[email-masked]>, [email-masked]
Subject: RE: [IP-Optical] LMP: Link verification procedure suggestions.
Date: Thu, 6 Dec 2001 09:26:26 -0800 

Fugui,
  Please see my response to Murugan.

Thanks,
jonathan

> -----Original Message-----
> From: Fugui Wang [mailto:[email-masked]]
> Sent: Thursday, December 06, 2001 7:13 AM
> To: 'Murugan .A'; Jonathan Lang; [email-masked]
> Subject: RE: [IP-Optical] LMP: Link verification procedure 
> suggestions.
> 
> 
> I also noticed the problem as Murugan described below. 
> Even worse, the TE link ID mapping could be unknown in
> the BeginVerify (according to the LMP draft, Remote Link
> ID is an optional object for BeginVerify). In such case,
> if the receiver can receive test messages sequentially
> ONLY, then it has to listen all of the data bearing links
> between the neighboring nodes one by one (each for Verify
> Dead Interval) to determine whether it is a TestStatusSuccess
> or a TestStatusFailure.
> 
> Fugui
> 
> -----Original Message-----
> From: Murugan .A [mailto:[email-masked]]
> Sent: Thursday, December 06, 2001 2:11 AM
> To: Jonathan Lang; [email-masked]
> Subject: Re: [IP-Optical] LMP: Link verification procedure 
> suggestions.
> 
> 
> Hi Jonathan Lang,
>     When mappings are not known, the procedure to find
> mappings are not that straight forward.
>      Some other pocedure over the LMP procedure is needed to
> find the mappings, which are not
>     efficient and straight forward(this i have discussed in
> "IETF:" section of my earlier mail).
>     Hence i have proposed some changes to LMP procedure
> itself(this i have discussed in
>     "My suggestion:"  section in my earlier  mail).
> 
>     Let me take an example where LMP procedure fails.
>     Both sender and receiver are capable of sending and
> receiving test messages sequentially ONLY.
>     Let us have 4 interfaces in each side.  Both the nodes
> dont know the interface mappings.
> 
>     The internal order in which the sender is going to send
> test messages is as follows
>     S_interface_1   (using prefix S to denote sender)
>     S_interface_2
>     S_interface_3
>     S_interface_4
> 
>     The internal order in which the reciver is going to wait
> for receiving  test messages is as follows
>     R_interface_4  (using prefix R to denote Receiver)
>     R_interface_3
>     R_interface_2
>     R_interface_1
> 
>     The  physical connection is as follows( in both
> directions)
>     S_interface_1    <->    R_interface_1
>     S_interface_2    <->    R_interface_2
>     S_interface_3    <->    R_interface_3
>     S_interface_4    <->    R_interface_4
> 
> Now let us see what happens when testing is started with
> "Number of Data Links" set to 4.
> Receiver is waiting in R_interface_4 upto
> VerifyDeadInterval, but the sender sends test messages in
> S_interface_1 repearedly.
>  The physical connection is between "S_interface_1    <->
> R_interface_1"
> At the end of  VerifyDeadInterval the receriver sends
> TestStatusFailure, now the sender will send
> estStatusAck( and move to the second link)..
> The Recever receives TestStatusAck( and move to the next
> link to listen)
> 
> Now The Sender moves to S_interface_2, the receiver moves to
> R_interface_3.
> But the physical conenction  is  between   "S_interface_2
> <->    R_interface_2".
> Hence this also fails.
> 
> Now The Sender moves to S_interface_3, the receiver moves to
> R_interface_2.
> But the physical conenction is  between   "S_interface_3
> <->    R_interface_3".
> Hence this also fails.
> 
> Now The Sender moves to S_interface_4, the receiver moves to
> R_interface_1.
> But the physical conenction is  between   "S_interface_4
> <->    R_interface_4".
> Hence this also fails.
> 
> The sender has received TestStatusFailure for all its four
> interfaces. Similarly the receiver has not received
> test messages in any of the interfaces as per the internal
> ordering in which it waited.
> Mapping is not found for any of the interfaces and the links
> state is down.
> 
> If the internal ordering of sending and receiving test
> messages are configured  as per the physical
> connection then the above procedure succeeds. But this is
> eqivalent to user/"any one"  configuring the interface
> mapping.
> The LMP procedure doesnot find the interface mappings, it
> only check if the interface mappings  provided by the user
> is correct or not
> 
> Let me know if i have missed some thing.
> 
> Thanks,
> Murugan
> Ramesh
> 
> > >Hi,
> > > Giving below the test procedures followed by the IETF
> draft and my
> > suggestions for them.
> > > Both nodes exchange their testing
> capabilites(sequential/simultaneous)
> > through BeginVerify
> > > and BeginVerifyAck.
> > There is no notion of exchanging sequential/simultaneous
> testing
> > capabilities. The protocol is designed to support both
> capabilities without
> > negotiation.
> >
> > >
> > > The local node also sends if it has the interface
> mappings(not know
> > intially) in BeginVerify.
> > > When the mappings are known, if both nodes support's
> simultaneous testing,
> > simultaneous
> > > testing is done.
> > >
> > >If only one node support's simultaneous testing, then
> both nodes do
> > sequential testing with
> > >the know ordering.
> > >
> > >
> > >1) sender testing capability:sequential, receiver testing
> > capability:simultaneous, mappings
> > > are not known.
> > > IETF:
> > > Verification procedure is started with number of links
> to be tested equal
> > to all links in
> > > the TE/data set. Sender sends test message in one of the
> links(as per its
> > internal ordering).
> > > Receiver waits in all the links.
> > >
> > > Receiver may receive test message in just one of the
> links, for all other
> > links it will not
> > > receive test message within VerifyDeadInterval. At the
> end of
> > VerifyDeadInterval the remtoe
> > > node would have send TestStatusSuccess or
> TestStatusFailure for all the
> > links.
> > >
> > > The sender sends TestStatusAck for all the links. The
> verification
> > procedure is completed.
> > >
> > > At the end of this verification procedure mapping is
> found out for only
> > one link(provided
> > > beginVeryAck is received).
> > > The above procedure has to be repeated again and again
> unitl mapping is
> > found for all links.
> > No. The VerifyDeadInterval is set for *each* Test message.
> This is
> > configured at the receiving node and indicates that if a
> Test message is not
> > seen within the VerifyDeadInterval, the Test procedure has
> failed for that
> > data link. In your above example, once the receiver sees a
> Test message, it
> > sends a TestStatusSuccess message to the sender.  If
> instead, the
> > VerifyDeadInterval is reached without receiving a Test
> message, A
> > TestStatusFailure message is sent.  At this point, the
> sender can transmit a
> > new Test message down the next data link.
> >
> > >
> > >My suggestion:
> > > The sender informs the receiving side that it is capable
> of testing
> > sequentially only. It also
> > > informs the remote node that it doesnot have interface
> mappings. Receiver
> > sends BeginVerifyAck,
> > > with VerifyDeadInterval set to "locally configured
> VerifyDeadInterval for
> > single data link"
> > > * "no of links to be tested".
> > > The local node will send test messages in a interface
> sequentially for
> > every verify interval
> > > and the number of retries for an interface will be
> stopped based on local
> > configuration
> > >( retransmission count or timer).
> > >
> > > Remote node is waiting for "VerifyDeadInterval for
> single data link" * "no
> > of links to be
> > > tested" for all interfaces. This time is enough to
> receive test message
> > send in any order
> > > over the links.
> > >
> > > 2) sender testing capability:sequential, receiver
> testing
> > capability:sequential, mappings are
> > > not known.
> > >
> > >IETF:
> > > Not clear how testing is done in this case. Since sender
> follows its own
> > ordering for sending
> > > test messages over different interfaces, where as the
> receiver follows its
> > own ordering
> > > waiting to receive test messages over interfaces. There
> is no correllation
> > of the ordering
> > > between the two.
> > The LMP procedure is the same as I described above.
> >
> > >
> > >My suggestion:
> > > The sender informs the receiving side that it is capable
> of testing
> > sequentially only. It also
> > > informs the remote node that it doesnot have interface
> mappings.
> > >
> > > The receiver also informs the sender that it is capable
> of doing testing
> > sequentially and sets
> > > VerifyDeadInterval to "locally configured
> VerifyDeadInterval for single
> > data link" * "no of
> > > links to be tested".
> > >
> > > Remote node is waiting for "VerifyDeadInterval for
> single data link" * "no
> > of links to be
> > > tested" for one interface. After the end of this period
> it waits in the
> > next interface.
> > >
> > > The local node will send test messages in a interface
> sequentially for
> > every verify interval
> > > and the number of retries for an interface will be
> stopped based on local
> > configuration
> > > ( retransmission count or timer). At the end of this
> period it may know
> > mapping for just
> > > one link. Since the local node know that the remote node
> is only capable
> > of sequential testing
> > > the above procedure has to be repated.
> > >
> > >Thanks,
> > >Murugan
> > >Ramesh
> >
> 

Delivery-date: Thu, 06 Dec 2001 08:49:58 -0800
Cc: [email-masked]
Date: Thu, 06 Dec 2001 17:47:39 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Dieter Beller <[email-masked]>
Original-CC: [email-masked]
Subject: Re: AW: AW: VC-4-64c as forwarding adjacency

This is a multi-part message in MIME format.
--------------9C26A6D1F77CA4329B5E0637
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Dieter,

Formally the VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, VC-4-16c/STS-48c,
VC-4-64c/STS-192c and VC-4-256c/STS-768c layer networks are separate laye=
r
networks. And if we do not want any special cases to treat we should admi=
nister
and control those layer networks as separate layer networks.

Nevertheless, in todays SDH/SONET networks the network management systems=

typically control those layer networks as HOVC/STS "layer" (similarly we =
have
the LOVC/VT "layer"). The specific layer network has been more or less co=
nverted
into a signal type parameter.

ASON is layer network based from the functional perspective. But one of t=
he ASON
components, the "protocol controller" can however have a 1:n relation wit=
h other
ASON components. In order to support the HOVC and LOVC "layer" approach, =
one
protocol controller can interact with e.g. VC-3 CC, VC-4 CC, VC-4-4c CC, =
etc.
I.e. the signalling messages from that single protocol controller contain=
 VC-3,
VC-4, VC-4-Xc related information elements. =

Idem for a "LOVC" protocol controller of course.
Whether or not this merging will be done is a matter of HOVC [and LOVC] U=
NI,
E-NNI and I-NNI agreements. =

	Note - Within one vendor's subnetwork, a vendor may make its own =

	decision (there is no interconnect with other vendors's equipment).

	Note - I have proposed to go for HOVC and LOVC "layer" approaches
	in a June and a September contribution to Q.12/15. But, this level of =

	detail didn't fit in the first version of G.8080. It will again be =

	discussed for the next version or a related ASON recommendation.
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/wp3/q12/01=
06/wd20-astn-ln-definition.pdf
	http://ties.itu.int/u/tsg15/sg15/wp3/q12/0109/cd/cd-ason-lna01.doc
	http://ties.itu.int/u/tsg15/sg15/wp3/q12/0109/cd/cd-ason-abc01.doc

Separate from the interface specification, there is the implementation of=

control plane functionality in equipment. ASON specifies a functional
architecture, and it is up to the vendors to implement this functional
architecture. Multiple implementations will exist, some which have merged=
 many
functional components into a single implementation component, others whic=
h are
more 1:1 with the functional architecture. But my feeling is that it is k=
ind of
natural to combine VC-3/4/4-Xc functional components into HOVC implementa=
tion
components (as long as the functional behaviour is supported). And idem f=
or
LOVC.

Combining multiple layer networks into a single "layer" may introduce an
"interworking" item when there is no complete orthogonality. E.g. the VC-=
3 is
part of both LOVC and HOVC "layers". A closer look some time ago revealed=

however that there is no real issue here... I documented this in
http://ties.itu.int/u/tsg15/sg15/wp3/q12/0109/cd/lovc_hovc_ln01.doc
http://ties.itu.int/u/tsg15/sg15/wp3/q12/0109/cd/lovc_hovc_ln01.pdf (if y=
ou do
not have access to ITU-T let me know and I forward file to you)... i.e. i=
f there
is a point in the network where AU3/VC3 signal is continued as TU3/VC3 si=
gnal
(within AU4/VC4), you have a HOVC fabric which is connected via a link to=
 a LOVC
fabric. The HOVC fabric sees this link as a HOVC link supporting only VC-=
3 link
connections, the LOVC fabric sees this link as a LOVC link supporting onl=
y VC-3
link connections.

Similarly, the ODU1, ODU2 and ODU3 layer networks are each others peers w=
ith
respect to the OCh layer network, but these ODUk layer networks have also=

client/server relationships. At the time of writing the June/Sept contrib=
utions
I had the feeling that ODU1, ODU2 and ODU3 should be treated as separate =
layer
networks, and not be combined into an ODUk "layer". At this moment, with =
the
concept of protocol controller, it can be expected that there is one ODUk=

protocol controller supporting ODU1, ODU2 and ODU3 layer network signalli=
ng.

With respect to advertising, I have the feeling that there will be no dif=
ference
between treating HOVC [LOVC, ODUk] layer networks separate or combined. T=
he same
information will be distributed, and the same operations will be possible=
=2E It
seems more a matter of how much of the specific details do we want to sho=
w. E.g.
take the HOVC case with its VC-3 link connections, Vc-4 link connections,=

VC-4-4c link connections, etc. We can describe this set of link connectio=
ns by
means of a set of parallel VC-3 link, VC-4 link, VC-4-4c link, etc. (each=

containing a single link connection type), or by means of a single HOVC l=
ink
(with multiple link connection types). The G.85x.y series uses the former=
 means,
in my correspondence documents in the middle of the year I used the latte=
r means
(
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/wp3/q12/01=
06/wd08-cd-astn-ln01.pdf
).

When we use the former and define separate VC-3, VC-4, etc links we have =
to add
explicit interactions between their Link Resource Managers (LRMs) or yet =
to
define related components to support the ability to change e.g. a group o=
f 4
VC-4 link connections into a single VC-4-4c link connection. When we use =
the
latter and define a combined HOVC link with a single LRM, the change of l=
ink
structure can be taken care of within the single LRM component. But at th=
e end
we won't notice a difference.

Up to so far... still some work to do :-)

Regards,

Maarten

Dieter Beller wrote:
> =

> Maarten,
> =

> I fully share your view concerning the contiguous concatenated
> signal. Moreover, I also read your mail regarding the "Lambda
> LSP Forwarding Adjacency Doubt" where you describe the
> layering of the transport plane.
> =

> Now, I have the question whether e.g. the HOVC layer in SDH
> or SONET which supports multiple signal types (plain VC-4s,
> VC-4-ncs, etc.) should be considered as strictly separated layers
> at the same level, or whether they should rather be considered
> as a single layer supporting multiple services?
> =

> This has of course some implications on routing (e.g. what is
> advertised and which nodes share a Forwarding Adjacency)
> =

> Regards,
> =

> Dieter
> =

> Maarten Vissers wrote:
> =

> > Manoj,
> >
> > In transport terminology I would refer to this as a VC-4-64c trail su=
pporting an
> > IP, ATM or Ethernet link.
> >
> > Regards,
> >
> > Maarten
> >
> > Heiles Juergen wrote:
> > >
> > > Manoj,
> > >
> > > this has nothing to do with forwarding adjacency. It is a restricti=
on of the transport plane. A VC-4 cannot be transported in a VC-4-64c. A =
VC-4-64c supports IP, ATM, Ethernet as client signal, but not a VC-4 or V=
C-3/2/12/11.
> > > So you can have a VC-4-64c forwarding adjacency for IP, ATM or Ethe=
rnet clients.
> > >
> > > Juergen
> > >
> > > > -----Urspr=FCngliche Nachricht-----
> > > > Von: manoj juneja [mailto:[email-masked]]
> > > > Gesendet: Mittwoch, 5. Dezember 2001 19:49
> > > > An: [email-masked]; [email-masked]
> > > > Betreff: Re: AW: VC-4-64c as forwarding adjacency
> > > >
> > > >
> > > > Hi Juergen,
> > > >             Does this mean the forwarding adjacency concept is no=
t
> > > > applicable to concatenated signals/LSPs ? I hope forwarding
> > > > adjacecny of
> > > > virtual concatenated LSP should be allowed.
> > > >
> > > > Regards,
> > > > manoj.
> > > >
> > > >
> > > > >From: "Juergen Heiles" <[email-masked]>
> > > > >To: "'manoj juneja'" <[email-masked]>,
> > > > <[email-masked]>
> > > > >Subject: AW: VC-4-64c as forwarding adjacency
> > > > >Date: Wed, 5 Dec 2001 10:19:03 +0100
> > > > >
> > > > >No, that is not possible as you cannot transport a VC-4 in a
> > > > VC-4-64c. A
> > > > >VC-4-64c only supports dat clients like ATM, IP, Ethernet.
> > > > >
> > > > >Juergen
> > > > >
> > > > > > -----Urspr=FCngliche Nachricht-----
> > > > > > Von: manoj juneja [mailto:[email-masked]]
> > > > > > Gesendet: Dienstag, 4. Dezember 2001 23:44
> > > > > > An: [email-masked]
> > > > > > Betreff: VC-4-64c as forwarding adjacency
> > > > > >
> > > > > >
> > > > > > Hi All,
> > > > > >          Can I tunnel a request for VC-4 LSP on VC-4-64c
> > > > forwarding
> > > > > > adjacency ? If yes, then what would be the {suklm} ?
> > > > > >
> > > > > > Regards,
> > > > > > manoj
> > > > > >
> > > > > > _____________________________________________________________=
____
> > > > > > Get your FREE download of MSN Explorer at
> > > > > > http://explorer.msn.com/intl.asp
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > _________________________________________________________________=

> > > > Get your FREE download of MSN Explorer at
> > > http://explorer.msn.com/intl.asp
--------------9C26A6D1F77CA4329B5E0637
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------9C26A6D1F77CA4329B5E0637--

Delivery-date: Thu, 06 Dec 2001 07:20:44 -0800
From: Fugui Wang <[email-masked]>
To: "'Murugan .A'" <[email-masked]>, Jonathan Lang <[email-masked]>, [email-masked]
Subject: RE: [IP-Optical] LMP: Link verification procedure suggestions.
Date: Thu, 6 Dec 2001 10:12:38 -0500 

I also noticed the problem as Murugan described below. 
Even worse, the TE link ID mapping could be unknown in
the BeginVerify (according to the LMP draft, Remote Link
ID is an optional object for BeginVerify). In such case,
if the receiver can receive test messages sequentially
ONLY, then it has to listen all of the data bearing links
between the neighboring nodes one by one (each for Verify
Dead Interval) to determine whether it is a TestStatusSuccess
or a TestStatusFailure.

Fugui

-----Original Message-----
From: Murugan .A [mailto:[email-masked]]
Sent: Thursday, December 06, 2001 2:11 AM
To: Jonathan Lang; [email-masked]
Subject: Re: [IP-Optical] LMP: Link verification procedure suggestions.

Hi Jonathan Lang,
    When mappings are not known, the procedure to find
mappings are not that straight forward.
     Some other pocedure over the LMP procedure is needed to
find the mappings, which are not
    efficient and straight forward(this i have discussed in
"IETF:" section of my earlier mail).
    Hence i have proposed some changes to LMP procedure
itself(this i have discussed in
    "My suggestion:"  section in my earlier  mail).

    Let me take an example where LMP procedure fails.
    Both sender and receiver are capable of sending and
receiving test messages sequentially ONLY.
    Let us have 4 interfaces in each side.  Both the nodes
dont know the interface mappings.

    The internal order in which the sender is going to send
test messages is as follows
    S_interface_1   (using prefix S to denote sender)
    S_interface_2
    S_interface_3
    S_interface_4

    The internal order in which the reciver is going to wait
for receiving  test messages is as follows
    R_interface_4  (using prefix R to denote Receiver)
    R_interface_3
    R_interface_2
    R_interface_1

    The  physical connection is as follows( in both
directions)
    S_interface_1    <->    R_interface_1
    S_interface_2    <->    R_interface_2
    S_interface_3    <->    R_interface_3
    S_interface_4    <->    R_interface_4

Now let us see what happens when testing is started with
"Number of Data Links" set to 4.
Receiver is waiting in R_interface_4 upto
VerifyDeadInterval, but the sender sends test messages in
S_interface_1 repearedly.
 The physical connection is between "S_interface_1    <->
R_interface_1"
At the end of  VerifyDeadInterval the receriver sends
TestStatusFailure, now the sender will send
estStatusAck( and move to the second link)..
The Recever receives TestStatusAck( and move to the next
link to listen)

Now The Sender moves to S_interface_2, the receiver moves to
R_interface_3.
But the physical conenction  is  between   "S_interface_2
<->    R_interface_2".
Hence this also fails.

Now The Sender moves to S_interface_3, the receiver moves to
R_interface_2.
But the physical conenction is  between   "S_interface_3
<->    R_interface_3".
Hence this also fails.

Now The Sender moves to S_interface_4, the receiver moves to
R_interface_1.
But the physical conenction is  between   "S_interface_4
<->    R_interface_4".
Hence this also fails.

The sender has received TestStatusFailure for all its four
interfaces. Similarly the receiver has not received
test messages in any of the interfaces as per the internal
ordering in which it waited.
Mapping is not found for any of the interfaces and the links
state is down.

If the internal ordering of sending and receiving test
messages are configured  as per the physical
connection then the above procedure succeeds. But this is
eqivalent to user/"any one"  configuring the interface
mapping.
The LMP procedure doesnot find the interface mappings, it
only check if the interface mappings  provided by the user
is correct or not

Let me know if i have missed some thing.

Thanks,
Murugan
Ramesh

> >Hi,
> > Giving below the test procedures followed by the IETF
draft and my
> suggestions for them.
> > Both nodes exchange their testing
capabilites(sequential/simultaneous)
> through BeginVerify
> > and BeginVerifyAck.
> There is no notion of exchanging sequential/simultaneous
testing
> capabilities. The protocol is designed to support both
capabilities without
> negotiation.
>
> >
> > The local node also sends if it has the interface
mappings(not know
> intially) in BeginVerify.
> > When the mappings are known, if both nodes support's
simultaneous testing,
> simultaneous
> > testing is done.
> >
> >If only one node support's simultaneous testing, then
both nodes do
> sequential testing with
> >the know ordering.
> >
> >
> >1) sender testing capability:sequential, receiver testing
> capability:simultaneous, mappings
> > are not known.
> > IETF:
> > Verification procedure is started with number of links
to be tested equal
> to all links in
> > the TE/data set. Sender sends test message in one of the
links(as per its
> internal ordering).
> > Receiver waits in all the links.
> >
> > Receiver may receive test message in just one of the
links, for all other
> links it will not
> > receive test message within VerifyDeadInterval. At the
end of
> VerifyDeadInterval the remtoe
> > node would have send TestStatusSuccess or
TestStatusFailure for all the
> links.
> >
> > The sender sends TestStatusAck for all the links. The
verification
> procedure is completed.
> >
> > At the end of this verification procedure mapping is
found out for only
> one link(provided
> > beginVeryAck is received).
> > The above procedure has to be repeated again and again
unitl mapping is
> found for all links.
> No. The VerifyDeadInterval is set for *each* Test message.
This is
> configured at the receiving node and indicates that if a
Test message is not
> seen within the VerifyDeadInterval, the Test procedure has
failed for that
> data link. In your above example, once the receiver sees a
Test message, it
> sends a TestStatusSuccess message to the sender.  If
instead, the
> VerifyDeadInterval is reached without receiving a Test
message, A
> TestStatusFailure message is sent.  At this point, the
sender can transmit a
> new Test message down the next data link.
>
> >
> >My suggestion:
> > The sender informs the receiving side that it is capable
of testing
> sequentially only. It also
> > informs the remote node that it doesnot have interface
mappings. Receiver
> sends BeginVerifyAck,
> > with VerifyDeadInterval set to "locally configured
VerifyDeadInterval for
> single data link"
> > * "no of links to be tested".
> > The local node will send test messages in a interface
sequentially for
> every verify interval
> > and the number of retries for an interface will be
stopped based on local
> configuration
> >( retransmission count or timer).
> >
> > Remote node is waiting for "VerifyDeadInterval for
single data link" * "no
> of links to be
> > tested" for all interfaces. This time is enough to
receive test message
> send in any order
> > over the links.
> >
> > 2) sender testing capability:sequential, receiver
testing
> capability:sequential, mappings are
> > not known.
> >
> >IETF:
> > Not clear how testing is done in this case. Since sender
follows its own
> ordering for sending
> > test messages over different interfaces, where as the
receiver follows its
> own ordering
> > waiting to receive test messages over interfaces. There
is no correllation
> of the ordering
> > between the two.
> The LMP procedure is the same as I described above.
>
> >
> >My suggestion:
> > The sender informs the receiving side that it is capable
of testing
> sequentially only. It also
> > informs the remote node that it doesnot have interface
mappings.
> >
> > The receiver also informs the sender that it is capable
of doing testing
> sequentially and sets
> > VerifyDeadInterval to "locally configured
VerifyDeadInterval for single
> data link" * "no of
> > links to be tested".
> >
> > Remote node is waiting for "VerifyDeadInterval for
single data link" * "no
> of links to be
> > tested" for one interface. After the end of this period
it waits in the
> next interface.
> >
> > The local node will send test messages in a interface
sequentially for
> every verify interval
> > and the number of retries for an interface will be
stopped based on local
> configuration
> > ( retransmission count or timer). At the end of this
period it may know
> mapping for just
> > one link. Since the local node know that the remote node
is only capable
> of sequential testing
> > the above procedure has to be repated.
> >
> >Thanks,
> >Murugan
> >Ramesh
>

Delivery-date: Thu, 06 Dec 2001 05:25:16 -0800
Date: Thu, 06 Dec 2001 14:19:25 +0100
From: Dieter Beller <[email-masked]>
Organization: Alcatel SEL AG, TND Stuttgart, Germany
To: Maarten Vissers <[email-masked]>
CC: "'manoj juneja'" <[email-masked]>, [email-masked]
Subject: Re: AW: AW: VC-4-64c as forwarding adjacency

This is a multi-part message in MIME format.
--------------EC3A02E86AD8694E2624642E
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Maarten,

I fully share your view concerning the contiguous concatenated
signal. Moreover, I also read your mail regarding the "Lambda
LSP Forwarding Adjacency Doubt" where you describe the
layering of the transport plane.

Now, I have the question whether e.g. the HOVC layer in SDH
or SONET which supports multiple signal types (plain VC-4s,
VC-4-ncs, etc.) should be considered as strictly separated layers
at the same level, or whether they should rather be considered
as a single layer supporting multiple services?

This has of course some implications on routing (e.g. what is
advertised and which nodes share a Forwarding Adjacency)

Regards,

Dieter

Maarten Vissers wrote:

> Manoj,
>
> In transport terminology I would refer to this as a VC-4-64c trail supporting an
> IP, ATM or Ethernet link.
>
> Regards,
>
> Maarten
>
> Heiles Juergen wrote:
> >
> > Manoj,
> >
> > this has nothing to do with forwarding adjacency. It is a restriction of the transport plane. A VC-4 cannot be transported in a VC-4-64c. A VC-4-64c supports IP, ATM, Ethernet as client signal, but not a VC-4 or VC-3/2/12/11.
> > So you can have a VC-4-64c forwarding adjacency for IP, ATM or Ethernet clients.
> >
> > Juergen
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: manoj juneja [mailto:[email-masked]]
> > > Gesendet: Mittwoch, 5. Dezember 2001 19:49
> > > An: [email-masked]; [email-masked]
> > > Betreff: Re: AW: VC-4-64c as forwarding adjacency
> > >
> > >
> > > Hi Juergen,
> > >             Does this mean the forwarding adjacency concept is not
> > > applicable to concatenated signals/LSPs ? I hope forwarding
> > > adjacecny of
> > > virtual concatenated LSP should be allowed.
> > >
> > > Regards,
> > > manoj.
> > >
> > >
> > > >From: "Juergen Heiles" <[email-masked]>
> > > >To: "'manoj juneja'" <[email-masked]>,
> > > <[email-masked]>
> > > >Subject: AW: VC-4-64c as forwarding adjacency
> > > >Date: Wed, 5 Dec 2001 10:19:03 +0100
> > > >
> > > >No, that is not possible as you cannot transport a VC-4 in a
> > > VC-4-64c. A
> > > >VC-4-64c only supports dat clients like ATM, IP, Ethernet.
> > > >
> > > >Juergen
> > > >
> > > > > -----Ursprüngliche Nachricht-----
> > > > > Von: manoj juneja [mailto:[email-masked]]
> > > > > Gesendet: Dienstag, 4. Dezember 2001 23:44
> > > > > An: [email-masked]
> > > > > Betreff: VC-4-64c as forwarding adjacency
> > > > >
> > > > >
> > > > > Hi All,
> > > > >          Can I tunnel a request for VC-4 LSP on VC-4-64c
> > > forwarding
> > > > > adjacency ? If yes, then what would be the {suklm} ?
> > > > >
> > > > > Regards,
> > > > > manoj
> > > > >
> > > > > _________________________________________________________________
> > > > > Get your FREE download of MSN Explorer at
> > > > > http://explorer.msn.com/intl.asp
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at
> > http://explorer.msn.com/intl.asp

--------------EC3A02E86AD8694E2624642E
Content-Type: text/x-vcard; charset=us-ascii;
 name="D.Beller.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dieter Beller
Content-Disposition: attachment;
 filename="D.Beller.vcf"

begin:vcard 
n:Beller;Dieter
tel;fax:+49 711 821 - 42303
tel;work:+49 711 821 - 43125
x-mozilla-html:FALSE
org:Alcatel - Optics Group - Terrestrial Networks Division;US/EA3
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;Alcatel SEL AG,=0D=0ALorenzstrasse 10;Stuttgart;;70435;Germany
fn:Beller, Dieter
end:vcard

--------------EC3A02E86AD8694E2624642E--

Delivery-date: Thu, 06 Dec 2001 03:25:50 -0800
Cc: [email-masked]
Date: Thu, 06 Dec 2001 12:24:32 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: "'manoj juneja'" <[email-masked]>
Original-CC: [email-masked]
Subject: Re: AW: AW: VC-4-64c as forwarding adjacency

This is a multi-part message in MIME format.
--------------768A3E894091DF809F3CFBC6
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Manoj,

In transport terminology I would refer to this as a VC-4-64c trail suppor=
ting an
IP, ATM or Ethernet link.

Regards,

Maarten

Heiles Juergen wrote:
> =

> Manoj,
> =

> this has nothing to do with forwarding adjacency. It is a restriction o=
f the transport plane. A VC-4 cannot be transported in a VC-4-64c. A VC-4=
-64c supports IP, ATM, Ethernet as client signal, but not a VC-4 or VC-3/=
2/12/11.
> So you can have a VC-4-64c forwarding adjacency for IP, ATM or Ethernet=
 clients.
> =

> Juergen
> =

> > -----Urspr=FCngliche Nachricht-----
> > Von: manoj juneja [mailto:[email-masked]]
> > Gesendet: Mittwoch, 5. Dezember 2001 19:49
> > An: [email-masked]; [email-masked]
> > Betreff: Re: AW: VC-4-64c as forwarding adjacency
> >
> >
> > Hi Juergen,
> >             Does this mean the forwarding adjacency concept is not
> > applicable to concatenated signals/LSPs ? I hope forwarding
> > adjacecny of
> > virtual concatenated LSP should be allowed.
> >
> > Regards,
> > manoj.
> >
> >
> > >From: "Juergen Heiles" <[email-masked]>
> > >To: "'manoj juneja'" <[email-masked]>,
> > <[email-masked]>
> > >Subject: AW: VC-4-64c as forwarding adjacency
> > >Date: Wed, 5 Dec 2001 10:19:03 +0100
> > >
> > >No, that is not possible as you cannot transport a VC-4 in a
> > VC-4-64c. A
> > >VC-4-64c only supports dat clients like ATM, IP, Ethernet.
> > >
> > >Juergen
> > >
> > > > -----Urspr=FCngliche Nachricht-----
> > > > Von: manoj juneja [mailto:[email-masked]]
> > > > Gesendet: Dienstag, 4. Dezember 2001 23:44
> > > > An: [email-masked]
> > > > Betreff: VC-4-64c as forwarding adjacency
> > > >
> > > >
> > > > Hi All,
> > > >          Can I tunnel a request for VC-4 LSP on VC-4-64c
> > forwarding
> > > > adjacency ? If yes, then what would be the {suklm} ?
> > > >
> > > > Regards,
> > > > manoj
> > > >
> > > > _________________________________________________________________=

> > > > Get your FREE download of MSN Explorer at
> > > > http://explorer.msn.com/intl.asp
> > > >
> > > >
> > >
> > >
> >
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at
> http://explorer.msn.com/intl.asp
--------------768A3E894091DF809F3CFBC6
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------768A3E894091DF809F3CFBC6--

Delivery-date: Thu, 06 Dec 2001 02:43:21 -0800
Cc: [email-masked]
Date: Thu, 06 Dec 2001 11:42:02 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: manoj juneja <[email-masked]>
Original-CC: [email-masked]
Subject: Re: Fwd: LSC Interface Doubt ...

This is a multi-part message in MIME format.
--------------7D13873BFD9B2A464BC513DD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Manoj,

I assume you refer to G.709 OCh connections when you use the term "LSC LSP". If
so, then a bi-directional OCh link connection will use the same OCh tributary
slot in both directions; i.e. the same wavelenght is used for go and return
direction.

Regards,

Maarten

manoj juneja wrote:
> 
> Hi All,
>         If I need to establish a bi-directional LSC LSP then do I
> need to configure the remote end wavelengths on an LSC interface ?
> Is there any case where both the upstream and downstream labels of an
> bi-directional LSC LSP be same ?
> 
> Regards,
> manoj.
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
--------------7D13873BFD9B2A464BC513DD
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------7D13873BFD9B2A464BC513DD--

Delivery-date: Thu, 06 Dec 2001 02:16:42 -0800
Date: Thu, 06 Dec 2001 11:15:44 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
Subject: Re: Lambda LSP Forwarding Adjacency Doubt

This is a multi-part message in MIME format.
--------------D70300A46D75F7BB4BE71F36
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Manoj,

The transport plane is a multi layer network as described in G.805 and its
technology specific recommendations G.803, G.872 and I.326. Each layer network
operates independent from each other layer network. Each layer network uses the
transport service provided by its server layer networks, and represents this
transport service as (G.805) links within its own layer network.

In your example with nodes A, B, C and D, nodes A and D could operate on the
ODUk layer network (i.e. having an ODUk fabric) and nodes B and C would operate
on the OCh layer network (i.e. having an OCh fabric). Nodes A and D may have
also OCh fabrics, but this is not necessary; OCh termination points would
already be sufficient.

Let me give a 3 node example (4 nodes don't fit the page width in this email) in
which a STM-N signal is to be transported through A, B and C. At C the STM-N
signal leaves the network within an OTM-0.m signal.

      node A			node B			    node C
  |<----------->|<------------------------------>|<------------------------->|

STM-N ----
         |
       ------
       |ODUk|
       |port|
       ------
         |   
   --------------                                      --------------------
   |   ODUk     |                                      |      ODUk        |
   |  Fabric    |                                      |     Fabric       |
   --------------                                      --------------------
    ||...|....|||                                      |||...|....||...|...
       ------                                              ------    ------
       |OTUk|                                              |OTUk|    |OTUk|
       |OCh |                                              |OCh |    |Och |
       |port|                                              |port|    |port|
       ------                                              ------    ------
         |                                              ||....|...|     |
         |          ----------------------------       -------------    |
         |          |         OCh              |       |    OCh    |    |
         |          |        Fabric            |       |   Fabric  |    |
         |          ----------------------------       -------------    |
    |||||||||||       |||||||||||   |||||||||            |||||||||      |
    -----------       -----------   ---------            ---------   -------
    |  OTM-n  |       |  OTM-n  |   | OTM-n |            | OTM-n |   |OTM-0|
    |  port   |       |  port   |   | port  |            | port  |   |port |
    -----------       -----------   ---------            ---------   -------
         |                 |            |                    |          |
         |                 |            |                    |          |
         -------------------            ----------------------          ------

The above network can be represented by means of its ODUk and OCh layer networks
as follows:

      node A			node B			    node C
  |<----------->|<------------------------------>|<------------------------->|

STM-N ----
         |
       ------
       |ODUk|
       |port|
       ------
         |   
   --------------                                      --------------------
   |   ODUk     |                                      |      ODUk        |
   |  Fabric    |                                      |     Fabric       |
   --------------                                      --------------------
   |||| |||||||||                                      ||||||||||  ||||||
   |  | |       |                                      |        |  |    |
  --  | |       ----------------------------------------        |  |    ------
      | |                  ODUk Link                            |  | ODUk Link
  ----- ---------------------------------------------------------  -----------

As you can see at the ODUk layer network, nodes A and C are neighbors. The
intermediate node B is totally invisible. ODUk signalling takes place therefore
between nodes A and C. The ODUk Connection Controllers (CC) (refer to G.8080) in
nodes A and C are connected with each other via the signalling communication
network.

         |                                                   |         |
       ------                                              ------    ------
       |OTUk|                                              |OTUk|    |OTUk|
       |OCh |                                              |OCh |    |Och |
       |port|                                              |port|    |port|
       ------                                              ------    ------
         |                                              ||....|...|     |
         |          ----------------------------       -------------    |
         |          |         OCh              |       |    OCh    |    |
         |          |        Fabric            |       |   Fabric  |    |
         |          ----------------------------       -------------    |
    ||| |||||||       |||||||||     |||||||||            |||||||||    ||||||
    | | |     |       |       |     |       |            |       |    |    |
  --  | |     ---------       |     |       --------------       |    |    ---
      | |     OCh Link        |     |           OCh Link         |    |
  ----- -----------------------     ------------------------------    --------

As you can see at the OCh layer network, nodes A and B and nodes B and C are
neighbors. OCh signalling takes place therefore between nodes A, B and C. The
OCh CCs in nodes A, B and C are connected with each other for this purpose via
the signalling communication network.

In the above 3-node example network, you will be able to setup ODUk connections
when the ODUk link is setup first. The ODUk link is created as part of network
planning and/or (distributed) network engineering. The ODUk link will exist when
one or more OCh trails are setup in the OCh layer network.

So when you want to setup an ODUk [i.e. a TDM LSP] connection you can ignore the
Lambda level.

Same principles apply of course to the SDH/SONET layer networks... i.e. you will
have a LOVC/VT layer with LOVC/VT links and a HOVC/STS layer with HOVC/STS
links.

This multi-layer principle doesn't require to stack labels.

Regards,

Maarten

manoj juneja wrote:
> 
> Hi All,
>          If there are 4 nodes say A, B, C and D. There is a Lambda FA
> established from A to D and if a new TDM LSP request comes to node A
> which is to be tunneled through the already established lambda FA-LSP
> then the node A sends the Path/label request message directly to node
> D. What label the node D will send back to node A in the RESV/label
> mapping message since the FA-LSP is just one label (lambda) ? Does it
> mean that all the LSPs which are tunneled through the lambda FA-LSP
> will be allocated the same label by node D to node A ?
> 
> Please help.
> 
> Regards,
> manoj.
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
--------------D70300A46D75F7BB4BE71F36
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------D70300A46D75F7BB4BE71F36--

Delivery-date: Thu, 06 Dec 2001 00:51:57 -0800
From: Heiles Juergen <[email-masked]>
To: "'manoj juneja'" <[email-masked]>, Heiles Juergen <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: AW: AW: Lambda LSP Forwarding Adjacency Doubt
Date: Thu, 6 Dec 2001 09:43:07 +0100 

Manoj,

I made only a suggestion. As I am not so familiar with FAs may be =
others can comment.

Juergen

> -----Urspr=FCngliche Nachricht-----
> Von: manoj juneja [mailto:[email-masked]]
> Gesendet: Mittwoch, 5. Dezember 2001 19:51
> An: [email-masked]; [email-masked]
> Cc: [email-masked]
> Betreff: Re: AW: Lambda LSP Forwarding Adjacency Doubt
>=20
>=20
> Hi Juergen,
>             The interface Id will be of forwarding adjacency (lambda=20
> Interface id). I have a doubt in label allocation. What label=20
> the node D=20
> will send to node A ?
>=20
> Regards,
> manoj.
>=20
>=20
> >From: "Juergen Heiles" <[email-masked]>
> >To: "'manoj juneja'" <[email-masked]>,=20
> ><[email-masked]>
> >CC: <[email-masked]>
> >Subject: AW: Lambda LSP Forwarding Adjacency Doubt
> >Date: Wed, 5 Dec 2001 10:18:49 +0100
> >
> >For a TDM service you have to consider the specific signal=20
> format, for
> >example SDH or G.709 ODU.
> >I ncase of SDH each LSP (e.g. VC-4, VC-12) has a unique=20
> SUKLM numbering in
> >the lable in additon to the interface ID. If nodes A and D=20
> include TDM and
> >lambda switches the STM-N signal is no longer a interface=20
> (instead the WDM
> >signal is the interface), so I would assume that the ID of=20
> the lambda=20
> >FA-LSP
> >replaces the interface ID.
> >
> >Juergen
> >
> > > -----Urspr=FCngliche Nachricht-----
> > > Von: manoj juneja [mailto:[email-masked]]
> > > Gesendet: Mittwoch, 5. Dezember 2001 00:24
> > > An: [email-masked]
> > > Cc: [email-masked]
> > > Betreff: RE: Lambda LSP Forwarding Adjacency Doubt
> > >
> > >
> > > Hi Debashis,
> > >             In my example, A and D nodes are TDM and lambda =
switch
> > > capable but nodes B and C are lambda switch capable. I=20
> want to tunnel
> > > TDM LSP through the lambda LSP (established earlier and
> > > advertised as a
> > > FA). My question was how the label allocation be done at node
> > > D ? Is it
> > > that for all the incoming TDM LSPs requests that need to=20
> be tunneled
> > > through same lambda FA-LSP be assigned the same label at=20
> node D and
> > > sent bck to node A in RESV message ? If no, then how to assign =
the
> > > different labels to different LSPs that are to be=20
> tunneled through the
> > > same lambda FA-LSP.
> > >
> > > I think u are describing the case of how to tunnel LOVC LSP
> > > in HOVC LSP
> > > (HOVC LSP advertised as FA).
> > >
> > > Regards,
> > > manoj.
> > >
> > >
> > > >From: "Basak, Debashis" <[email-masked]>
> > > >To: 'manoj juneja' <[email-masked]>
> > > >CC: "[email-masked]'" <[email-masked]>
> > > >Subject: RE: Lambda LSP Forwarding Adjacency Doubt
> > > >Date: Tue, 4 Dec 2001 17:55:26 -0500
> > > >
> > > >Manoj,
> > > >
> > > >The end points of the lambdapath in your example, nodes A to
> > > D, are capable
> > > >of  establishing TDM services through it. Its probably
> > > better referred as a
> > > >TDM-FA, basically you have created a new TDM link between A
> > > and D. For
> > > >establishing TDM services on the new link, A and D in your
> > > example should
> > > >have a signaling peer relationship setup for the link.
> > > Further TDM services
> > > >would be set up as you would over any TDM link, by
> > > exchanging TDM labels.
> > > >
> > > >-Debashis
> > > >
> > > >Accelight Networks
> > > >
> > > >
> > > >-----Original Message-----
> > > >From: manoj juneja [mailto:[email-masked]]
> > > >Sent: Tuesday, December 04, 2001 3:24 PM
> > > >To: [email-masked]
> > > >Subject: Lambda LSP Forwarding Adjacency Doubt
> > > >
> > > >
> > > >Hi All,
> > > >          If there are 4 nodes say A, B, C and D. There is a
> > > Lambda FA
> > > >established from A to D and if a new TDM LSP request=20
> comes to node A
> > > >which is to be tunneled through the already established=20
> lambda FA-LSP
> > > >then the node A sends the Path/label request message=20
> directly to node
> > > >D. What label the node D will send back to node A in the=20
> RESV/label
> > > >mapping message since the FA-LSP is just one label=20
> (lambda) ? Does it
> > > >mean that all the LSPs which are tunneled through the=20
> lambda FA-LSP
> > > >will be allocated the same label by node D to node A ?
> > > >
> > > >Please help.
> > > >
> > > >Regards,
> > > >manoj.
> > > >
> > > =
>_________________________________________________________________
> > > >Get your FREE download of MSN Explorer at
> > > http://explorer.msn.com/intl.asp
> > > >
> > >
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at
> > > http://explorer.msn.com/intl.asp
> > >
> > >
> >
> >
>=20
>=20
> _________________________________________________________________
> Get your FREE download of MSN Explorer at=20
http://explorer.msn.com/intl.asp

Delivery-date: Thu, 06 Dec 2001 00:31:09 -0800
From: Heiles Juergen <[email-masked]>
To: "'manoj juneja'" <[email-masked]>, Heiles Juergen <[email-masked]>, [email-masked]
Subject: AW: AW: VC-4-64c as forwarding adjacency
Date: Thu, 6 Dec 2001 09:26:06 +0100 

Manoj,

this has nothing to do with forwarding adjacency. It is a restriction =
of the transport plane. A VC-4 cannot be transported in a VC-4-64c. A =
VC-4-64c supports IP, ATM, Ethernet as client signal, but not a VC-4 or =
VC-3/2/12/11.
So you can have a VC-4-64c forwarding adjacency for IP, ATM or Ethernet =
clients.

Juergen

> -----Urspr=FCngliche Nachricht-----
> Von: manoj juneja [mailto:[email-masked]]
> Gesendet: Mittwoch, 5. Dezember 2001 19:49
> An: [email-masked]; [email-masked]
> Betreff: Re: AW: VC-4-64c as forwarding adjacency
>=20
>=20
> Hi Juergen,
>             Does this mean the forwarding adjacency concept is not=20
> applicable to concatenated signals/LSPs ? I hope forwarding=20
> adjacecny of=20
> virtual concatenated LSP should be allowed.
>=20
> Regards,
> manoj.
>=20
>=20
> >From: "Juergen Heiles" <[email-masked]>
> >To: "'manoj juneja'" <[email-masked]>,=20
> <[email-masked]>
> >Subject: AW: VC-4-64c as forwarding adjacency
> >Date: Wed, 5 Dec 2001 10:19:03 +0100
> >
> >No, that is not possible as you cannot transport a VC-4 in a=20
> VC-4-64c. A
> >VC-4-64c only supports dat clients like ATM, IP, Ethernet.
> >
> >Juergen
> >
> > > -----Urspr=FCngliche Nachricht-----
> > > Von: manoj juneja [mailto:[email-masked]]
> > > Gesendet: Dienstag, 4. Dezember 2001 23:44
> > > An: [email-masked]
> > > Betreff: VC-4-64c as forwarding adjacency
> > >
> > >
> > > Hi All,
> > >          Can I tunnel a request for VC-4 LSP on VC-4-64c=20
> forwarding
> > > adjacency ? If yes, then what would be the {suklm} ?
> > >
> > > Regards,
> > > manoj
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at
> > > http://explorer.msn.com/intl.asp
> > >
> > >
> >
> >
>=20
>=20
> _________________________________________________________________
> Get your FREE download of MSN Explorer at=20
http://explorer.msn.com/intl.asp

Delivery-date: Wed, 05 Dec 2001 23:17:18 -0800
From: "Murugan .A" <[email-masked]>
To: "Jonathan Lang" <[email-masked]>, <[email-masked]>
Subject: Re: [IP-Optical] LMP: Link verification procedure suggestions.
Date: Thu, 6 Dec 2001 12:41:21 +0530

Hi Jonathan Lang,
    When mappings are not known, the procedure to find
mappings are not that straight forward.
     Some other pocedure over the LMP procedure is needed to
find the mappings, which are not
    efficient and straight forward(this i have discussed in
"IETF:" section of my earlier mail).
    Hence i have proposed some changes to LMP procedure
itself(this i have discussed in
    "My suggestion:"  section in my earlier  mail).

    Let me take an example where LMP procedure fails.
    Both sender and receiver are capable of sending and
receiving test messages sequentially ONLY.
    Let us have 4 interfaces in each side.  Both the nodes
dont know the interface mappings.

    The internal order in which the sender is going to send
test messages is as follows
    S_interface_1   (using prefix S to denote sender)
    S_interface_2
    S_interface_3
    S_interface_4

    The internal order in which the reciver is going to wait
for receiving  test messages is as follows
    R_interface_4  (using prefix R to denote Receiver)
    R_interface_3
    R_interface_2
    R_interface_1

    The  physical connection is as follows( in both
directions)
    S_interface_1    <->    R_interface_1
    S_interface_2    <->    R_interface_2
    S_interface_3    <->    R_interface_3
    S_interface_4    <->    R_interface_4

Now let us see what happens when testing is started with
"Number of Data Links" set to 4.
Receiver is waiting in R_interface_4 upto
VerifyDeadInterval, but the sender sends test messages in
S_interface_1 repearedly.
 The physical connection is between "S_interface_1    <->
R_interface_1"
At the end of  VerifyDeadInterval the receriver sends
TestStatusFailure, now the sender will send
estStatusAck( and move to the second link)..
The Recever receives TestStatusAck( and move to the next
link to listen)

Now The Sender moves to S_interface_2, the receiver moves to
R_interface_3.
But the physical conenction  is  between   "S_interface_2
<->    R_interface_2".
Hence this also fails.

Now The Sender moves to S_interface_3, the receiver moves to
R_interface_2.
But the physical conenction is  between   "S_interface_3
<->    R_interface_3".
Hence this also fails.

Now The Sender moves to S_interface_4, the receiver moves to
R_interface_1.
But the physical conenction is  between   "S_interface_4
<->    R_interface_4".
Hence this also fails.

The sender has received TestStatusFailure for all its four
interfaces. Similarly the receiver has not received
test messages in any of the interfaces as per the internal
ordering in which it waited.
Mapping is not found for any of the interfaces and the links
state is down.

If the internal ordering of sending and receiving test
messages are configured  as per the physical
connection then the above procedure succeeds. But this is
eqivalent to user/"any one"  configuring the interface
mapping.
The LMP procedure doesnot find the interface mappings, it
only check if the interface mappings  provided by the user
is correct or not

Let me know if i have missed some thing.

Thanks,
Murugan
Ramesh

> >Hi,
> > Giving below the test procedures followed by the IETF
draft and my
> suggestions for them.
> > Both nodes exchange their testing
capabilites(sequential/simultaneous)
> through BeginVerify
> > and BeginVerifyAck.
> There is no notion of exchanging sequential/simultaneous
testing
> capabilities. The protocol is designed to support both
capabilities without
> negotiation.
>
> >
> > The local node also sends if it has the interface
mappings(not know
> intially) in BeginVerify.
> > When the mappings are known, if both nodes support's
simultaneous testing,
> simultaneous
> > testing is done.
> >
> >If only one node support's simultaneous testing, then
both nodes do
> sequential testing with
> >the know ordering.
> >
> >
> >1) sender testing capability:sequential, receiver testing
> capability:simultaneous, mappings
> > are not known.
> > IETF:
> > Verification procedure is started with number of links
to be tested equal
> to all links in
> > the TE/data set. Sender sends test message in one of the
links(as per its
> internal ordering).
> > Receiver waits in all the links.
> >
> > Receiver may receive test message in just one of the
links, for all other
> links it will not
> > receive test message within VerifyDeadInterval. At the
end of
> VerifyDeadInterval the remtoe
> > node would have send TestStatusSuccess or
TestStatusFailure for all the
> links.
> >
> > The sender sends TestStatusAck for all the links. The
verification
> procedure is completed.
> >
> > At the end of this verification procedure mapping is
found out for only
> one link(provided
> > beginVeryAck is received).
> > The above procedure has to be repeated again and again
unitl mapping is
> found for all links.
> No. The VerifyDeadInterval is set for *each* Test message.
This is
> configured at the receiving node and indicates that if a
Test message is not
> seen within the VerifyDeadInterval, the Test procedure has
failed for that
> data link. In your above example, once the receiver sees a
Test message, it
> sends a TestStatusSuccess message to the sender.  If
instead, the
> VerifyDeadInterval is reached without receiving a Test
message, A
> TestStatusFailure message is sent.  At this point, the
sender can transmit a
> new Test message down the next data link.
>
> >
> >My suggestion:
> > The sender informs the receiving side that it is capable
of testing
> sequentially only. It also
> > informs the remote node that it doesnot have interface
mappings. Receiver
> sends BeginVerifyAck,
> > with VerifyDeadInterval set to "locally configured
VerifyDeadInterval for
> single data link"
> > * "no of links to be tested".
> > The local node will send test messages in a interface
sequentially for
> every verify interval
> > and the number of retries for an interface will be
stopped based on local
> configuration
> >( retransmission count or timer).
> >
> > Remote node is waiting for "VerifyDeadInterval for
single data link" * "no
> of links to be
> > tested" for all interfaces. This time is enough to
receive test message
> send in any order
> > over the links.
> >
> > 2) sender testing capability:sequential, receiver
testing
> capability:sequential, mappings are
> > not known.
> >
> >IETF:
> > Not clear how testing is done in this case. Since sender
follows its own
> ordering for sending
> > test messages over different interfaces, where as the
receiver follows its
> own ordering
> > waiting to receive test messages over interfaces. There
is no correllation
> of the ordering
> > between the two.
> The LMP procedure is the same as I described above.
>
> >
> >My suggestion:
> > The sender informs the receiving side that it is capable
of testing
> sequentially only. It also
> > informs the remote node that it doesnot have interface
mappings.
> >
> > The receiver also informs the sender that it is capable
of doing testing
> sequentially and sets
> > VerifyDeadInterval to "locally configured
VerifyDeadInterval for single
> data link" * "no of
> > links to be tested".
> >
> > Remote node is waiting for "VerifyDeadInterval for
single data link" * "no
> of links to be
> > tested" for one interface. After the end of this period
it waits in the
> next interface.
> >
> > The local node will send test messages in a interface
sequentially for
> every verify interval
> > and the number of retries for an interface will be
stopped based on local
> configuration
> > ( retransmission count or timer). At the end of this
period it may know
> mapping for just
> > one link. Since the local node know that the remote node
is only capable
> of sequential testing
> > the above procedure has to be repated.
> >
> >Thanks,
> >Murugan
> >Ramesh
>

Delivery-date: Wed, 05 Dec 2001 15:14:34 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: Re: AW: VC-4-64c as forwarding adjacency
Date: Wed, 05 Dec 2001 16:08:42 -0700

Hi Kireeti,

          I was thinking from the point of view that routing advertisement 
of VC-4-64c as a FA should not be allowed.

Regards,
manoj.

>From: Kireeti Kompella <[email-masked]>
>To: [email-masked], [email-masked],   
>[email-masked]
>Subject: Re: AW: VC-4-64c as forwarding adjacency
>Date: Wed, 5 Dec 2001 15:00:59 -0800 (PST)
>
> >             Does this mean the forwarding adjacency concept is not
> > applicable to concatenated signals/LSPs ?
>
>Instead of misrepresenting FAs, why don't you read Juergen's mail again?
>
>Juergen wrote:
>
> >No, that is not possible as you cannot transport a VC-4 in a VC-4-64c. A
> >VC-4-64c only supports dat clients like ATM, IP, Ethernet.
>
>Nothing to do with FAs.  Everything to do with VC-4-64c, emphasis on c.
>
>Kireeti.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Envelope-to: [email-masked]
Delivery-date: Wed, 05 Dec 2001 15:02:50 -0800
Date: Wed, 5 Dec 2001 15:00:59 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: AW: VC-4-64c as forwarding adjacency

>             Does this mean the forwarding adjacency concept is not 
> applicable to concatenated signals/LSPs ?

Instead of misrepresenting FAs, why don't you read Juergen's mail again?

Juergen wrote:

>No, that is not possible as you cannot transport a VC-4 in a VC-4-64c. A
>VC-4-64c only supports dat clients like ATM, IP, Ethernet.

Nothing to do with FAs.  Everything to do with VC-4-64c, emphasis on c.

Kireeti.

Delivery-date: Wed, 05 Dec 2001 13:09:41 -0800
From: Jonathan Lang <[email-masked]>
To: "'Murugan .A'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: [IP-Optical] LMP: Link verification procedure suggestions.
Date: Wed, 5 Dec 2001 12:56:46 -0800 

Murugan,
Please see inline.  [Note, IPO list clipped to avoid cross-posting.]

Thanks,
Jonathan

-----Original Message-----
From: Murugan .A [mailto:[email-masked]]
Sent: Wednesday, December 05, 2001 5:58 AM
To: [email-masked]; [email-masked]
Cc: MURUGAN AMIRTHALINGAM; [email-masked]
Subject: [IP-Optical] LMP: Link verification procedure suggestions.

>Hi,
> Giving below the test procedures followed by the IETF draft and my
suggestions for them. 
> Both nodes exchange their testing capabilites(sequential/simultaneous)
through BeginVerify
> and BeginVerifyAck.
There is no notion of exchanging sequential/simultaneous testing
capabilities. The protocol is designed to support both capabilities without
negotiation.

>
> The local node also sends if it has the interface mappings(not know
intially) in BeginVerify. 
> When the mappings are known, if both nodes support's simultaneous testing,
simultaneous
> testing is done.
>
>If only one node support's simultaneous testing, then both nodes do
sequential testing with
>the know ordering.
>
>
>1) sender testing capability:sequential, receiver testing
capability:simultaneous, mappings
> are not known.
> IETF:
> Verification procedure is started with number of links to be tested equal
to all links in
> the TE/data set. Sender sends test message in one of the links(as per its
internal ordering). 
> Receiver waits in all the links. 
>
> Receiver may receive test message in just one of the links, for all other
links it will not
> receive test message within VerifyDeadInterval. At the end of
VerifyDeadInterval the remtoe
> node would have send TestStatusSuccess or TestStatusFailure for all the
links. 
>
> The sender sends TestStatusAck for all the links. The verification
procedure is completed. 
>
> At the end of this verification procedure mapping is found out for only
one link(provided 
> beginVeryAck is received).
> The above procedure has to be repeated again and again unitl mapping is
found for all links.
No. The VerifyDeadInterval is set for *each* Test message. This is
configured at the receiving node and indicates that if a Test message is not
seen within the VerifyDeadInterval, the Test procedure has failed for that
data link. In your above example, once the receiver sees a Test message, it
sends a TestStatusSuccess message to the sender.  If instead, the
VerifyDeadInterval is reached without receiving a Test message, A
TestStatusFailure message is sent.  At this point, the sender can transmit a
new Test message down the next data link. 

>
>My suggestion:
> The sender informs the receiving side that it is capable of testing
sequentially only. It also 
> informs the remote node that it doesnot have interface mappings. Receiver
sends BeginVerifyAck,
> with VerifyDeadInterval set to "locally configured VerifyDeadInterval for
single data link"
> * "no of links to be tested".
> The local node will send test messages in a interface sequentially for
every verify interval
> and the number of retries for an interface will be stopped based on local
configuration
>( retransmission count or timer).
>
> Remote node is waiting for "VerifyDeadInterval for single data link" * "no
of links to be
> tested" for all interfaces. This time is enough to receive test message
send in any order
> over the links.
>
> 2) sender testing capability:sequential, receiver testing
capability:sequential, mappings are
> not known.
> 
>IETF:
> Not clear how testing is done in this case. Since sender follows its own
ordering for sending
> test messages over different interfaces, where as the receiver follows its
own ordering
> waiting to receive test messages over interfaces. There is no correllation
of the ordering
> between the two.
The LMP procedure is the same as I described above.

>
>My suggestion:
> The sender informs the receiving side that it is capable of testing
sequentially only. It also
> informs the remote node that it doesnot have interface mappings.
>
> The receiver also informs the sender that it is capable of doing testing
sequentially and sets
> VerifyDeadInterval to "locally configured VerifyDeadInterval for single
data link" * "no of
> links to be tested".
> 
> Remote node is waiting for "VerifyDeadInterval for single data link" * "no
of links to be
> tested" for one interface. After the end of this period it waits in the
next interface.
> 
> The local node will send test messages in a interface sequentially for
every verify interval
> and the number of retries for an interface will be stopped based on local
configuration
> ( retransmission count or timer). At the end of this period it may know
mapping for just
> one link. Since the local node know that the remote node is only capable
of sequential testing
> the above procedure has to be repated.
>
>Thanks,
>Murugan
>Ramesh

Delivery-date: Wed, 05 Dec 2001 10:50:55 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: AW: Lambda LSP Forwarding Adjacency Doubt
Date: Wed, 05 Dec 2001 11:50:37 -0700

Hi Juergen,
            The interface Id will be of forwarding adjacency (lambda 
Interface id). I have a doubt in label allocation. What label the node D 
will send to node A ?

Regards,
manoj.

>From: "Juergen Heiles" <[email-masked]>
>To: "'manoj juneja'" <[email-masked]>, 
><[email-masked]>
>CC: <[email-masked]>
>Subject: AW: Lambda LSP Forwarding Adjacency Doubt
>Date: Wed, 5 Dec 2001 10:18:49 +0100
>
>For a TDM service you have to consider the specific signal format, for
>example SDH or G.709 ODU.
>I ncase of SDH each LSP (e.g. VC-4, VC-12) has a unique SUKLM numbering in
>the lable in additon to the interface ID. If nodes A and D include TDM and
>lambda switches the STM-N signal is no longer a interface (instead the WDM
>signal is the interface), so I would assume that the ID of the lambda 
>FA-LSP
>replaces the interface ID.
>
>Juergen
>
> > -----Ursprüngliche Nachricht-----
> > Von: manoj juneja [mailto:[email-masked]]
> > Gesendet: Mittwoch, 5. Dezember 2001 00:24
> > An: [email-masked]
> > Cc: [email-masked]
> > Betreff: RE: Lambda LSP Forwarding Adjacency Doubt
> >
> >
> > Hi Debashis,
> >             In my example, A and D nodes are TDM and lambda switch
> > capable but nodes B and C are lambda switch capable. I want to tunnel
> > TDM LSP through the lambda LSP (established earlier and
> > advertised as a
> > FA). My question was how the label allocation be done at node
> > D ? Is it
> > that for all the incoming TDM LSPs requests that need to be tunneled
> > through same lambda FA-LSP be assigned the same label at node D and
> > sent bck to node A in RESV message ? If no, then how to assign the
> > different labels to different LSPs that are to be tunneled through the
> > same lambda FA-LSP.
> >
> > I think u are describing the case of how to tunnel LOVC LSP
> > in HOVC LSP
> > (HOVC LSP advertised as FA).
> >
> > Regards,
> > manoj.
> >
> >
> > >From: "Basak, Debashis" <[email-masked]>
> > >To: 'manoj juneja' <[email-masked]>
> > >CC: "[email-masked]'" <[email-masked]>
> > >Subject: RE: Lambda LSP Forwarding Adjacency Doubt
> > >Date: Tue, 4 Dec 2001 17:55:26 -0500
> > >
> > >Manoj,
> > >
> > >The end points of the lambdapath in your example, nodes A to
> > D, are capable
> > >of  establishing TDM services through it. Its probably
> > better referred as a
> > >TDM-FA, basically you have created a new TDM link between A
> > and D. For
> > >establishing TDM services on the new link, A and D in your
> > example should
> > >have a signaling peer relationship setup for the link.
> > Further TDM services
> > >would be set up as you would over any TDM link, by
> > exchanging TDM labels.
> > >
> > >-Debashis
> > >
> > >Accelight Networks
> > >
> > >
> > >-----Original Message-----
> > >From: manoj juneja [mailto:[email-masked]]
> > >Sent: Tuesday, December 04, 2001 3:24 PM
> > >To: [email-masked]
> > >Subject: Lambda LSP Forwarding Adjacency Doubt
> > >
> > >
> > >Hi All,
> > >          If there are 4 nodes say A, B, C and D. There is a
> > Lambda FA
> > >established from A to D and if a new TDM LSP request comes to node A
> > >which is to be tunneled through the already established lambda FA-LSP
> > >then the node A sends the Path/label request message directly to node
> > >D. What label the node D will send back to node A in the RESV/label
> > >mapping message since the FA-LSP is just one label (lambda) ? Does it
> > >mean that all the LSPs which are tunneled through the lambda FA-LSP
> > >will be allocated the same label by node D to node A ?
> > >
> > >Please help.
> > >
> > >Regards,
> > >manoj.
> > >
> > >_________________________________________________________________
> > >Get your FREE download of MSN Explorer at
> > http://explorer.msn.com/intl.asp
> > >
> >
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at
> > http://explorer.msn.com/intl.asp
> >
> >
>
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Wed, 05 Dec 2001 10:49:14 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: Re: AW: VC-4-64c as forwarding adjacency
Date: Wed, 05 Dec 2001 11:48:36 -0700

Hi Juergen,
            Does this mean the forwarding adjacency concept is not 
applicable to concatenated signals/LSPs ? I hope forwarding adjacecny of 
virtual concatenated LSP should be allowed.

Regards,
manoj.

>From: "Juergen Heiles" <[email-masked]>
>To: "'manoj juneja'" <[email-masked]>, <[email-masked]>
>Subject: AW: VC-4-64c as forwarding adjacency
>Date: Wed, 5 Dec 2001 10:19:03 +0100
>
>No, that is not possible as you cannot transport a VC-4 in a VC-4-64c. A
>VC-4-64c only supports dat clients like ATM, IP, Ethernet.
>
>Juergen
>
> > -----Ursprüngliche Nachricht-----
> > Von: manoj juneja [mailto:[email-masked]]
> > Gesendet: Dienstag, 4. Dezember 2001 23:44
> > An: [email-masked]
> > Betreff: VC-4-64c as forwarding adjacency
> >
> >
> > Hi All,
> >          Can I tunnel a request for VC-4 LSP on VC-4-64c forwarding
> > adjacency ? If yes, then what would be the {suklm} ?
> >
> > Regards,
> > manoj
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at
> > http://explorer.msn.com/intl.asp
> >
> >
>
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Wed, 05 Dec 2001 10:46:20 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: RE: Representation of VC-3 in STM-0 in {SUKLM} format
Date: Wed, 05 Dec 2001 11:44:27 -0700

Eric,
       Agreeed. This special case of STM-0 should be mentioned in the 
drafts.

Regards,
manoj.

>From: "Mannie, Eric" <[email-masked]>
>To: 'manoj juneja' <[email-masked]>, 
>[email-masked]
>CC: [email-masked], [email-masked]
>Subject: RE: Representation of VC-3 in STM-0 in {SUKLM} format
>Date: Wed, 5 Dec 2001 19:34:01 +0100
>
>Hi Manoj,
>
>I guess that I could simply write that for STM-0: S = 0 and U = 0.
>
>Since one knows the type of link (e.g. STM-0), you don't need more I think.
>
>About Juergen comments:
>
> >SONET and SDH have similar structures and using
> >different {SUKLM} numbering schemes results in confusion and problems 
>like
> >this that something is missing for one hierarchy.
>
>I'll clarify that at the IETF. The SONET label could be 100% different from
>the SDH label that it would not change anything. There is NO
>need/application for SDH to SONET label translation and vice versa. There 
>is
>no reason to care about having similar formats since there is no need. The
>only reason is for the beauty of the text. However, I am not against a nice
>text, that's why we tried to have a similar label format, however this is
>cosmetic.
>
> >  I haven't seen a final decision concerning the {SUKLM} scheme so I have
> >attached my proposal again.
>
>My personal final decision was to not change it. However, we need to see 
>the
>consensus of the group during the next meeting. In any case, if someone ask
>a modification he/she will have to justify the technical requirements or
>reasons.
>
>Kind regards,
>
>Eric
>
>-----Original Message-----
>From: manoj juneja [mailto:[email-masked]]
>Sent: Wednesday, December 05, 2001 12:43 AM
>To: [email-masked]
>Cc: Mannie, Eric; [email-masked]; [email-masked]
>Subject: RE: Representation of VC-3 in STM-0 in {SUKLM} format
>
>
>Hi All,
>           If STM-0 signal can't be represented using {SUKLM} then
>should not this be removed from the drafts ?
>
>Regards,
>manoj.
>
>
> >From: Heiles Juergen <[email-masked]>
> >To: "'manoj juneja'" <[email-masked]>, [email-masked]
> >Subject: RE: Representation of VC-3 in STM-0 in {SUKLM} format
> >Date: Tue, 20 Nov 2001 09:26:31 +0100
> >
> >Manoj,
> >
> >indeed the STM-0 case is not covered in the current definition. This is 
>one
>
> >of the reasons for my proposed changes to the label definition I did sent
> >out as a last call comment. SONET and SDH have similar structures and 
>using
>
> >different {SUKLM} numbering schemes results in confusion and problems 
>like
> >this that something is missing for one hierarchy.
> >  I haven't seen a final decision concerning the {SUKLM} scheme so I have
> >attached my proposal again.
> >
> >Juergen
> >
> >    The format of the label for SDH and/or SONET TDM-LSR link is:
> >
> >     0                   1                   2                   3
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |               S               |   U   |   K   |   L   |   M   |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >    For SDH, this is an extension of the numbering scheme defined in
> >    G.707 section 7.3, i.e. the (K, L, M) numbering. For SONET, the same
> >    signaling scheme is used in order to provide easy interworking 
>between
> >    SDH and SONET signaling. For the S field a STS-3 group, which
> >    corresponds with the SDH AUG-1 level is introduce. The U field
> >indicates
> >    the position of the STS-3c-SPE or STS-1-SPE within the STS-3 group.
> >
> >    Each letter indicates a possible branch number starting at the
> >    parent node in the multiplex structure. Branches are considered as
> >    numbered in increasing order, starting from the top of the
> >    multiplexing structure. The numbering starts at 1, zero is used to
> >    indicate a non-significant field.
> >
> >    When a field is not significant in a particular context it MUST be
> >    set to zero when transmitted, and MUST be ignored when received.
> >
> >    When hierarchical SDH/SONET LSPs are used, an LSP with a given
> >    bandwidth can be used to tunnel lower order LSPs.  The higher
> >    order SDH/SONET LSP behaves as a virtual link with a given
> >    bandwidth (e.g. VC-3), it may also be used as a Forwarding
> >    Adjacency. A lower order SDH/SONET LSP can be established through
> >    that higher order LSP. Since a label is local to a (virtual) link,
> >    the highest part of that label is non-significant and is set to
> >    zero.
> >
> >    For instance, a VC-3 LSP can be advertised as a forwarding
> >    adjacency. In that case the labels allocated between the two ends
> >    of that LSP (i.e. for that "link") will have S, U and K set to
> >    zero, i.e., non-significant, while L and M will be used to
> >    indicate the signal allocated in that VC-3.
> >
> >      1. S is the index of a particular AUG-1/STS-3 group. S=1->N
> >      indicates a specific AUG-1/STS-3 group inside an STM-N/STS-3xN
> >      multiplex. For example, S=1 indicates the first AUG-1/STS-3 group,
> >      and S=N indicates the last AUG-1/STS-3 group of this multiplex.
> >      S is not significant for STM-0/STS-1.
> >
> >      2. U indicates a specific VC/STS-SPE inside a given AUG-1/STS-3
> >      group or STM-0/STS-1. U=1 indicates a single VC-4/STS-3c-SPE in a
> >      AUG-1/STS-3 group or the single VC-3/STS-1-SPE in a STM-0/STS-1,
> >while U=2->4
> >      indicates a specific VC-3/STS-1-SPE inside the given AUG-1/STS-3
> >      group.
> >
> >      3. K is only significant for VC-4/STS-3c and must be ignored for
> >      higher order VC-3/STS-1-SPE. For SDH it indicates a specific branch
> >of a VC-4.
> >      K=1 indicates that the VC-4 is not further subdivided and
> >      contains a C-4. K=2->4 indicates a specific TUG-3 inside the VC-4.
> >      For a SONET STS-3c-SPE it is fixed to K=1 as SONET doesn't support
> >      substructured STS-3c-SPE.
> >
> >      4. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE.
> >      It is not significant for an unstructured VC-4/STS-3c-SPE. L=1
> >      indicates that the TUG-3/VC-3/STS-1 SPE is not further
> >      subdivided and contains a VC-3/C-3 in SDH or the equivalent in
> >      SONET. L=2->8 indicates a specific TUG-2/VT Group inside the
> >      corresponding higher order signal.
> >
> >      5. M indicates a specific branch of a TUG-2/VT Group. It is not
> >      significant for an unstructured VC-4, STS-3c-SPE, TUG-3, VC-3 or
> >STS-1 SPE.
> >      M=1 indicates that the TUG-2/VT Group is not further subdivided
> >      and contains a VC-2/VT-6 SPE. M=2->3 indicates a specific VT-3
> >      inside the corresponding VT Group, these values MUST NOT be used
> >      for SDH since there is no equivalent of VT-3 with SDH. M=4->6
> >      indicates a specific VC-12/VT-2 SPE inside the corresponding
> >      TUG-2/VT Group. M=7->10 indicates a specific VC-11/VT-1.5 SPE
> >      inside the corresponding TUG-2/VT Group. Note that M=0 denotes
> >      an unstructured VC-4, VC-3 or STS-1 SPE (easy for debugging).
> >
> >
> >       The M encoding is summarized in the following table:
> >
> >           M    SDH                          SONET
> >          ----------------------------------------------------------
> >           0    unstructured VC-4/VC-3  unstructured STS-1 SPE
> >           1    VC-2                    VT-6
> >           2    -                       1st VT-3
> >           3    -                       2nd VT-3
> >           4    1st VC-12               1st VT-2
> >           5    2nd VC-12               2nd VT-2
> >           6    3rd VC-12               3rd VT-2
> >           7    1st VC-11               1st VT-1.5
> >           8    2nd VC-11               2nd VT-1.5
> >           9    3rd VC-11               3rd VT-1.5
> >           10   4th VC-11               4th VT-1.5
> >
> >    In case of contiguous concatenation, the label that is used is the
> >    lowest label of the contiguously concatenated signal as explained
> >    before. The higher part of the label indicates where the signal
> >    starts and the lowest part is not significant. For instance, when
> >    requesting an VC-4-16c the label is S>0, U=0, K=0, L=0, M=0.
> >
> >    Examples of labels:
> >
> >    Example 1: S>0, U=1, K=1, L=0, M=0
> >    Denotes the unstructured VC-4/STS-3c-SPE of the Sth AUG-1/STS-3 
>group.
> >
> >    Example 2: S>0, U=1, K>1, L=1, M=0
> >    Denotes the unstructured VC-3 of the Kth-1 TUG-3 of the Sth AUG-1.
> >
> >    Example 3: S>0, U>1, K=0, L=1, M=0
> >    Denotes the Uth unstructured VC-3/STS-1 SPE of the Sth AUG-1/STS-3
> >group.
> >
> >    Example 4: S>0, U>1, K=0, L>1, M=1
> >    Denotes the VC-2/VT-6 in the Lth-1 TUG2/VT Group in the Uth 
>VC-3/STS-1
> >SPE of the Sth AUG-1/STS-3 group.
> >
> >    Example 5: S>0, U>1, K=0, L>1, M=9
> >    Denotes the 3rd VC-11/VT-1.5 in the Lth-1 TUG2/VT Group in the Uth
> >VC-3/STS-1 SPE of the Sth AUG-1/STS-3 group.
> >
> >    Example 6: S>0, U=1, K>1, L>1, M=5
> >    Denotes the 2nd VC-12 in the Lth-1 TUG2 in the Kth TUG3 in the VC-4 
>of
> >the Sth AUG-1.
> >
> >
> > > -----Original Message-----
> > > From: manoj juneja [mailto:[email-masked]]
> > > Sent: Tuesday, November 20, 2001 1:49 AM
> > > To: [email-masked]
> > > Subject: Representation of VC-3 in STM-0 in {SUKLM} format
> > >
> > >
> > > Hi All,
> > >         If I have to allocate VC-3 on a STM-0 link then how to
> > > represent it in {SUKLM}? As per gmpls-sdh-sonet draft, S is the index
> > > of particular AUG-1 and can take values from 1 -> N. but there is no
> > > AUG-1 in STM-0.
> > >
> > > Regards,
> > > manoj.
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at
> > > http://explorer.msn.com/intl.asp
> > >
> > >
> >
>
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Wed, 05 Dec 2001 09:21:11 -0800
From: "Murugan .A" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Fw: Link verification procedure suggestions(  IETF sequential on both ends)
Date: Wed, 5 Dec 2001 22:47:03 +0530

This is a multi-part message in MIME format.

------=_NextPart_000_0311_01C17DDE.C20DCAA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
       =20
> 2) sender testing capability:sequential, receiver testing =
capability:sequential, mappings are not known.
>
> IETF:
 >         Not clear how testing is done in this case. Since sender =
follows its own ordering for=20
> sending test messages over different interfaces, where as the receiver =
follows its own=20
> ordering waiting to receive test messages over interfaces.=20
> There is no correllation of the ordering between the two.

        With respect to IETF the following procedure can be followed:

    Sender does  verification procedure repeatedly with "Number of Data =
Links" set to one, until it gets a mapping from the remote side or there =
are no more data links in the TE/Data set.  In the sender side for each =
repetetion test message is send on a different data link(as per local =
preference). The receiver will wait on the same data link as per its =
preference.

For the sending side at  the end of this procedure it could have got =
mapping for a single data link.
The above procedure has to be repeated with "Number of Data Links" set =
to TWO, as the remote node will wait  on the first interface for =
VerifyDeadInterval and then wait on the second interface. Because the =
receiver will always follow the same ordering as per its local =
preference for untested links.=20
The sender will send test messages for the remaining data links.

An optimization of the above procedure will be:
        Set the "Number of Data Links"  to number of data links in the =
TE/data set or the number of links to be tested. The sender  will send =
test messages sequentially(based on locally  for the links as per its =
internal ordering. The sender will send test messages in the fist =
interface for the verify interval. Then it will send test messages in =
the second interface.

Once the above procedure is completed the sender will change it local =
internal ordering. This can be done by moving the local interfaces in a =
circular queue by ONE. After this the above procedure will be repeated.

Thanks,
Murugan

------=_NextPart_000_0311_01C17DDE.C20DCAA0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>&gt; 2) =
sender testing=20
capability:sequential, receiver testing capability:sequential, mappings =
are not=20
known.</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&gt; IETF:</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
Not clear=20
how testing is done in this case. Since sender follows its own ordering =
for=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&gt; sending test messages over =
different=20
interfaces,&nbsp;</FONT><FONT face=3DArial size=3D2>where as the =
receiver follows=20
its own </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&gt; ordering&nbsp;waiting to =
receive&nbsp;test=20
messages over interfaces. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&gt; There is no correllation of the =
ordering=20
between the two.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; With=20
respect to IETF the following procedure can be followed:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Sender&nbsp;does  =
verification=20
procedure <FONT face=3DArial size=3D2>repeatedly with "Number of Data =
Links"=20
set&nbsp;to one, until&nbsp;it gets a mapping from the remote side or =
there are=20
no more data links in the TE/Data set.&nbsp; In the sender side for each =

repetetion</FONT></FONT><FONT face=3DArial size=3D2> test message is =
send on a=20
different data link(as per local preference). The receiver will wait on =
the same=20
data link as per its preference.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>For the sending side at&nbsp; the end =
of this=20
procedure it could have got mapping for a single data link.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>The above procedure has to be repeated =
with "Number=20
of Data Links" set&nbsp;to TWO, as the remote node will wait  on the =
first=20
interface for VerifyDeadInterval and then wait on the second interface. =
Because=20
the receiver will always follow the same ordering as per its local =
preference=20
for untested links. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>The sender will send test messages for =
the=20
remaining data links.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>An optimization of the above procedure =
will=20
be:</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Set the=20
"Number of Data Links"  to number of data links in the TE/data set or =
the number=20
of links to be tested. The sender  will send test messages =
sequentially(based on=20
locally&nbsp; for the links as per its internal ordering. The sender =
will send=20
test messages in the fist interface for the verify interval. Then it =
will send=20
test messages in the second interface.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Once the above procedure is completed =
the sender=20
will change it local internal ordering. This can be done by moving the =
local=20
interfaces in a circular queue by ONE. After this the above procedure =
will be=20
repeated.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Murugan</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0311_01C17DDE.C20DCAA0--

Delivery-date: Wed, 05 Dec 2001 06:13:50 -0800
From: "Murugan .A" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: "MURUGAN AMIRTHALINGAM" <[email-masked]>, <[email-masked]>
Subject: LMP: Link verification procedure suggestions.
Date: Wed, 5 Dec 2001 19:27:34 +0530

This is a multi-part message in MIME format.

------=_NextPart_000_0087_01C17DC2.E3D180D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
    Giving below the test procedures  followed by the IETF draft and my =
suggestions for them

.=20
     Both nodes exchange their testing =
capabilites(sequential/simultaneous) through BeginVerify and =
BeginVerifyAck.

    The local node also sends if it has the interface mappings(not know =
intially) in BeginVerify.=20
    When the mappings are known, if both nodes support's simultaneous =
testing, simultaneous testing is done.
    If only one node support's simultaneous testing, then both nodes do =
sequential testing with the know ordering.

1) sender testing capability:sequential, receiver testing =
capability:simultaneous, mappings are not known.
     IETF:
            Verification procedure is started with number of links to be =
tested equal to all links in the TE/data set. Sender sends test message =
in one of the links(as per its internal ordering). Receiver waits in all =
the links. =20
Receiver may receive test message in just one of the links, for all =
other links it will not receive test message within VerifyDeadInterval. =
At the end of VerifyDeadInterval the remtoe node would have send  =
TestStatusSuccess or TestStatusFailure for all the links. The sender =
sends TestStatusAck for all the links. The verification procedure is =
completed.=20

At the end of this verification procedure mapping is found out for only =
one link(provided beginVeryAck is received).
The above  procedure has to be repeated again and again unitl mapping is =
found for all links.

My suggestion:
        The sender informs the receiving side that it is capable of =
testing sequentially only. It also informs the remote node that it =
doesnot have interface mappings. Receiver sends BeginVerifyAck, with =
VerifyDeadInterval  set to "locally configured  VerifyDeadInterval for =
single data link" *  "no of links to be tested".
      The local node will send test messages in a  interface =
sequentially for every verify interval and the number of retries for an =
interface will be stopped based on local configuration( retransmission  =
count or timer).
     Remote node is waiting for "VerifyDeadInterval for single data =
link" * "no of links to be tested" for  all interfaces. This time is =
enough to receive test message send in any order over the links.

2) sender testing capability:sequential, receiver testing =
capability:sequential, mappings are not known.

IETF:
          Not clear how testing is done in this case. Since sender =
follows its own ordering for sending test messages over different =
interfaces, where as the receiver follows its own ordering waiting to =
receive test messages over interfaces. There is no correllation of the =
ordering between the two.

My suggestion:
        The sender informs the receiving side that it is capable of =
testing sequentially only. It also informs the remote node that it =
doesnot have interface mappings.
       The receiver also informs the sender that it is capable of doing =
testing sequentially and sets VerifyDeadInterval to "locally configured  =
VerifyDeadInterval for single data link" * "no of links to be tested".
 =20
      Remote node is waiting for "VerifyDeadInterval for single data =
link" * "no of links to be tested" for one interface. After the end of =
this period it waits in the next interface.
     =20
      The local node will send test messages in a interface sequentially =
for every verify interval and the number of retries for an interface =
will be stopped based on local configuration( retransmission  count or =
timer). At the end of this period it may know mapping for just one link. =
Since the local node know that the remote node is only capable of =
sequential testing the above procedure has to be repated.

Thanks,
Murugan
Ramesh

------=_NextPart_000_0087_01C17DC2.E3D180D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Giving below the =
test=20
procedures&nbsp; followed by the&nbsp;IETF draft and my suggestions for=20
them</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; Both nodes =
exchange their=20
testing capabilites(sequential/simultaneous) through BeginVerify and=20
BeginVerifyAck.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; The local node also =
sends if it=20
has the interface mappings(not know intially) in BeginVerify. =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; When the mappings =
are known, if=20
both nodes support's simultaneous testing, simultaneous testing is=20
done.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; If only one node =
support's=20
simultaneous testing, then both nodes do sequential testing with the =
know=20
ordering.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1) sender testing =
capability:sequential, receiver=20
testing capability:simultaneous, mappings are not known.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;=20
IETF:<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
Verification procedure is started with number of links to be tested =
equal to all=20
links in the TE/data set. Sender sends test message in one of the =
links(as per=20
its internal ordering). Receiver waits&nbsp;in all the links.&nbsp;=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Receiver may receive test message in =
just one of=20
the links, for all other links it will not receive test message within=20
VerifyDeadInterval. At the end of VerifyDeadInterval the remtoe node =
would have=20
send&nbsp; TestStatusSuccess or TestStatusFailure for all the links. The =
sender=20
sends TestStatusAck for all the links. The verification procedure is =
completed.=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>At the end of this verification =
procedure mapping=20
is found out for only one link(provided beginVeryAck is =
received).<BR>The=20
above&nbsp; procedure has to be repeated again and again unitl mapping =
is found=20
for all links.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>My suggestion:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
The sender=20
informs the receiving side that it is capable&nbsp;of testing =
sequentially only.=20
It also in</FONT><FONT face=3DArial size=3D2>forms the remote node that =
it doesnot=20
have&nbsp;interface&nbsp;mappings. Receiver sends BeginVerifyAck, with=20
VerifyDeadInterval&nbsp; set to&nbsp;"locally configured&nbsp;=20
VerifyDeadInterval for single data link"&nbsp;*  "no of links to be=20
tested".</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
local node will=20
send test messages in&nbsp;a =20
interface&nbsp;<STRONG>sequentially&nbsp;</STRONG>for every verify =
interval and=20
the number of </FONT><FONT face=3DArial size=3D2>retries for an =
interface will be=20
stopped based on local configuration(&nbsp;retransmission&nbsp; count or =

timer).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Remote =
node is=20
waiting for "VerifyDeadInterval for single data link"&nbsp;* "no of =
links to be=20
tested"&nbsp;for&nbsp; <STRONG>all interfaces</STRONG>. This time is =
enough to=20
receive test message send in any order over the links.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>2) sender =
testing=20
capability:sequential, receiver testing capability:sequential, mappings =
are not=20
known.</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>IETF:</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Not =
clear how=20
testing is done in this case. Since sender follows its own ordering for =
sending=20
test messages over different interfaces,&nbsp;</FONT><FONT face=3DArial=20
size=3D2>where as the receiver follows its own ordering&nbsp;waiting to=20
receive&nbsp;test messages over interfaces. There is no correllation of =
the=20
ordering between the two.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>My suggestion:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
The sender=20
informs the receiving side that it is capable&nbsp;of testing =
sequentially only.=20
<FONT face=3DArial size=3D2>It also in</FONT><FONT face=3DArial =
size=3D2>forms the=20
remote node that it doesnot=20
have&nbsp;interface&nbsp;mappings.</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
The receiver=20
also informs the sender that it is capable of doing testing=20
sequentially</FONT><FONT face=3DArial size=3D2> and sets=20
VerifyDeadInterval&nbsp;to&nbsp;"locally configured&nbsp; =
VerifyDeadInterval for=20
single data link"&nbsp;* "no of links to be =
tested".</FONT></DIV></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Remote node is=20
waiting for "VerifyDeadInterval for single data link"&nbsp;* "no of =
links to be=20
tested"&nbsp;for <STRONG>one interface. </STRONG>After the end of this =
period it=20
waits in the next interface.</FONT></DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
local node will=20
send test messages in&nbsp;a=20
interface&nbsp;<STRONG>sequentially&nbsp;</STRONG>for every verify =
interval and=20
the number of </FONT><FONT face=3DArial size=3D2>retries for an =
interface will be=20
stopped based on local configuration(&nbsp;retransmission&nbsp; count or =

timer).</FONT></FONT><FONT face=3DArial size=3D2> At the end of this =
period it may=20
know mapping for just one link. Since the local node know that the =
remote node=20
is only capable of sequential testing the above procedure has to be=20
repated.</FONT></DIV></DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks,</DIV>
<DIV>Murugan</DIV>
<DIV>Ramesh</DIV></DIV></DIV></FONT></BODY></HTML>

------=_NextPart_000_0087_01C17DC2.E3D180D0--

Delivery-date: Wed, 05 Dec 2001 03:02:52 -0800
Date: Wed, 05 Dec 2001 12:00:20 +0100
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: Maarten Vissers <[email-masked]>
CC: manoj juneja <[email-masked]>, [email-masked], [email-masked], [email-masked], "Helvoort, Huub van" <[email-masked]>
Subject: Re: Bandwidth modification in GMPLS

This is a multi-part message in MIME format.
--------------1881898109D5420C5A141631
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Maarten,

See in-line...

Maarten Vissers wrote:
> 
> Dimitri,
> 
> I am not comparing the two methods. I am describing how LCAS operates the SEQ
> IDs and how connection management has to support virtual concatenation with
> LCAS. GMPLS is an implementation of distributed connection management, and must
> therefore support what I described.

This is what i was trying to demonstrate (see previous email).
 
> In addition, connection management must support a means to perform the same
> capabilities for the case one or both endpoints do not support LCAS, but allow
> resizing the pipe. The proposal you made in your LBM document is much more
> restrictive than LCAS capable implementations. It is up to the operators to
> decide if these restrictions are acceptable. It is most likely a trade of
> between less restrictions/more complex protocol and more restrictions/less
> complex protocol.

This is a first proposal be sure the next version will be improved.
 
> Personally, I would like to compare two proposals: one that supports all LCAS
> capabilities (except of course the hitless one), the other that includes
> restrictions. If the complexity difference is not too large, go for the full
> capabilities support, otherwise select the one with the restrictions.

Agreed. But one should be in agreement in what we consider by "not too
large"
 
Regards,
- dimitri.

> Regards,
> 
> Maarten
> 
> Dimitri Papadimitriou wrote:
> >
> > Maarten,
> >
> > First for people reading these e-mails the discussion here
> > is not focused on a comparison between LCAS versus something
> > else but only on control plane issues (more precisely which
> > are the GMPLS mechanisms to be provided in order to enable
> > bandwidth modification on different scenarios)
> >
> > Now, to continue the discussion we have defined in the GMPLS
> > LBM I-D the Circuit ID and the LSP Sequence Number for that
> > purpose (see Section 5.2). Together with the following rule:
> >
> > "All LSPs belonging to the same circuit MUST have the same
> > Circuit ID. All LSPs MUST have a unique LSP sequence number
> > in that Circuit ID, the LSP sequence number MUST be the
> > sequence number of the first SPE/VC of the overall virtually
> > concatenated circuit."
> >
> > Therefore, the scenarios you have defined are a combination
> > of the methods described in Section 5.1 and 5.2.
> >
> > To illustrate this, let's take your example back:
> >
> > > Assume the connection controller selects VC-4 SNPs with addresses G1, G2 to
> > > connect to route A, and G3, G4 to connect to route B. G5 to G7 are not connected
> > > VC-4 SNPs.
> > >
> > >         VC-4 with G1    via route A
> > >         VC-4 with G2    via route A
> > >         VC-4 with G3    via route B
> > >         VC-4 with G4    via route B
> > >         VC-4 with G5    not connected
> > >         VC-4 with G6    not connected
> > >         VC-4 with G7    not connected
> >
> > => Circuit ID #1 (for instance) will include LSP SEQ ID#0
> >    and LSP SEQ ID#1 (here we assume that Route A is link
> >    diverse from Route B to preserve generality of the
> >    proposed method)
> >
> > > Assume that the VC-4 trail via G2 is the first one which clears its Signal Fail
> > > (SF) condition, then this trail will pass through the signal with SEQ ID=0. If
> > > the second one is via G4, then this one passes through the signal with SEQ ID=1.
> > > If 3rd is via G3, then this gets SEQ ID=2 and finally via G1 gets SEQ ID=3.
> > >
> > >         VC-4 with G1    via route A             SEQ ID=3
> > >         VC-4 with G2    via route A             SEQ ID=0
> > >         VC-4 with G3    via route B             SEQ ID=2
> > >         VC-4 with G4    via route B             SEQ ID=1
> > >         VC-4 with G5    not connected
> > >         VC-4 with G6    not connected
> > >         VC-4 with G7    not connected
> >
> > => As such LSP SEQ ID#0 corresponds to the SEQ ID=0 and LSP
> >    SEQ ID#1 to the SEQ ID=0
> >
> > > When adding the 5th VC-4 (e.g. via VC-4 SNP G5), this VC-4 will carry SEQ ID #4.
> > >
> > >         VC-4 with G1    via route A             SEQ ID=3
> > >         VC-4 with G2    via route A             SEQ ID=0
> > >         VC-4 with G3    via route B             SEQ ID=2
> > >         VC-4 with G4    via route B             SEQ ID=1
> > >         VC-4 with G5    via route A             SEQ ID=4
> > >         VC-4 with G6    not connected
> > >         VC-4 with G7    not connected
> >
> > => To update the LSP SEQ#0 you follow the rules defined in
> >    the Section 5.1
> >
> > > Now route B fails; i.e. VC-4 with SEQ ID #1 and #2 fail. There will be no change
> > > of SEQ ID, only there will be an indication not to transmit over those VC-4
> > > trails. If later on it is decided to continue over route A only, the SEQ IDs
> > > are adapted as follows:
> > >
> > >         VC-4 with G1    via route A             SEQ ID=1
> > >         VC-4 with G2    via route A             SEQ ID=0
> > >         VC-4 with G3    not connected
> > >         VC-4 with G4    not connected
> > >         VC-4 with G5    via route A             SEQ ID=2
> > >         VC-4 with G6    not connected
> > >         VC-4 with G7    not connected
> >
> > => you delete the VC-4 components with the re-sequencing as described
> >    at the end of the Section 5.1 with the restriction that "SPEs/VCs
> >    can be removed from an LSP but only at the end of that LSP (i.e.
> >    starting at SPE/VC sequence number X)"
> >
> > > If the demand for bandwidth doubles again, it is possible to add say three more
> > > VC-4 trails via e.g. route C (X - C - Y); e.g. via G3, G4 and G6. If the order
> > > those trails become available is G6, G3, G4 then the SEQ IDs will be:
> > >
> > >         VC-4 with G1    via route A             SEQ ID=1
> > >         VC-4 with G2    via route A             SEQ ID=0
> > >         VC-4 with G3    via route C             SEQ ID=4
> > >         VC-4 with G4    via route C             SEQ ID=5
> > >         VC-4 with G5    via route A             SEQ ID=2
> > >         VC-4 with G6    via route C             SEQ ID=3
> > >         VC-4 with G7    not connected
> >
> > => once again you follow the rule described in Section 5.1
> >
> > There is no need to use the multiplier for this purpose (this
> > field is used for instance to operate a change on multiple LSP
> > using the same message - it has been provided to avoid lengthy
> > repetitions of the same operation)
> >
> > Once again (i think that Eric has already provided this comment)
> > the scope of the LSP SEQ ID is not to reproduce the LCAS defined
> > structures within the control plan but to provide a consistent
> > control plane definition (allowing a level of consistency checking
> > between the control plane and the transport plane.)
> >
> > Are we in agreement, or do you want further comparison of both
> > methods ?
> >
> > Regards,
> > - dimitri.
> >
> > Maarten Vissers wrote:
> > >
> > > Dimitri,
> > >
> > > Assume the VC-4-4v signal consisting of 4 VC-4 signals. Each VC-4 signal has a
> > > SEQ ID (0,1,2,3). Which SEQ ID is associated with which VC-4 is not not fixed...
> > > this is under control of LCAS and may change with time...
> > >
> > > When you set up the connection to transport the VC-4-4v signal via two routes
> > > (A, B), two VC-4 termination points will be connected to the A route, two other
> > > to the B route.
> > > There are typically 7 VC-4 termination points per GbE port... let's refer to
> > > those 7 VC-4 termination points by means of SubNetwork Point (SNP) addresses G1
> > > .. G7.
> > >
> > > Assume the connection controller selects VC-4 SNPs with addresses G1, G2 to
> > > connect to route A, and G3, G4 to connect to route B. G5 to G7 are not connected
> > > VC-4 SNPs.
> > >
> > >         VC-4 with G1    via route A
> > >         VC-4 with G2    via route A
> > >         VC-4 with G3    via route B
> > >         VC-4 with G4    via route B
> > >         VC-4 with G5    not connected
> > >         VC-4 with G6    not connected
> > >         VC-4 with G7    not connected
> > >
> > > Assume that the VC-4 trail via G2 is the first one which clears its Signal Fail
> > > (SF) condition, then this trail will pass through the signal with SEQ ID=0. If
> > > the second one is via G4, then this one passes through the signal with SEQ ID=1.
> > > If 3rd is via G3, then this gets SEQ ID=2 and finally via G1 gets SEQ ID=3.
> > >
> > >         VC-4 with G1    via route A             SEQ ID=3
> > >         VC-4 with G2    via route A             SEQ ID=0
> > >         VC-4 with G3    via route B             SEQ ID=2
> > >         VC-4 with G4    via route B             SEQ ID=1
> > >         VC-4 with G5    not connected
> > >         VC-4 with G6    not connected
> > >         VC-4 with G7    not connected
> > >
> > > When adding the 5th VC-4 (e.g. via VC-4 SNP G5), this VC-4 will carry SEQ ID #4.
> > >
> > >         VC-4 with G1    via route A             SEQ ID=3
> > >         VC-4 with G2    via route A             SEQ ID=0
> > >         VC-4 with G3    via route B             SEQ ID=2
> > >         VC-4 with G4    via route B             SEQ ID=1
> > >         VC-4 with G5    via route A             SEQ ID=4
> > >         VC-4 with G6    not connected
> > >         VC-4 with G7    not connected
> > >
> > > Now route B fails; i.e. VC-4 with SEQ ID #1 and #2 fail. There will be no change
> > > of SEQ ID, only there will be an indication not to transmit over those VC-4
> > > trails. If later on it is decided to continue over route A only, the SEQ IDs
> > > are adapted as follows:
> > >
> > >         VC-4 with G1    via route A             SEQ ID=1
> > >         VC-4 with G2    via route A             SEQ ID=0
> > >         VC-4 with G3    not connected
> > >         VC-4 with G4    not connected
> > >         VC-4 with G5    via route A             SEQ ID=2
> > >         VC-4 with G6    not connected
> > >         VC-4 with G7    not connected
> > >
> > > If the demand for bandwidth doubles again, it is possible to add say three more
> > > VC-4 trails via e.g. route C (X - C - Y); e.g. via G3, G4 and G6. If the order
> > > those trails become available is G6, G3, G4 then the SEQ IDs will be:
> > >
> > >         VC-4 with G1    via route A             SEQ ID=1
> > >         VC-4 with G2    via route A             SEQ ID=0
> > >         VC-4 with G3    via route C             SEQ ID=4
> > >         VC-4 with G4    via route C             SEQ ID=5
> > >         VC-4 with G5    via route A             SEQ ID=2
> > >         VC-4 with G6    via route C             SEQ ID=3
> > >         VC-4 with G7    not connected
> > >
> > > Looking at the connection setup details, I do not setup a VC-4-2v via A and
> > > another VC-4-2v via B initially... I do setup two groups of two VC-4
> > > connections, which together support the  VC-4-4v trail; a VC-4-4v is not the
> > > same as two times a VC-4-2v. The use of NVC parameter here seems as such not
> > > appropriate. The only alternative present is the MT field.
> > >
> > > Alternative is to redefine NVC as "This field indicates the number of identical
> > > co-routed connections that are requested for this LSP. These connections are all
> > > of the same type."
> > >
> > >         But if I assume for a moment an alternative example in which the
> > >         virtual concatenated endpoints are outside of the network of
> > >         interest, then a UNI/E-NNI request using MT will result in the
> > >         same connections being setup compared to such request using the
> > >         modified NVC definition. What am I missing here?
> > >
> > > The traffic parameters for these two group-connections supporting the VC-4-Xv
> > > trail are thus:
> > >
> > > initially:
> > >         route A: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1]
> > >         route B: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1]
> > >
> > > after 5th VC-4 trail addition:
> > >         route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]
> > >         route B: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1]
> > >
> > > after route B connections being released:
> > >         route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]
> > >
> > > after 4th, 5th, 6th connection being added via route C:
> > >         route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]
> > >         route C: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]
> > >
> > > To add the 3rd VC-4 connection to the VC-4 group-connection over route A, a
> > > MODIFY message is required. In your LBM document you propose to signal the diff
> > > value only, and consequently let the switch nodes compute the new total (i.e.
> > > new = original + diff). It will work as well to signal the new value and let the
> > > switch nodes compute the difference (i.e. diff = new - original). We need to
> > > evaluate the pros/cons of both approaches before selecting one.
> > >
> > > When the group-connection via route B is removed, this group-connection has to
> > > be released.
> > >
> > > When the group-connection via route C is to be added, this group-connection has
> > > to be setup.
> > >
> > > In addition to these cases, the MODIFY message has to support also the decrease
> > > case. E.g. assume that route A is more expensive than route C, then one would
> > > obviously prefer to release a VC-4 connection via route A when the total
> > > bandwidth of the VC-4-Xv has to be shrunk from 900 Mb/s to 750 Mbit/s.
> > >
> > > after 3rd connection via route A is removed:
> > >         route A: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1]
> > >         route C: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]
> > >
> > >         VC-4 with G1    via route A             SEQ ID=1
> > >         VC-4 with G2    via route A             SEQ ID=0
> > >         VC-4 with G3    via route C             SEQ ID=3
> > >         VC-4 with G4    via route C             SEQ ID=4
> > >         VC-4 with G5    not connected
> > >         VC-4 with G6    via route C             SEQ ID=2
> > >         VC-4 with G7    not connected
> > >
> > > When using a MODIFY message which includes the new traffic parameters (and not
> > > the diff ones), the same MODIFY message can be used for addition and removal of
> > > connections to/from the group. This looks like a pro for a MODIFY message
> > > definition including the new traffic parameters.
> > >
> > > One note to the above scenarios... the set of 7 VC-4 SNPs can be operated as a
> > > single SNP Pool (SNPP). Instead of requesting the setup of a group-connection to
> > > SNPs G1 and G2 (route A) and to SNPs G3 and G4 (route B), one could choose to
> > > request the setup of two 2-group-connections to SNPP "G1-G7" and let the local
> > > switch node decide which specific SNPs will be allocated.
> > > And the same SNPP "G1-G7" address can be used to add the 5th VC-4 connection,
> > > and to add the 4/5/6th VC-4 connections via route C later on.
> > >
> > > I hope this clarifies some of the capabilities of the control plane needs to
> > > support when a group-connection is to be modified, and the operation of the SEQ
> > > ID within virtual concatenation with LCAS.
> > >
> > > Regards,
> > >
> > > Maarten
> > >
> > > Dimitri Papadimitriou wrote:
> > > >
> > > > Maarten,
> > > >
> > > > As per GMPLS-LBM, the multiplier field (MT) SHOULD not be used
> > > > for bandwidth increase purpose since it is used for a different
> > > > semantic.
> > > >
> > > > SPEs/VCs can only be added at the end of an LSP. For instance,
> > > > when adding Y VC-4s to a VC-4-Xv (where each of the VC-4 is
> > > > numbered from 0 to X-1), one obtains a VC-4-(X+Y)v with the
> > > > sequence numbered from 0 to X+Y-1.
> > > >
> > > > The number Y of SPEs/VCs to add is given by the following
> > > > equation: new NVC - old NVC. The first new SPE/VC will have a
> > > > sequence number equals to the sequence number of the previously
> > > > last VC + 1 (i.e. X).
> > > >
> > > > In such a case (in your below example)
> > > >
> > > >  - Connection X - A - Y traffic parameters
> > > >    * Before increase VC-4-2v: ST=6, RCC=0, NCC=0, NVC=2, MT=1, T=0
> > > >    * Increase to     VC-4-3v: ST=6, RCC=0, NCC=0, NVC=1, MT=1, T=0
> > > >
> > > >    remember that MT = 0 is an invalid value (as per draft-ietf-ccamp
> > > >    -gmpls-sonet-sdh-02.txt)
> > > >
> > > > The MT field in this picture is used in the following way (the
> > > > number Y of SPEs/VCs to add is given by the following equation:
> > > > (new NVC * new MT) - (old NVC * old MT) just notice that in most
> > > > cases new MT will be equal to old MT):
> > > >
> > > >  - 2 Connections X - A - Y traffic paramters
> > > >    * Before increase VC-4-2v: ST=6, RCC=0, NCC=0, NVC=2, MT=2, T=0
> > > >    * Increase to     VC-4-3v: ST=6, RCC=0, NCC=0, NVC=1, MT=2, T=0
> > > >
> > > > Your second example is depicted in the section 5.2 of the
> > > > draft-mannie-ccamp-gmpls-lbm-tdm-00.txt but again the use
> > > > of the multiplier (MT) in that context is not recommended.
> > > >
> > > > Regards,
> > > > - dimitri.
> > > >
> > > > Maarten Vissers wrote:
> > > > >
> > > > > Manoj,
> > > > >
> > > > > There is a difference between
> > > > > 1) modifying the bandwidth of a connection and
> > > > > 2) replacing the connection by a different connection.
> > > > >
> > > > > Add 2) A VC-3 connection is a connection in a VC-3 network layer, whereas a VC-4
> > > > > connection is a connection in a VC-4 network layer. These network layers are
> > > > > independent, and as such you can only replace a VC-3 connection by a VC-4
> > > > > connection by releasing the VC-3 connection and requesting to set up a VC-4
> > > > > connection.
> > > > >
> > > > > Add 1) You can modify the "bandwidth" of a group-connection (i.e. NVC(*) or MT
> > > > > >= 1), by adding/removing connection members. If this group-connection supports a virtual concatenated trail (VC-n-Xv, ODUk-Xv) then the supported client link's bandwidth is modified as a result.
> > > > >
> > > > >         Example: Consider VC-4-Xv trail between nodes X and Y which
> > > > >         supports an Ethernet link between these two nodes. When X is
> > > > >         increased from 4 to 5, the Ethernet link bandwdith is increased
> > > > >         from 600 Mb/s to 750 Mbit/s.
> > > > >
> > > > >         Assume that the VC-4-Xv trail is supported via two diverse
> > > > >         routes (X - A - Y and X - B - Y), each providing two VC-4
> > > > >         connections. Then the bandwidth modification will increase
> > > > >         the number of connections on one of the two routes; e.g. the
> > > > >         route via A. The associated traffic parameters will be:
> > > > >
> > > > >         - Connection X - A - Y traffic parameters
> > > > >                 * Before increase: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0
> > > > >                 * After increase:  ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0
> > > > >         - Connection X - B - Y traffic parameters (unchanged)
> > > > >                 * ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0
> > > > >
> > > > > What is needed is a MODIFY request which allows for an identified connection to
> > > > > modify the MT value.
> > > > >
> > > > > (*) Note that the parameter NVC is interpreted as to represent the number of
> > > > > components in a virtual concatenated signal connection... in this example NVC=4
> > > > > and grows to NVC=5. As the virtual concatenated signal is transported via two
> > > > > routes, each having half of the member connections, I have the impression that
> > > > > MT is the parameter to use.
> > > > >
> > > > > Or to turn this around and look at the source for the bandwidth modification
> > > > > first, we may assume that over the e.g. Ethernet UNI the call controller
> > > > > (G.8080) at the network side receives a request to increase the enthernet link
> > > > > from 600 to 750 Mbit/s. The call controller then decides to support this
> > > > > ehternet bandwidth modification request by means of a modification of the
> > > > > group-connection via route A... it then issues a connection modification request
> > > > > for this group-connection... etc.
> > > > >
> > > > > Add 1) True bandwidth modification of an individual connection is possible for
> > > > > e.g. ATM VP, ATM VC and MPLS connections. As long as the ATM VP, ATM VC or MPLS
> > > > > links (G.805) over which the connection is transported have spare capacity, the
> > > > > bandwidth of an individual VP, VC or LSP can be increased.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Maarten
> > > > >
> > > > > manoj juneja wrote:
> > > > > >
> > > > > > Hi All,
> > > > > >          If the bandwidth modification is not supported by GMPLS then
> > > > > > it should be clearly mentioned in the drafts (at least the architecture
> > > > > > draft). Please see the attached mail for reference.
> > > > > >
> > > > > > I am still not clear whether GMPLS supports SE-style of reservation.
> > > > > > My original question related to SE-style of reservation was and I didn't
> > > > > > get any reply on the mailing list :
> > > > > >
> > > > > >       "  I have a doubt related to SE style of reservation in GMPLS. As
> > > > > > in RSVP-TE, multiple senders can share the reservation but they can be
> > > > > > assigned different labels to distinguish different senders from one
> > > > > > other.
> > > > > > In GMPLS, as the label itself is a resource on the link, it means that
> > > > > > if there are multiple senders in the same session sharing reservation,
> > > > > > they should be assigned the same label. They can't be assigned
> > > > > > different labels or is it that GMPLS does not support SE style of
> > > > > > reservation ?"
> > > > > >
> > > > > > Please correct me if I am missing something.
> > > > > >
> > > > > > Regards,
> > > > > > manoj.
> > > > > >
> > > > > > >From: Maarten Vissers <[email-masked]>
> > > > > > >To: manoj juneja <[email-masked]>
> > > > > > >CC: [email-masked]
> > > > > > >Subject: Re: Bandwidth modification in GMPLS
> > > > > > >Date: Fri, 30 Nov 2001 11:45:25 +0100
> > > > > > >
> > > > > > >Manoj,
> > > > > > >
> > > > > > >manoj juneja wrote:
> > > > > > > >
> > > > > > > > Hi All,
> > > > > > > >         Is it possible to modify/increase the bandwidth of an existing
> > > > > > >GMPLS
> > > > > > > > tunnel ? I mean to say if I establish a VC-3 SDH LSP, will it be
> > > > > > >possible to
> > > > > > > > increase the bandwidth to say VC-4 ?
> > > > > > >
> > > > > > >No, this is not possible.
> > > > > > >
> > > > > > >Regards,
> > > > > > >
> > > > > > >Maarten
> > > > > > >
> > > > > > > >
> > > > > > > > Should the new request be considered independent of previous one ?
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > manoj.
> > > > > > > >
> > > > > > > > _________________________________________________________________
> > > > > > > > Get your FREE download of MSN Explorer at
> > > > > > >http://explorer.msn.com/intl.asp
> > > > > > ><< mvissers.vcf >>
> > > > > >
> > > > > > _________________________________________________________________
> > > > > > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
--------------1881898109D5420C5A141631
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------1881898109D5420C5A141631--

Delivery-date: Wed, 05 Dec 2001 02:09:55 -0800
Date: Wed, 05 Dec 2001 11:05:54 +0100
From: Richard Douville <[email-masked]>
Organization: Alcatel R&I - URP
To: [email-masked]
Subject: draft-douville-ccamp-gmpls-waveband-extensions-00.txt

Hi all,

We have posted the following draft:
"Extensions to GMPLS for Waveband Switching", 
http://www.ietf.org/internet-drafts/draft-douville-ccamp-gmpls-waveband-extensions-00.txt 
 
We proposed band-dedicated extensions to GMPLS protocols including
support of waveband interface component in optical networks as defined
in the
http://www.ietf.org/internet-drafts/draft-dotaro-ipo-optical-multi-granularity-01.txt
.

Looking forward to comments. 

Regards, 

Richard Douville
-- 
Richard Douville		[email-masked]
Alcatel Research & Innovation	Photonic Networks Unit, URP
Route de Nozay			Tel: 33-1-69.63.44.31
F-91460 Marcoussis, France.	Fax: 33-1-69.63.18.65

Delivery-date: Wed, 05 Dec 2001 01:23:08 -0800
From: "Juergen Heiles" <[email-masked]>
To: "'manoj juneja'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: AW: Lambda LSP Forwarding Adjacency Doubt
Date: Wed, 5 Dec 2001 10:18:49 +0100

For a TDM service you have to consider the specific signal format, for
example SDH or G.709 ODU.
I ncase of SDH each LSP (e.g. VC-4, VC-12) has a unique SUKLM numbering in
the lable in additon to the interface ID. If nodes A and D include TDM and
lambda switches the STM-N signal is no longer a interface (instead the WDM
signal is the interface), so I would assume that the ID of the lambda FA-LSP
replaces the interface ID.

Juergen

> -----Ursprüngliche Nachricht-----
> Von: manoj juneja [mailto:[email-masked]]
> Gesendet: Mittwoch, 5. Dezember 2001 00:24
> An: [email-masked]
> Cc: [email-masked]
> Betreff: RE: Lambda LSP Forwarding Adjacency Doubt
>
>
> Hi Debashis,
>             In my example, A and D nodes are TDM and lambda switch
> capable but nodes B and C are lambda switch capable. I want to tunnel
> TDM LSP through the lambda LSP (established earlier and
> advertised as a
> FA). My question was how the label allocation be done at node
> D ? Is it
> that for all the incoming TDM LSPs requests that need to be tunneled
> through same lambda FA-LSP be assigned the same label at node D and
> sent bck to node A in RESV message ? If no, then how to assign the
> different labels to different LSPs that are to be tunneled through the
> same lambda FA-LSP.
>
> I think u are describing the case of how to tunnel LOVC LSP
> in HOVC LSP
> (HOVC LSP advertised as FA).
>
> Regards,
> manoj.
>
>
> >From: "Basak, Debashis" <[email-masked]>
> >To: 'manoj juneja' <[email-masked]>
> >CC: "[email-masked]'" <[email-masked]>
> >Subject: RE: Lambda LSP Forwarding Adjacency Doubt
> >Date: Tue, 4 Dec 2001 17:55:26 -0500
> >
> >Manoj,
> >
> >The end points of the lambdapath in your example, nodes A to
> D, are capable
> >of  establishing TDM services through it. Its probably
> better referred as a
> >TDM-FA, basically you have created a new TDM link between A
> and D. For
> >establishing TDM services on the new link, A and D in your
> example should
> >have a signaling peer relationship setup for the link.
> Further TDM services
> >would be set up as you would over any TDM link, by
> exchanging TDM labels.
> >
> >-Debashis
> >
> >Accelight Networks
> >
> >
> >-----Original Message-----
> >From: manoj juneja [mailto:[email-masked]]
> >Sent: Tuesday, December 04, 2001 3:24 PM
> >To: [email-masked]
> >Subject: Lambda LSP Forwarding Adjacency Doubt
> >
> >
> >Hi All,
> >          If there are 4 nodes say A, B, C and D. There is a
> Lambda FA
> >established from A to D and if a new TDM LSP request comes to node A
> >which is to be tunneled through the already established lambda FA-LSP
> >then the node A sends the Path/label request message directly to node
> >D. What label the node D will send back to node A in the RESV/label
> >mapping message since the FA-LSP is just one label (lambda) ? Does it
> >mean that all the LSPs which are tunneled through the lambda FA-LSP
> >will be allocated the same label by node D to node A ?
> >
> >Please help.
> >
> >Regards,
> >manoj.
> >
> >_________________________________________________________________
> >Get your FREE download of MSN Explorer at
> http://explorer.msn.com/intl.asp
> >
>
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at
> http://explorer.msn.com/intl.asp
>
>

Delivery-date: Wed, 05 Dec 2001 01:22:41 -0800
From: "Juergen Heiles" <[email-masked]>
To: "'manoj juneja'" <[email-masked]>, <[email-masked]>
Subject: AW: VC-4-64c as forwarding adjacency
Date: Wed, 5 Dec 2001 10:19:03 +0100

No, that is not possible as you cannot transport a VC-4 in a VC-4-64c. A
VC-4-64c only supports dat clients like ATM, IP, Ethernet.

Juergen

> -----Ursprüngliche Nachricht-----
> Von: manoj juneja [mailto:[email-masked]]
> Gesendet: Dienstag, 4. Dezember 2001 23:44
> An: [email-masked]
> Betreff: VC-4-64c as forwarding adjacency
>
>
> Hi All,
>          Can I tunnel a request for VC-4 LSP on VC-4-64c forwarding
> adjacency ? If yes, then what would be the {suklm} ?
>
> Regards,
> manoj
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at
> http://explorer.msn.com/intl.asp
>
>

Delivery-date: Wed, 05 Dec 2001 00:21:51 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Fwd: LSC Interface Doubt ...
Date: Wed, 05 Dec 2001 01:20:25 -0700

Hi All,
        If I need to establish a bi-directional LSC LSP then do I
need to configure the remote end wavelengths on an LSC interface ?
Is there any case where both the upstream and downstream labels of an
bi-directional LSC LSP be same ?

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Tue, 04 Dec 2001 16:41:23 -0800
Date: Tue, 4 Dec 2001 16:38:32 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: manoj juneja <[email-masked]>
cc: [email-masked]
Subject: Re: Lambda LSP Forwarding Adjacency Doubt

On Tue, 4 Dec 2001, Yangguang Xu wrote:

> In this case A and D are neighbors in the TDM network. So A and D need to build
> up TDM label mapping table between them over the new interfaces connected
> through the Lambda FA-LSP. The TDM labels are at a different space from the
> Lambda labels. They are at different logical layers.

What he said.  And what Debashis said.  Not what George Young said.

>        Thanks a lot for the immediate reply. Does this mean that concept 
> of forwarding adjacency is not applicable for FSC/LSC interfaces 
> presently?

That would be the ultimate irony.  FAs, while useful for 'regular'
MPLS, were really conceived for GMPLS (i.e., non-packet LSPs).

Kireeti.

Delivery-date: Tue, 04 Dec 2001 15:24:38 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: Lambda LSP Forwarding Adjacency Doubt
Date: Tue, 04 Dec 2001 16:23:39 -0700

Hi Debashis,
            In my example, A and D nodes are TDM and lambda switch
capable but nodes B and C are lambda switch capable. I want to tunnel
TDM LSP through the lambda LSP (established earlier and advertised as a
FA). My question was how the label allocation be done at node D ? Is it
that for all the incoming TDM LSPs requests that need to be tunneled
through same lambda FA-LSP be assigned the same label at node D and
sent bck to node A in RESV message ? If no, then how to assign the
different labels to different LSPs that are to be tunneled through the
same lambda FA-LSP.

I think u are describing the case of how to tunnel LOVC LSP in HOVC LSP
(HOVC LSP advertised as FA).

Regards,
manoj.

>From: "Basak, Debashis" <[email-masked]>
>To: 'manoj juneja' <[email-masked]>
>CC: "[email-masked]'" <[email-masked]>
>Subject: RE: Lambda LSP Forwarding Adjacency Doubt
>Date: Tue, 4 Dec 2001 17:55:26 -0500
>
>Manoj,
>
>The end points of the lambdapath in your example, nodes A to D, are capable
>of  establishing TDM services through it. Its probably better referred as a
>TDM-FA, basically you have created a new TDM link between A and D. For
>establishing TDM services on the new link, A and D in your example should
>have a signaling peer relationship setup for the link. Further TDM services
>would be set up as you would over any TDM link, by exchanging TDM labels.
>
>-Debashis
>
>Accelight Networks
>
>
>-----Original Message-----
>From: manoj juneja [mailto:[email-masked]]
>Sent: Tuesday, December 04, 2001 3:24 PM
>To: [email-masked]
>Subject: Lambda LSP Forwarding Adjacency Doubt
>
>
>Hi All,
>          If there are 4 nodes say A, B, C and D. There is a Lambda FA
>established from A to D and if a new TDM LSP request comes to node A
>which is to be tunneled through the already established lambda FA-LSP
>then the node A sends the Path/label request message directly to node
>D. What label the node D will send back to node A in the RESV/label
>mapping message since the FA-LSP is just one label (lambda) ? Does it
>mean that all the LSPs which are tunneled through the lambda FA-LSP
>will be allocated the same label by node D to node A ?
>
>Please help.
>
>Regards,
>manoj.
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Tue, 04 Dec 2001 15:11:17 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Lambda LSP Forwarding Adjacency Doubt
Date: Tue, 04 Dec 2001 16:08:16 -0700

Hi Yangguang,
              How the TDM mapping be established at nodes A and D ? There is 
no signalling for this. I am not aware of any draft that talks of such kind 
of mapping.

Can u please point me to appropriate text in the drafts ?

Regards,
manoj.

>From: Yangguang Xu <[email-masked]>
>To: manoj juneja <[email-masked]>
>CC: [email-masked]
>Subject: Re: Lambda LSP Forwarding Adjacency Doubt
>Date: Tue, 04 Dec 2001 18:00:28 -0500
>
>
>
>manoj,
>
> > > >Hi All,
> > > >         If there are 4 nodes say A, B, C and D. There is a Lambda FA
> > > >established from A to D and if a new TDM LSP request comes to node A
> > > >which is to be tunneled through the already established lambda FA-LSP
> > > >then the node A sends the Path/label request message directly to node
> > > >D. What label the node D will send back to node A in the RESV/label
> > > >mapping message since the FA-LSP is just one label (lambda) ? Does it
> > > >mean that all the LSPs which are tunneled through the lambda FA-LSP
> > > >will be allocated the same label by node D to node A ?
> > > >
>
>In this case A and D are neighbors in the TDM network. So A and D need to 
>build
>up TDM label mapping table between them over the new interfaces connected
>through the Lambda FA-LSP. The TDM labels are at a different space from the
>Lambda labels. They are at different logical layers.
>
>Regards,
>
>Yangguang

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Tue, 04 Dec 2001 15:05:44 -0800
Date: Tue, 04 Dec 2001 18:00:28 -0500
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: manoj juneja <[email-masked]>
CC: [email-masked]
Subject: Re: Lambda LSP Forwarding Adjacency Doubt

manoj,

> > >Hi All,
> > >         If there are 4 nodes say A, B, C and D. There is a Lambda FA
> > >established from A to D and if a new TDM LSP request comes to node A
> > >which is to be tunneled through the already established lambda FA-LSP
> > >then the node A sends the Path/label request message directly to node
> > >D. What label the node D will send back to node A in the RESV/label
> > >mapping message since the FA-LSP is just one label (lambda) ? Does it
> > >mean that all the LSPs which are tunneled through the lambda FA-LSP
> > >will be allocated the same label by node D to node A ?
> > >

In this case A and D are neighbors in the TDM network. So A and D need to build
up TDM label mapping table between them over the new interfaces connected
through the Lambda FA-LSP. The TDM labels are at a different space from the
Lambda labels. They are at different logical layers.

Regards,

Yangguang

Delivery-date: Tue, 04 Dec 2001 14:59:38 -0800
From: "Basak, Debashis" <[email-masked]>
To: 'manoj juneja' <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Lambda LSP Forwarding Adjacency Doubt
Date: Tue, 4 Dec 2001 17:55:26 -0500 

Manoj,

The end points of the lambdapath in your example, nodes A to D, are capable
of  establishing TDM services through it. Its probably better referred as a
TDM-FA, basically you have created a new TDM link between A and D. For
establishing TDM services on the new link, A and D in your example should
have a signaling peer relationship setup for the link. Further TDM services
would be set up as you would over any TDM link, by exchanging TDM labels.

-Debashis

Accelight Networks 

-----Original Message-----
From: manoj juneja [mailto:[email-masked]]
Sent: Tuesday, December 04, 2001 3:24 PM
To: [email-masked]
Subject: Lambda LSP Forwarding Adjacency Doubt

Hi All,
         If there are 4 nodes say A, B, C and D. There is a Lambda FA
established from A to D and if a new TDM LSP request comes to node A
which is to be tunneled through the already established lambda FA-LSP
then the node A sends the Path/label request message directly to node
D. What label the node D will send back to node A in the RESV/label
mapping message since the FA-LSP is just one label (lambda) ? Does it
mean that all the LSPs which are tunneled through the lambda FA-LSP
will be allocated the same label by node D to node A ?

Please help.

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Tue, 04 Dec 2001 14:46:38 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: VC-4-64c as forwarding adjacency
Date: Tue, 04 Dec 2001 15:44:05 -0700

Hi All,
         Can I tunnel a request for VC-4 LSP on VC-4-64c forwarding 
adjacency ? If yes, then what would be the {suklm} ?

Regards,
manoj

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Tue, 04 Dec 2001 14:19:57 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: Lambda LSP Forwarding Adjacency Doubt
Date: Tue, 04 Dec 2001 15:16:57 -0700

Hi George,
           Thanks a lot for the immediate reply. Does this mean that concept 
of forwarding adjacency is not applicable for FSC/LSC interfaces presently ?

Regards,
manoj.

>From: "George Young" <[email-masked]>
>To: "manoj juneja" <[email-masked]>
>CC: <[email-masked]>
>Subject: RE: Lambda LSP Forwarding Adjacency Doubt
>Date: Tue, 4 Dec 2001 16:05:08 -0500
>
>Hello Manoj,
>
>The use of a label to designate a circuit mode connection works well in
>a homogeneous network (e.g. everybody switching OC-48 paths).
>
>If the OC-48 switched network is itself obtaining connections from (say)
>a lambda-switched network, the lambda-switched network should have its
>own set of labels mapping to lambda connections. The concept of label
>stacking doesn't seem to carry over well from the packet world.
>
>There's work that I'm familiar with just starting in OIF on this
>inter-layer cooperation, under the NNI project. ITU has also done work
>in this area.
>
>Regards,
>George R. Young
>Meriton Networks Inc.
>329 March Rd., Kanata, ON, Canada, K2K 2E1
>phone: +1 613-270-9279 Ext 287
>fax: +1 613-270-9268
>
>
> >-----Original Message-----
> >From: manoj juneja [mailto:[email-masked]]
> >Sent: Tuesday, December 04, 2001 3:24 PM
> >To: [email-masked]
> >Subject: Lambda LSP Forwarding Adjacency Doubt
> >
> >
> >Hi All,
> >         If there are 4 nodes say A, B, C and D. There is a Lambda FA
> >established from A to D and if a new TDM LSP request comes to node A
> >which is to be tunneled through the already established lambda FA-LSP
> >then the node A sends the Path/label request message directly to node
> >D. What label the node D will send back to node A in the RESV/label
> >mapping message since the FA-LSP is just one label (lambda) ? Does it
> >mean that all the LSPs which are tunneled through the lambda FA-LSP
> >will be allocated the same label by node D to node A ?
> >
> >Please help.
> >
> >Regards,
> >manoj.
> >
> >_________________________________________________________________
> >Get your FREE download of MSN Explorer at
> >http://explorer.msn.com/intl.asp
> >
> >
> >
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Tue, 04 Dec 2001 13:05:53 -0800
content-class: urn:content-classes:message
Subject: RE: Lambda LSP Forwarding Adjacency Doubt
Date:  Tue, 4 Dec 2001 16:05:08 -0500
From: "George Young" <[email-masked]>
To: "manoj juneja" <[email-masked]>
Cc: <[email-masked]>

Hello Manoj,

The use of a label to designate a circuit mode connection works well in
a homogeneous network (e.g. everybody switching OC-48 paths).

If the OC-48 switched network is itself obtaining connections from (say)
a lambda-switched network, the lambda-switched network should have its
own set of labels mapping to lambda connections. The concept of label
stacking doesn't seem to carry over well from the packet world.

There's work that I'm familiar with just starting in OIF on this
inter-layer cooperation, under the NNI project. ITU has also done work
in this area.

Regards,
George R. Young
Meriton Networks Inc.
329 March Rd., Kanata, ON, Canada, K2K 2E1
phone: +1 613-270-9279 Ext 287
fax: +1 613-270-9268

>-----Original Message-----
>From: manoj juneja [mailto:[email-masked]]
>Sent: Tuesday, December 04, 2001 3:24 PM
>To: [email-masked]
>Subject: Lambda LSP Forwarding Adjacency Doubt
>
>
>Hi All,
>         If there are 4 nodes say A, B, C and D. There is a Lambda FA
>established from A to D and if a new TDM LSP request comes to node A
>which is to be tunneled through the already established lambda FA-LSP
>then the node A sends the Path/label request message directly to node
>D. What label the node D will send back to node A in the RESV/label
>mapping message since the FA-LSP is just one label (lambda) ? Does it
>mean that all the LSPs which are tunneled through the lambda FA-LSP
>will be allocated the same label by node D to node A ?
>
>Please help.
>
>Regards,
>manoj.
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at=20
>http://explorer.msn.com/intl.asp
>
>
>

Delivery-date: Tue, 04 Dec 2001 12:27:22 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Lambda LSP Forwarding Adjacency Doubt
Date: Tue, 04 Dec 2001 13:24:15 -0700

Hi All,
         If there are 4 nodes say A, B, C and D. There is a Lambda FA
established from A to D and if a new TDM LSP request comes to node A
which is to be tunneled through the already established lambda FA-LSP
then the node A sends the Path/label request message directly to node
D. What label the node D will send back to node A in the RESV/label
mapping message since the FA-LSP is just one label (lambda) ? Does it
mean that all the LSPs which are tunneled through the lambda FA-LSP
will be allocated the same label by node D to node A ?

Please help.

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Tue, 04 Dec 2001 03:46:46 -0800
Cc: manoj juneja <[email-masked]>, [email-masked], [email-masked], [email-masked], "Helvoort, Huub van" <[email-masked]>
Date: Tue, 04 Dec 2001 12:36:17 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Dimitri Papadimitriou <[email-masked]>
Original-CC: manoj juneja <[email-masked]>, [email-masked], [email-masked], [email-masked], "Helvoort, Huub van" <[email-masked]>
Subject: Re: Bandwidth modification in GMPLS

This is a multi-part message in MIME format.
--------------28B3AE269E886FB78A163294
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dimitri,

I am not comparing the two methods. I am describing how LCAS operates the SEQ
IDs and how connection management has to support virtual concatenation with
LCAS. GMPLS is an implementation of distributed connection management, and must
therefore support what I described.

In addition, connection management must support a means to perform the same
capabilities for the case one or both endpoints do not support LCAS, but allow
resizing the pipe. The proposal you made in your LBM document is much more
restrictive than LCAS capable implementations. It is up to the operators to
decide if these restrictions are acceptable. It is most likely a trade of
between less restrictions/more complex protocol and more restrictions/less
complex protocol.

Personally, I would like to compare two proposals: one that supports all LCAS
capabilities (except of course the hitless one), the other that includes
restrictions. If the complexity difference is not too large, go for the full
capabilities support, otherwise select the one with the restrictions.

Regards,

Maarten

Dimitri Papadimitriou wrote:
> 
> Maarten,
> 
> First for people reading these e-mails the discussion here
> is not focused on a comparison between LCAS versus something
> else but only on control plane issues (more precisely which
> are the GMPLS mechanisms to be provided in order to enable
> bandwidth modification on different scenarios)
> 
> Now, to continue the discussion we have defined in the GMPLS
> LBM I-D the Circuit ID and the LSP Sequence Number for that
> purpose (see Section 5.2). Together with the following rule:
> 
> "All LSPs belonging to the same circuit MUST have the same
> Circuit ID. All LSPs MUST have a unique LSP sequence number
> in that Circuit ID, the LSP sequence number MUST be the
> sequence number of the first SPE/VC of the overall virtually
> concatenated circuit."
> 
> Therefore, the scenarios you have defined are a combination
> of the methods described in Section 5.1 and 5.2.
> 
> To illustrate this, let's take your example back:
> 
> > Assume the connection controller selects VC-4 SNPs with addresses G1, G2 to
> > connect to route A, and G3, G4 to connect to route B. G5 to G7 are not connected
> > VC-4 SNPs.
> >
> >         VC-4 with G1    via route A
> >         VC-4 with G2    via route A
> >         VC-4 with G3    via route B
> >         VC-4 with G4    via route B
> >         VC-4 with G5    not connected
> >         VC-4 with G6    not connected
> >         VC-4 with G7    not connected
> 
> => Circuit ID #1 (for instance) will include LSP SEQ ID#0
>    and LSP SEQ ID#1 (here we assume that Route A is link
>    diverse from Route B to preserve generality of the
>    proposed method)
> 
> > Assume that the VC-4 trail via G2 is the first one which clears its Signal Fail
> > (SF) condition, then this trail will pass through the signal with SEQ ID=0. If
> > the second one is via G4, then this one passes through the signal with SEQ ID=1.
> > If 3rd is via G3, then this gets SEQ ID=2 and finally via G1 gets SEQ ID=3.
> >
> >         VC-4 with G1    via route A             SEQ ID=3
> >         VC-4 with G2    via route A             SEQ ID=0
> >         VC-4 with G3    via route B             SEQ ID=2
> >         VC-4 with G4    via route B             SEQ ID=1
> >         VC-4 with G5    not connected
> >         VC-4 with G6    not connected
> >         VC-4 with G7    not connected
> 
> => As such LSP SEQ ID#0 corresponds to the SEQ ID=0 and LSP
>    SEQ ID#1 to the SEQ ID=0
> 
> > When adding the 5th VC-4 (e.g. via VC-4 SNP G5), this VC-4 will carry SEQ ID #4.
> >
> >         VC-4 with G1    via route A             SEQ ID=3
> >         VC-4 with G2    via route A             SEQ ID=0
> >         VC-4 with G3    via route B             SEQ ID=2
> >         VC-4 with G4    via route B             SEQ ID=1
> >         VC-4 with G5    via route A             SEQ ID=4
> >         VC-4 with G6    not connected
> >         VC-4 with G7    not connected
> 
> => To update the LSP SEQ#0 you follow the rules defined in
>    the Section 5.1
> 
> > Now route B fails; i.e. VC-4 with SEQ ID #1 and #2 fail. There will be no change
> > of SEQ ID, only there will be an indication not to transmit over those VC-4
> > trails. If later on it is decided to continue over route A only, the SEQ IDs
> > are adapted as follows:
> >
> >         VC-4 with G1    via route A             SEQ ID=1
> >         VC-4 with G2    via route A             SEQ ID=0
> >         VC-4 with G3    not connected
> >         VC-4 with G4    not connected
> >         VC-4 with G5    via route A             SEQ ID=2
> >         VC-4 with G6    not connected
> >         VC-4 with G7    not connected
> 
> => you delete the VC-4 components with the re-sequencing as described
>    at the end of the Section 5.1 with the restriction that "SPEs/VCs
>    can be removed from an LSP but only at the end of that LSP (i.e.
>    starting at SPE/VC sequence number X)"
> 
> > If the demand for bandwidth doubles again, it is possible to add say three more
> > VC-4 trails via e.g. route C (X - C - Y); e.g. via G3, G4 and G6. If the order
> > those trails become available is G6, G3, G4 then the SEQ IDs will be:
> >
> >         VC-4 with G1    via route A             SEQ ID=1
> >         VC-4 with G2    via route A             SEQ ID=0
> >         VC-4 with G3    via route C             SEQ ID=4
> >         VC-4 with G4    via route C             SEQ ID=5
> >         VC-4 with G5    via route A             SEQ ID=2
> >         VC-4 with G6    via route C             SEQ ID=3
> >         VC-4 with G7    not connected
> 
> => once again you follow the rule described in Section 5.1
> 
> There is no need to use the multiplier for this purpose (this
> field is used for instance to operate a change on multiple LSP
> using the same message - it has been provided to avoid lengthy
> repetitions of the same operation)
> 
> Once again (i think that Eric has already provided this comment)
> the scope of the LSP SEQ ID is not to reproduce the LCAS defined
> structures within the control plan but to provide a consistent
> control plane definition (allowing a level of consistency checking
> between the control plane and the transport plane.)
> 
> Are we in agreement, or do you want further comparison of both
> methods ?
> 
> Regards,
> - dimitri.
> 
> Maarten Vissers wrote:
> >
> > Dimitri,
> >
> > Assume the VC-4-4v signal consisting of 4 VC-4 signals. Each VC-4 signal has a
> > SEQ ID (0,1,2,3). Which SEQ ID is associated with which VC-4 is not not fixed...
> > this is under control of LCAS and may change with time...
> >
> > When you set up the connection to transport the VC-4-4v signal via two routes
> > (A, B), two VC-4 termination points will be connected to the A route, two other
> > to the B route.
> > There are typically 7 VC-4 termination points per GbE port... let's refer to
> > those 7 VC-4 termination points by means of SubNetwork Point (SNP) addresses G1
> > .. G7.
> >
> > Assume the connection controller selects VC-4 SNPs with addresses G1, G2 to
> > connect to route A, and G3, G4 to connect to route B. G5 to G7 are not connected
> > VC-4 SNPs.
> >
> >         VC-4 with G1    via route A
> >         VC-4 with G2    via route A
> >         VC-4 with G3    via route B
> >         VC-4 with G4    via route B
> >         VC-4 with G5    not connected
> >         VC-4 with G6    not connected
> >         VC-4 with G7    not connected
> >
> > Assume that the VC-4 trail via G2 is the first one which clears its Signal Fail
> > (SF) condition, then this trail will pass through the signal with SEQ ID=0. If
> > the second one is via G4, then this one passes through the signal with SEQ ID=1.
> > If 3rd is via G3, then this gets SEQ ID=2 and finally via G1 gets SEQ ID=3.
> >
> >         VC-4 with G1    via route A             SEQ ID=3
> >         VC-4 with G2    via route A             SEQ ID=0
> >         VC-4 with G3    via route B             SEQ ID=2
> >         VC-4 with G4    via route B             SEQ ID=1
> >         VC-4 with G5    not connected
> >         VC-4 with G6    not connected
> >         VC-4 with G7    not connected
> >
> > When adding the 5th VC-4 (e.g. via VC-4 SNP G5), this VC-4 will carry SEQ ID #4.
> >
> >         VC-4 with G1    via route A             SEQ ID=3
> >         VC-4 with G2    via route A             SEQ ID=0
> >         VC-4 with G3    via route B             SEQ ID=2
> >         VC-4 with G4    via route B             SEQ ID=1
> >         VC-4 with G5    via route A             SEQ ID=4
> >         VC-4 with G6    not connected
> >         VC-4 with G7    not connected
> >
> > Now route B fails; i.e. VC-4 with SEQ ID #1 and #2 fail. There will be no change
> > of SEQ ID, only there will be an indication not to transmit over those VC-4
> > trails. If later on it is decided to continue over route A only, the SEQ IDs
> > are adapted as follows:
> >
> >         VC-4 with G1    via route A             SEQ ID=1
> >         VC-4 with G2    via route A             SEQ ID=0
> >         VC-4 with G3    not connected
> >         VC-4 with G4    not connected
> >         VC-4 with G5    via route A             SEQ ID=2
> >         VC-4 with G6    not connected
> >         VC-4 with G7    not connected
> >
> > If the demand for bandwidth doubles again, it is possible to add say three more
> > VC-4 trails via e.g. route C (X - C - Y); e.g. via G3, G4 and G6. If the order
> > those trails become available is G6, G3, G4 then the SEQ IDs will be:
> >
> >         VC-4 with G1    via route A             SEQ ID=1
> >         VC-4 with G2    via route A             SEQ ID=0
> >         VC-4 with G3    via route C             SEQ ID=4
> >         VC-4 with G4    via route C             SEQ ID=5
> >         VC-4 with G5    via route A             SEQ ID=2
> >         VC-4 with G6    via route C             SEQ ID=3
> >         VC-4 with G7    not connected
> >
> > Looking at the connection setup details, I do not setup a VC-4-2v via A and
> > another VC-4-2v via B initially... I do setup two groups of two VC-4
> > connections, which together support the  VC-4-4v trail; a VC-4-4v is not the
> > same as two times a VC-4-2v. The use of NVC parameter here seems as such not
> > appropriate. The only alternative present is the MT field.
> >
> > Alternative is to redefine NVC as "This field indicates the number of identical
> > co-routed connections that are requested for this LSP. These connections are all
> > of the same type."
> >
> >         But if I assume for a moment an alternative example in which the
> >         virtual concatenated endpoints are outside of the network of
> >         interest, then a UNI/E-NNI request using MT will result in the
> >         same connections being setup compared to such request using the
> >         modified NVC definition. What am I missing here?
> >
> > The traffic parameters for these two group-connections supporting the VC-4-Xv
> > trail are thus:
> >
> > initially:
> >         route A: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1]
> >         route B: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1]
> >
> > after 5th VC-4 trail addition:
> >         route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]
> >         route B: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1]
> >
> > after route B connections being released:
> >         route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]
> >
> > after 4th, 5th, 6th connection being added via route C:
> >         route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]
> >         route C: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]
> >
> > To add the 3rd VC-4 connection to the VC-4 group-connection over route A, a
> > MODIFY message is required. In your LBM document you propose to signal the diff
> > value only, and consequently let the switch nodes compute the new total (i.e.
> > new = original + diff). It will work as well to signal the new value and let the
> > switch nodes compute the difference (i.e. diff = new - original). We need to
> > evaluate the pros/cons of both approaches before selecting one.
> >
> > When the group-connection via route B is removed, this group-connection has to
> > be released.
> >
> > When the group-connection via route C is to be added, this group-connection has
> > to be setup.
> >
> > In addition to these cases, the MODIFY message has to support also the decrease
> > case. E.g. assume that route A is more expensive than route C, then one would
> > obviously prefer to release a VC-4 connection via route A when the total
> > bandwidth of the VC-4-Xv has to be shrunk from 900 Mb/s to 750 Mbit/s.
> >
> > after 3rd connection via route A is removed:
> >         route A: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1]
> >         route C: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]
> >
> >         VC-4 with G1    via route A             SEQ ID=1
> >         VC-4 with G2    via route A             SEQ ID=0
> >         VC-4 with G3    via route C             SEQ ID=3
> >         VC-4 with G4    via route C             SEQ ID=4
> >         VC-4 with G5    not connected
> >         VC-4 with G6    via route C             SEQ ID=2
> >         VC-4 with G7    not connected
> >
> > When using a MODIFY message which includes the new traffic parameters (and not
> > the diff ones), the same MODIFY message can be used for addition and removal of
> > connections to/from the group. This looks like a pro for a MODIFY message
> > definition including the new traffic parameters.
> >
> > One note to the above scenarios... the set of 7 VC-4 SNPs can be operated as a
> > single SNP Pool (SNPP). Instead of requesting the setup of a group-connection to
> > SNPs G1 and G2 (route A) and to SNPs G3 and G4 (route B), one could choose to
> > request the setup of two 2-group-connections to SNPP "G1-G7" and let the local
> > switch node decide which specific SNPs will be allocated.
> > And the same SNPP "G1-G7" address can be used to add the 5th VC-4 connection,
> > and to add the 4/5/6th VC-4 connections via route C later on.
> >
> > I hope this clarifies some of the capabilities of the control plane needs to
> > support when a group-connection is to be modified, and the operation of the SEQ
> > ID within virtual concatenation with LCAS.
> >
> > Regards,
> >
> > Maarten
> >
> > Dimitri Papadimitriou wrote:
> > >
> > > Maarten,
> > >
> > > As per GMPLS-LBM, the multiplier field (MT) SHOULD not be used
> > > for bandwidth increase purpose since it is used for a different
> > > semantic.
> > >
> > > SPEs/VCs can only be added at the end of an LSP. For instance,
> > > when adding Y VC-4s to a VC-4-Xv (where each of the VC-4 is
> > > numbered from 0 to X-1), one obtains a VC-4-(X+Y)v with the
> > > sequence numbered from 0 to X+Y-1.
> > >
> > > The number Y of SPEs/VCs to add is given by the following
> > > equation: new NVC - old NVC. The first new SPE/VC will have a
> > > sequence number equals to the sequence number of the previously
> > > last VC + 1 (i.e. X).
> > >
> > > In such a case (in your below example)
> > >
> > >  - Connection X - A - Y traffic parameters
> > >    * Before increase VC-4-2v: ST=6, RCC=0, NCC=0, NVC=2, MT=1, T=0
> > >    * Increase to     VC-4-3v: ST=6, RCC=0, NCC=0, NVC=1, MT=1, T=0
> > >
> > >    remember that MT = 0 is an invalid value (as per draft-ietf-ccamp
> > >    -gmpls-sonet-sdh-02.txt)
> > >
> > > The MT field in this picture is used in the following way (the
> > > number Y of SPEs/VCs to add is given by the following equation:
> > > (new NVC * new MT) - (old NVC * old MT) just notice that in most
> > > cases new MT will be equal to old MT):
> > >
> > >  - 2 Connections X - A - Y traffic paramters
> > >    * Before increase VC-4-2v: ST=6, RCC=0, NCC=0, NVC=2, MT=2, T=0
> > >    * Increase to     VC-4-3v: ST=6, RCC=0, NCC=0, NVC=1, MT=2, T=0
> > >
> > > Your second example is depicted in the section 5.2 of the
> > > draft-mannie-ccamp-gmpls-lbm-tdm-00.txt but again the use
> > > of the multiplier (MT) in that context is not recommended.
> > >
> > > Regards,
> > > - dimitri.
> > >
> > > Maarten Vissers wrote:
> > > >
> > > > Manoj,
> > > >
> > > > There is a difference between
> > > > 1) modifying the bandwidth of a connection and
> > > > 2) replacing the connection by a different connection.
> > > >
> > > > Add 2) A VC-3 connection is a connection in a VC-3 network layer, whereas a VC-4
> > > > connection is a connection in a VC-4 network layer. These network layers are
> > > > independent, and as such you can only replace a VC-3 connection by a VC-4
> > > > connection by releasing the VC-3 connection and requesting to set up a VC-4
> > > > connection.
> > > >
> > > > Add 1) You can modify the "bandwidth" of a group-connection (i.e. NVC(*) or MT
> > > > >= 1), by adding/removing connection members. If this group-connection supports a virtual concatenated trail (VC-n-Xv, ODUk-Xv) then the supported client link's bandwidth is modified as a result.
> > > >
> > > >         Example: Consider VC-4-Xv trail between nodes X and Y which
> > > >         supports an Ethernet link between these two nodes. When X is
> > > >         increased from 4 to 5, the Ethernet link bandwdith is increased
> > > >         from 600 Mb/s to 750 Mbit/s.
> > > >
> > > >         Assume that the VC-4-Xv trail is supported via two diverse
> > > >         routes (X - A - Y and X - B - Y), each providing two VC-4
> > > >         connections. Then the bandwidth modification will increase
> > > >         the number of connections on one of the two routes; e.g. the
> > > >         route via A. The associated traffic parameters will be:
> > > >
> > > >         - Connection X - A - Y traffic parameters
> > > >                 * Before increase: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0
> > > >                 * After increase:  ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0
> > > >         - Connection X - B - Y traffic parameters (unchanged)
> > > >                 * ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0
> > > >
> > > > What is needed is a MODIFY request which allows for an identified connection to
> > > > modify the MT value.
> > > >
> > > > (*) Note that the parameter NVC is interpreted as to represent the number of
> > > > components in a virtual concatenated signal connection... in this example NVC=4
> > > > and grows to NVC=5. As the virtual concatenated signal is transported via two
> > > > routes, each having half of the member connections, I have the impression that
> > > > MT is the parameter to use.
> > > >
> > > > Or to turn this around and look at the source for the bandwidth modification
> > > > first, we may assume that over the e.g. Ethernet UNI the call controller
> > > > (G.8080) at the network side receives a request to increase the enthernet link
> > > > from 600 to 750 Mbit/s. The call controller then decides to support this
> > > > ehternet bandwidth modification request by means of a modification of the
> > > > group-connection via route A... it then issues a connection modification request
> > > > for this group-connection... etc.
> > > >
> > > > Add 1) True bandwidth modification of an individual connection is possible for
> > > > e.g. ATM VP, ATM VC and MPLS connections. As long as the ATM VP, ATM VC or MPLS
> > > > links (G.805) over which the connection is transported have spare capacity, the
> > > > bandwidth of an individual VP, VC or LSP can be increased.
> > > >
> > > > Regards,
> > > >
> > > > Maarten
> > > >
> > > > manoj juneja wrote:
> > > > >
> > > > > Hi All,
> > > > >          If the bandwidth modification is not supported by GMPLS then
> > > > > it should be clearly mentioned in the drafts (at least the architecture
> > > > > draft). Please see the attached mail for reference.
> > > > >
> > > > > I am still not clear whether GMPLS supports SE-style of reservation.
> > > > > My original question related to SE-style of reservation was and I didn't
> > > > > get any reply on the mailing list :
> > > > >
> > > > >       "  I have a doubt related to SE style of reservation in GMPLS. As
> > > > > in RSVP-TE, multiple senders can share the reservation but they can be
> > > > > assigned different labels to distinguish different senders from one
> > > > > other.
> > > > > In GMPLS, as the label itself is a resource on the link, it means that
> > > > > if there are multiple senders in the same session sharing reservation,
> > > > > they should be assigned the same label. They can't be assigned
> > > > > different labels or is it that GMPLS does not support SE style of
> > > > > reservation ?"
> > > > >
> > > > > Please correct me if I am missing something.
> > > > >
> > > > > Regards,
> > > > > manoj.
> > > > >
> > > > > >From: Maarten Vissers <[email-masked]>
> > > > > >To: manoj juneja <[email-masked]>
> > > > > >CC: [email-masked]
> > > > > >Subject: Re: Bandwidth modification in GMPLS
> > > > > >Date: Fri, 30 Nov 2001 11:45:25 +0100
> > > > > >
> > > > > >Manoj,
> > > > > >
> > > > > >manoj juneja wrote:
> > > > > > >
> > > > > > > Hi All,
> > > > > > >         Is it possible to modify/increase the bandwidth of an existing
> > > > > >GMPLS
> > > > > > > tunnel ? I mean to say if I establish a VC-3 SDH LSP, will it be
> > > > > >possible to
> > > > > > > increase the bandwidth to say VC-4 ?
> > > > > >
> > > > > >No, this is not possible.
> > > > > >
> > > > > >Regards,
> > > > > >
> > > > > >Maarten
> > > > > >
> > > > > > >
> > > > > > > Should the new request be considered independent of previous one ?
> > > > > > >
> > > > > > > Regards,
> > > > > > > manoj.
> > > > > > >
> > > > > > > _________________________________________________________________
> > > > > > > Get your FREE download of MSN Explorer at
> > > > > >http://explorer.msn.com/intl.asp
> > > > > ><< mvissers.vcf >>
> > > > >
> > > > > _________________________________________________________________
> > > > > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
--------------28B3AE269E886FB78A163294
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------28B3AE269E886FB78A163294--

Delivery-date: Mon, 03 Dec 2001 20:43:04 -0800
Date: Mon, 3 Dec 2001 23:38:06 -0500 (EST)
From: Jim Boyle <[email-masked]>
To: "Ash, Gerald R (Jerry), ALCTA" <[email-masked]>
cc: <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-ash-multi-area-te-reqmts-01.txt

Hello, hello, there appears to be an echo in here.
One list please, as this is a discussion of requirements, I'll reply
just to the tewg list.

cheers,

Jim

On Mon, 3 Dec 2001, Ash, Gerald R (Jerry), ALCTA wrote:

> We would like to call for agreement that
>
> a) draft-ietf-tewg-restore-hierarchy-00.txt calls for multi-area TE
> requirements to be generated, but contains no such requirements (Section 3
> says "requirements for multi-area traffic engineering need to be developed
> to provide guidance for any necessary protocol extensions"), and
> b) draft-ash-multi-area-te-reqmts-01.txt be adopted as a multi-area TE
> requirements draft.
>
> In addition, Section 6.3 of draft-ietf-tewg-restore-hierarchy-00.txt says
> "To support edge-to-edge signaling in the above network scenarios within the
> framework of existing horizontal hierarchies, current traffic engineering
> (TE) methods [19, 5] may need to be extended. Requirements for multi-area TE
> need to be developed to provide guidance for any necessary protocol
> extensions."
>
> In regard to 'necessary protocol extensions', there are numerous multi-area
> TE approaches, so there is a need to converge on one or a subset of the
> approaches (rather than support them all).
> draft-ash-multi-area-te-rqmts-01.txt summarizes what protocol extensions
> have been proposed by various multi-area TE drafts, including:
> http://search.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-02.t
> xt
> http://search.ietf.org/internet-drafts/draft-venkatachalam-interarea-mpls-te
> -02.txt
> http://search.ietf.org/internet-drafts/draft-vasseur-mpls-computation-rsvp-0
> 0.txt
> http://www.ietf.org/internet-drafts/draft-lee-mpls-path-request-02.txt
> http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-02.txt.
>
> draft-ash-multi-area-te-rqmts-01.txt also compares the
> advantages/disadvantages of each proposed multi-area TE method, and how well
> the method meets the proposed requirements.  The analysis can be used to
> focus discussion and to select among the approaches.
>
> In summary, we would like to hear any objections to adopting
> draft-ash-multi-area-te-rqmts-01.txt as a multi-area TE requirements draft.
>
> Thanks,
> Jerry Ash
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, November 30, 2001 6:00 AM
> To: IETF-Announce; @wsscan.att.com
> Subject: I-D ACTION:draft-ash-multi-area-te-reqmts-01.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> 	Title		: Requirements for Multi-Area TE
> 	Author(s)	: J. Ash et al.
> 	Filename	: draft-ash-multi-area-te-reqmts-01.txt
> 	Pages		: 16
> 	Date		: 29-Nov-01
>
> This draft describes requirements for multi-area TE within the context of
> GMPLS.  Based on the requirements, the goal is to eventually provide
> protocol extensions needed for multi-area TE.  Various approaches to
> multi-area TE are considered, and these approaches are evaluated against the
> requirements.  These approaches include state dependent routing (SDR) LSP
> selection, event dependent routing (EDR) LSP selection, and time dependent
> routing (TDR) LSP selection.  These approaches include needs to support
> path-computation server (PCS) functionality, query functionality, crankback
> functionality, TE feedback functionality, and summary-LSA functionality. The
> target in future releases of this document will be to converge on a reduced
> subset of the required multi-area TE methods and protocol
> extensions.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ash-multi-area-te-reqmts-01.txt
>
>

Delivery-date: Mon, 03 Dec 2001 15:49:15 -0800
From: "Ash, Gerald R (Jerry), ALCTA" <[email-masked]>
To: [email-masked]
Cc: "Ash, Gerald R (Jerry), ALCTA" <[email-masked]>, [email-masked]
Subject: RE: I-D ACTION:draft-ash-multi-area-te-reqmts-01.txt
Date: Mon, 3 Dec 2001 18:48:12 -0500 

We would like to call for agreement that

a) draft-ietf-tewg-restore-hierarchy-00.txt calls for multi-area TE
requirements to be generated, but contains no such requirements (Section 3
says "requirements for multi-area traffic engineering need to be developed
to provide guidance for any necessary protocol extensions"), and
b) draft-ash-multi-area-te-reqmts-01.txt be adopted as a multi-area TE
requirements draft.

In addition, Section 6.3 of draft-ietf-tewg-restore-hierarchy-00.txt says
"To support edge-to-edge signaling in the above network scenarios within the
framework of existing horizontal hierarchies, current traffic engineering
(TE) methods [19, 5] may need to be extended. Requirements for multi-area TE
need to be developed to provide guidance for any necessary protocol
extensions."

In regard to 'necessary protocol extensions', there are numerous multi-area
TE approaches, so there is a need to converge on one or a subset of the
approaches (rather than support them all).
draft-ash-multi-area-te-rqmts-01.txt summarizes what protocol extensions
have been proposed by various multi-area TE drafts, including:
http://search.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-02.t
xt
http://search.ietf.org/internet-drafts/draft-venkatachalam-interarea-mpls-te
-02.txt
http://search.ietf.org/internet-drafts/draft-vasseur-mpls-computation-rsvp-0
0.txt
http://www.ietf.org/internet-drafts/draft-lee-mpls-path-request-02.txt
http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-02.txt.

draft-ash-multi-area-te-rqmts-01.txt also compares the
advantages/disadvantages of each proposed multi-area TE method, and how well
the method meets the proposed requirements.  The analysis can be used to
focus discussion and to select among the approaches.

In summary, we would like to hear any objections to adopting
draft-ash-multi-area-te-rqmts-01.txt as a multi-area TE requirements draft.

Thanks,
Jerry Ash

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, November 30, 2001 6:00 AM
To: IETF-Announce; @wsscan.att.com
Subject: I-D ACTION:draft-ash-multi-area-te-reqmts-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Requirements for Multi-Area TE
	Author(s)	: J. Ash et al.
	Filename	: draft-ash-multi-area-te-reqmts-01.txt
	Pages		: 16
	Date		: 29-Nov-01
	
This draft describes requirements for multi-area TE within the context of
GMPLS.  Based on the requirements, the goal is to eventually provide
protocol extensions needed for multi-area TE.  Various approaches to
multi-area TE are considered, and these approaches are evaluated against the
requirements.  These approaches include state dependent routing (SDR) LSP
selection, event dependent routing (EDR) LSP selection, and time dependent
routing (TDR) LSP selection.  These approaches include needs to support
path-computation server (PCS) functionality, query functionality, crankback
functionality, TE feedback functionality, and summary-LSA functionality. The
target in future releases of this document will be to converge on a reduced
subset of the required multi-area TE methods and protocol
extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ash-multi-area-te-reqmts-01.txt

Delivery-date: Mon, 03 Dec 2001 14:38:51 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: Re: Bandwidth modification in GMPLS
Date: Mon, 03 Dec 2001 15:34:30 -0700

Hi Dimitri/Marteen,

              I got the idea that the bandwidth modification for
SDH/SONET LSPs has to be supported by using the LBM draft. What about
the bandwidth modification for LSC LSPs ? How these are supported ? Are
the bandwidth modification for LSC LSPs need to be supported using the
RSVP-TE procedures ? I hope that the bandwidth modification for FSC
LSPs is not allowed ?

What about the SE style of reservation ? Is it supported in GMPLS ?

Is it that bandwidth modification for LSC/FSC LSPs are allowed by first
establsihing the new LSP and then tearing down the old (with/without
double booking of resources) ?

Please correct me I am wrong.

Regards,
manoj.

>From: Dimitri Papadimitriou <[email-masked]>
>To: Maarten Vissers <[email-masked]>
>CC: manoj juneja <[email-masked]>, [email-masked],   
>[email-masked], [email-masked],   "Helvoort, Huub van" 
><[email-masked]>
>Subject: Re: Bandwidth modification in GMPLS
>Date: Mon, 03 Dec 2001 22:02:54 +0100
>
>Maarten,
>
>First for people reading these e-mails the discussion here
>is not focused on a comparison between LCAS versus something
>else but only on control plane issues (more precisely which
>are the GMPLS mechanisms to be provided in order to enable
>bandwidth modification on different scenarios)
>
>Now, to continue the discussion we have defined in the GMPLS
>LBM I-D the Circuit ID and the LSP Sequence Number for that
>purpose (see Section 5.2). Together with the following rule:
>
>"All LSPs belonging to the same circuit MUST have the same
>Circuit ID. All LSPs MUST have a unique LSP sequence number
>in that Circuit ID, the LSP sequence number MUST be the
>sequence number of the first SPE/VC of the overall virtually
>concatenated circuit."
>
>Therefore, the scenarios you have defined are a combination
>of the methods described in Section 5.1 and 5.2.
>
>To illustrate this, let's take your example back:
>
> > Assume the connection controller selects VC-4 SNPs with addresses G1, G2 
>to
> > connect to route A, and G3, G4 to connect to route B. G5 to G7 are not 
>connected
> > VC-4 SNPs.
> >
> >         VC-4 with G1    via route A
> >         VC-4 with G2    via route A
> >         VC-4 with G3    via route B
> >         VC-4 with G4    via route B
> >         VC-4 with G5    not connected
> >         VC-4 with G6    not connected
> >         VC-4 with G7    not connected
>
>=> Circuit ID #1 (for instance) will include LSP SEQ ID#0
>    and LSP SEQ ID#1 (here we assume that Route A is link
>    diverse from Route B to preserve generality of the
>    proposed method)
>
> > Assume that the VC-4 trail via G2 is the first one which clears its 
>Signal Fail
> > (SF) condition, then this trail will pass through the signal with SEQ 
>ID=0. If
> > the second one is via G4, then this one passes through the signal with 
>SEQ ID=1.
> > If 3rd is via G3, then this gets SEQ ID=2 and finally via G1 gets SEQ 
>ID=3.
> >
> >         VC-4 with G1    via route A             SEQ ID=3
> >         VC-4 with G2    via route A             SEQ ID=0
> >         VC-4 with G3    via route B             SEQ ID=2
> >         VC-4 with G4    via route B             SEQ ID=1
> >         VC-4 with G5    not connected
> >         VC-4 with G6    not connected
> >         VC-4 with G7    not connected
>
>=> As such LSP SEQ ID#0 corresponds to the SEQ ID=0 and LSP
>    SEQ ID#1 to the SEQ ID=0
>
> > When adding the 5th VC-4 (e.g. via VC-4 SNP G5), this VC-4 will carry 
>SEQ ID #4.
> >
> >         VC-4 with G1    via route A             SEQ ID=3
> >         VC-4 with G2    via route A             SEQ ID=0
> >         VC-4 with G3    via route B             SEQ ID=2
> >         VC-4 with G4    via route B             SEQ ID=1
> >         VC-4 with G5    via route A             SEQ ID=4
> >         VC-4 with G6    not connected
> >         VC-4 with G7    not connected
>
>=> To update the LSP SEQ#0 you follow the rules defined in
>    the Section 5.1
>
> > Now route B fails; i.e. VC-4 with SEQ ID #1 and #2 fail. There will be 
>no change
> > of SEQ ID, only there will be an indication not to transmit over those 
>VC-4
> > trails. If later on it is decided to continue over route A only, the SEQ 
>IDs
> > are adapted as follows:
> >
> >         VC-4 with G1    via route A             SEQ ID=1
> >         VC-4 with G2    via route A             SEQ ID=0
> >         VC-4 with G3    not connected
> >         VC-4 with G4    not connected
> >         VC-4 with G5    via route A             SEQ ID=2
> >         VC-4 with G6    not connected
> >         VC-4 with G7    not connected
>
>=> you delete the VC-4 components with the re-sequencing as described
>    at the end of the Section 5.1 with the restriction that "SPEs/VCs
>    can be removed from an LSP but only at the end of that LSP (i.e.
>    starting at SPE/VC sequence number X)"
>
> > If the demand for bandwidth doubles again, it is possible to add say 
>three more
> > VC-4 trails via e.g. route C (X - C - Y); e.g. via G3, G4 and G6. If the 
>order
> > those trails become available is G6, G3, G4 then the SEQ IDs will be:
> >
> >         VC-4 with G1    via route A             SEQ ID=1
> >         VC-4 with G2    via route A             SEQ ID=0
> >         VC-4 with G3    via route C             SEQ ID=4
> >         VC-4 with G4    via route C             SEQ ID=5
> >         VC-4 with G5    via route A             SEQ ID=2
> >         VC-4 with G6    via route C             SEQ ID=3
> >         VC-4 with G7    not connected
>
>=> once again you follow the rule described in Section 5.1
>
>There is no need to use the multiplier for this purpose (this
>field is used for instance to operate a change on multiple LSP
>using the same message - it has been provided to avoid lengthy
>repetitions of the same operation)
>
>Once again (i think that Eric has already provided this comment)
>the scope of the LSP SEQ ID is not to reproduce the LCAS defined
>structures within the control plan but to provide a consistent
>control plane definition (allowing a level of consistency checking
>between the control plane and the transport plane.)
>
>Are we in agreement, or do you want further comparison of both
>methods ?
>
>Regards,
>- dimitri.
>
>Maarten Vissers wrote:
> >
> > Dimitri,
> >
> > Assume the VC-4-4v signal consisting of 4 VC-4 signals. Each VC-4 signal 
>has a
> > SEQ ID (0,1,2,3). Which SEQ ID is associated with which VC-4 is not not 
>fixed...
> > this is under control of LCAS and may change with time...
> >
> > When you set up the connection to transport the VC-4-4v signal via two 
>routes
> > (A, B), two VC-4 termination points will be connected to the A route, 
>two other
> > to the B route.
> > There are typically 7 VC-4 termination points per GbE port... let's 
>refer to
> > those 7 VC-4 termination points by means of SubNetwork Point (SNP) 
>addresses G1
> > .. G7.
> >
> > Assume the connection controller selects VC-4 SNPs with addresses G1, G2 
>to
> > connect to route A, and G3, G4 to connect to route B. G5 to G7 are not 
>connected
> > VC-4 SNPs.
> >
> >         VC-4 with G1    via route A
> >         VC-4 with G2    via route A
> >         VC-4 with G3    via route B
> >         VC-4 with G4    via route B
> >         VC-4 with G5    not connected
> >         VC-4 with G6    not connected
> >         VC-4 with G7    not connected
> >
> > Assume that the VC-4 trail via G2 is the first one which clears its 
>Signal Fail
> > (SF) condition, then this trail will pass through the signal with SEQ 
>ID=0. If
> > the second one is via G4, then this one passes through the signal with 
>SEQ ID=1.
> > If 3rd is via G3, then this gets SEQ ID=2 and finally via G1 gets SEQ 
>ID=3.
> >
> >         VC-4 with G1    via route A             SEQ ID=3
> >         VC-4 with G2    via route A             SEQ ID=0
> >         VC-4 with G3    via route B             SEQ ID=2
> >         VC-4 with G4    via route B             SEQ ID=1
> >         VC-4 with G5    not connected
> >         VC-4 with G6    not connected
> >         VC-4 with G7    not connected
> >
> > When adding the 5th VC-4 (e.g. via VC-4 SNP G5), this VC-4 will carry 
>SEQ ID #4.
> >
> >         VC-4 with G1    via route A             SEQ ID=3
> >         VC-4 with G2    via route A             SEQ ID=0
> >         VC-4 with G3    via route B             SEQ ID=2
> >         VC-4 with G4    via route B             SEQ ID=1
> >         VC-4 with G5    via route A             SEQ ID=4
> >         VC-4 with G6    not connected
> >         VC-4 with G7    not connected
> >
> > Now route B fails; i.e. VC-4 with SEQ ID #1 and #2 fail. There will be 
>no change
> > of SEQ ID, only there will be an indication not to transmit over those 
>VC-4
> > trails. If later on it is decided to continue over route A only, the SEQ 
>IDs
> > are adapted as follows:
> >
> >         VC-4 with G1    via route A             SEQ ID=1
> >         VC-4 with G2    via route A             SEQ ID=0
> >         VC-4 with G3    not connected
> >         VC-4 with G4    not connected
> >         VC-4 with G5    via route A             SEQ ID=2
> >         VC-4 with G6    not connected
> >         VC-4 with G7    not connected
> >
> > If the demand for bandwidth doubles again, it is possible to add say 
>three more
> > VC-4 trails via e.g. route C (X - C - Y); e.g. via G3, G4 and G6. If the 
>order
> > those trails become available is G6, G3, G4 then the SEQ IDs will be:
> >
> >         VC-4 with G1    via route A             SEQ ID=1
> >         VC-4 with G2    via route A             SEQ ID=0
> >         VC-4 with G3    via route C             SEQ ID=4
> >         VC-4 with G4    via route C             SEQ ID=5
> >         VC-4 with G5    via route A             SEQ ID=2
> >         VC-4 with G6    via route C             SEQ ID=3
> >         VC-4 with G7    not connected
> >
> > Looking at the connection setup details, I do not setup a VC-4-2v via A 
>and
> > another VC-4-2v via B initially... I do setup two groups of two VC-4
> > connections, which together support the  VC-4-4v trail; a VC-4-4v is not 
>the
> > same as two times a VC-4-2v. The use of NVC parameter here seems as such 
>not
> > appropriate. The only alternative present is the MT field.
> >
> > Alternative is to redefine NVC as "This field indicates the number of 
>identical
> > co-routed connections that are requested for this LSP. These connections 
>are all
> > of the same type."
> >
> >         But if I assume for a moment an alternative example in which the
> >         virtual concatenated endpoints are outside of the network of
> >         interest, then a UNI/E-NNI request using MT will result in the
> >         same connections being setup compared to such request using the
> >         modified NVC definition. What am I missing here?
> >
> > The traffic parameters for these two group-connections supporting the 
>VC-4-Xv
> > trail are thus:
> >
> > initially:
> >         route A: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1]
> >         route B: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1]
> >
> > after 5th VC-4 trail addition:
> >         route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]
> >         route B: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1]
> >
> > after route B connections being released:
> >         route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]
> >
> > after 4th, 5th, 6th connection being added via route C:
> >         route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]
> >         route C: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]
> >
> > To add the 3rd VC-4 connection to the VC-4 group-connection over route 
>A, a
> > MODIFY message is required. In your LBM document you propose to signal 
>the diff
> > value only, and consequently let the switch nodes compute the new total 
>(i.e.
> > new = original + diff). It will work as well to signal the new value and 
>let the
> > switch nodes compute the difference (i.e. diff = new - original). We 
>need to
> > evaluate the pros/cons of both approaches before selecting one.
> >
> > When the group-connection via route B is removed, this group-connection 
>has to
> > be released.
> >
> > When the group-connection via route C is to be added, this 
>group-connection has
> > to be setup.
> >
> > In addition to these cases, the MODIFY message has to support also the 
>decrease
> > case. E.g. assume that route A is more expensive than route C, then one 
>would
> > obviously prefer to release a VC-4 connection via route A when the total
> > bandwidth of the VC-4-Xv has to be shrunk from 900 Mb/s to 750 Mbit/s.
> >
> > after 3rd connection via route A is removed:
> >         route A: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1]
> >         route C: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]
> >
> >         VC-4 with G1    via route A             SEQ ID=1
> >         VC-4 with G2    via route A             SEQ ID=0
> >         VC-4 with G3    via route C             SEQ ID=3
> >         VC-4 with G4    via route C             SEQ ID=4
> >         VC-4 with G5    not connected
> >         VC-4 with G6    via route C             SEQ ID=2
> >         VC-4 with G7    not connected
> >
> > When using a MODIFY message which includes the new traffic parameters 
>(and not
> > the diff ones), the same MODIFY message can be used for addition and 
>removal of
> > connections to/from the group. This looks like a pro for a MODIFY 
>message
> > definition including the new traffic parameters.
> >
> > One note to the above scenarios... the set of 7 VC-4 SNPs can be 
>operated as a
> > single SNP Pool (SNPP). Instead of requesting the setup of a 
>group-connection to
> > SNPs G1 and G2 (route A) and to SNPs G3 and G4 (route B), one could 
>choose to
> > request the setup of two 2-group-connections to SNPP "G1-G7" and let the 
>local
> > switch node decide which specific SNPs will be allocated.
> > And the same SNPP "G1-G7" address can be used to add the 5th VC-4 
>connection,
> > and to add the 4/5/6th VC-4 connections via route C later on.
> >
> > I hope this clarifies some of the capabilities of the control plane 
>needs to
> > support when a group-connection is to be modified, and the operation of 
>the SEQ
> > ID within virtual concatenation with LCAS.
> >
> > Regards,
> >
> > Maarten
> >
> > Dimitri Papadimitriou wrote:
> > >
> > > Maarten,
> > >
> > > As per GMPLS-LBM, the multiplier field (MT) SHOULD not be used
> > > for bandwidth increase purpose since it is used for a different
> > > semantic.
> > >
> > > SPEs/VCs can only be added at the end of an LSP. For instance,
> > > when adding Y VC-4s to a VC-4-Xv (where each of the VC-4 is
> > > numbered from 0 to X-1), one obtains a VC-4-(X+Y)v with the
> > > sequence numbered from 0 to X+Y-1.
> > >
> > > The number Y of SPEs/VCs to add is given by the following
> > > equation: new NVC - old NVC. The first new SPE/VC will have a
> > > sequence number equals to the sequence number of the previously
> > > last VC + 1 (i.e. X).
> > >
> > > In such a case (in your below example)
> > >
> > >  - Connection X - A - Y traffic parameters
> > >    * Before increase VC-4-2v: ST=6, RCC=0, NCC=0, NVC=2, MT=1, T=0
> > >    * Increase to     VC-4-3v: ST=6, RCC=0, NCC=0, NVC=1, MT=1, T=0
> > >
> > >    remember that MT = 0 is an invalid value (as per draft-ietf-ccamp
> > >    -gmpls-sonet-sdh-02.txt)
> > >
> > > The MT field in this picture is used in the following way (the
> > > number Y of SPEs/VCs to add is given by the following equation:
> > > (new NVC * new MT) - (old NVC * old MT) just notice that in most
> > > cases new MT will be equal to old MT):
> > >
> > >  - 2 Connections X - A - Y traffic paramters
> > >    * Before increase VC-4-2v: ST=6, RCC=0, NCC=0, NVC=2, MT=2, T=0
> > >    * Increase to     VC-4-3v: ST=6, RCC=0, NCC=0, NVC=1, MT=2, T=0
> > >
> > > Your second example is depicted in the section 5.2 of the
> > > draft-mannie-ccamp-gmpls-lbm-tdm-00.txt but again the use
> > > of the multiplier (MT) in that context is not recommended.
> > >
> > > Regards,
> > > - dimitri.
> > >
> > > Maarten Vissers wrote:
> > > >
> > > > Manoj,
> > > >
> > > > There is a difference between
> > > > 1) modifying the bandwidth of a connection and
> > > > 2) replacing the connection by a different connection.
> > > >
> > > > Add 2) A VC-3 connection is a connection in a VC-3 network layer, 
>whereas a VC-4
> > > > connection is a connection in a VC-4 network layer. These network 
>layers are
> > > > independent, and as such you can only replace a VC-3 connection by a 
>VC-4
> > > > connection by releasing the VC-3 connection and requesting to set up 
>a VC-4
> > > > connection.
> > > >
> > > > Add 1) You can modify the "bandwidth" of a group-connection (i.e. 
>NVC(*) or MT
> > > > >= 1), by adding/removing connection members. If this 
>group-connection supports a virtual concatenated trail (VC-n-Xv, ODUk-Xv) 
>then the supported client link's bandwidth is modified as a result.
> > > >
> > > >         Example: Consider VC-4-Xv trail between nodes X and Y which
> > > >         supports an Ethernet link between these two nodes. When X is
> > > >         increased from 4 to 5, the Ethernet link bandwdith is 
>increased
> > > >         from 600 Mb/s to 750 Mbit/s.
> > > >
> > > >         Assume that the VC-4-Xv trail is supported via two diverse
> > > >         routes (X - A - Y and X - B - Y), each providing two VC-4
> > > >         connections. Then the bandwidth modification will increase
> > > >         the number of connections on one of the two routes; e.g. the
> > > >         route via A. The associated traffic parameters will be:
> > > >
> > > >         - Connection X - A - Y traffic parameters
> > > >                 * Before increase: ST=6, RCC=0, NCC=0, NVC=0, MT=2, 
>T=0
> > > >                 * After increase:  ST=6, RCC=0, NCC=0, NVC=0, MT=3, 
>T=0
> > > >         - Connection X - B - Y traffic parameters (unchanged)
> > > >                 * ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0
> > > >
> > > > What is needed is a MODIFY request which allows for an identified 
>connection to
> > > > modify the MT value.
> > > >
> > > > (*) Note that the parameter NVC is interpreted as to represent the 
>number of
> > > > components in a virtual concatenated signal connection... in this 
>example NVC=4
> > > > and grows to NVC=5. As the virtual concatenated signal is 
>transported via two
> > > > routes, each having half of the member connections, I have the 
>impression that
> > > > MT is the parameter to use.
> > > >
> > > > Or to turn this around and look at the source for the bandwidth 
>modification
> > > > first, we may assume that over the e.g. Ethernet UNI the call 
>controller
> > > > (G.8080) at the network side receives a request to increase the 
>enthernet link
> > > > from 600 to 750 Mbit/s. The call controller then decides to support 
>this
> > > > ehternet bandwidth modification request by means of a modification 
>of the
> > > > group-connection via route A... it then issues a connection 
>modification request
> > > > for this group-connection... etc.
> > > >
> > > > Add 1) True bandwidth modification of an individual connection is 
>possible for
> > > > e.g. ATM VP, ATM VC and MPLS connections. As long as the ATM VP, ATM 
>VC or MPLS
> > > > links (G.805) over which the connection is transported have spare 
>capacity, the
> > > > bandwidth of an individual VP, VC or LSP can be increased.
> > > >
> > > > Regards,
> > > >
> > > > Maarten
> > > >
> > > > manoj juneja wrote:
> > > > >
> > > > > Hi All,
> > > > >          If the bandwidth modification is not supported by GMPLS 
>then
> > > > > it should be clearly mentioned in the drafts (at least the 
>architecture
> > > > > draft). Please see the attached mail for reference.
> > > > >
> > > > > I am still not clear whether GMPLS supports SE-style of 
>reservation.
> > > > > My original question related to SE-style of reservation was and I 
>didn't
> > > > > get any reply on the mailing list :
> > > > >
> > > > >       "  I have a doubt related to SE style of reservation in 
>GMPLS. As
> > > > > in RSVP-TE, multiple senders can share the reservation but they 
>can be
> > > > > assigned different labels to distinguish different senders from 
>one
> > > > > other.
> > > > > In GMPLS, as the label itself is a resource on the link, it means 
>that
> > > > > if there are multiple senders in the same session sharing 
>reservation,
> > > > > they should be assigned the same label. They can't be assigned
> > > > > different labels or is it that GMPLS does not support SE style of
> > > > > reservation ?"
> > > > >
> > > > > Please correct me if I am missing something.
> > > > >
> > > > > Regards,
> > > > > manoj.
> > > > >
> > > > > >From: Maarten Vissers <[email-masked]>
> > > > > >To: manoj juneja <[email-masked]>
> > > > > >CC: [email-masked]
> > > > > >Subject: Re: Bandwidth modification in GMPLS
> > > > > >Date: Fri, 30 Nov 2001 11:45:25 +0100
> > > > > >
> > > > > >Manoj,
> > > > > >
> > > > > >manoj juneja wrote:
> > > > > > >
> > > > > > > Hi All,
> > > > > > >         Is it possible to modify/increase the bandwidth of an 
>existing
> > > > > >GMPLS
> > > > > > > tunnel ? I mean to say if I establish a VC-3 SDH LSP, will it 
>be
> > > > > >possible to
> > > > > > > increase the bandwidth to say VC-4 ?
> > > > > >
> > > > > >No, this is not possible.
> > > > > >
> > > > > >Regards,
> > > > > >
> > > > > >Maarten
> > > > > >
> > > > > > >
> > > > > > > Should the new request be considered independent of previous 
>one ?
> > > > > > >
> > > > > > > Regards,
> > > > > > > manoj.
> > > > > > >
> > > > > > > 
>_________________________________________________________________
> > > > > > > Get your FREE download of MSN Explorer at
> > > > > >http://explorer.msn.com/intl.asp
> > > > > ><< mvissers.vcf >>
> > > > >
> > > > > _________________________________________________________________
> > > > > Get your FREE download of MSN Explorer at 
>http://explorer.msn.com/intl.asp
><< dimitri.papadimitriou.vcf >>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Mon, 03 Dec 2001 13:05:22 -0800
Date: Mon, 03 Dec 2001 22:02:54 +0100
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: Maarten Vissers <[email-masked]>
CC: manoj juneja <[email-masked]>, [email-masked], [email-masked], [email-masked], "Helvoort, Huub van" <[email-masked]>
Subject: Re: Bandwidth modification in GMPLS

This is a multi-part message in MIME format.
--------------B286F227B1DAE0F570364138
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Maarten,

First for people reading these e-mails the discussion here
is not focused on a comparison between LCAS versus something 
else but only on control plane issues (more precisely which
are the GMPLS mechanisms to be provided in order to enable 
bandwidth modification on different scenarios)

Now, to continue the discussion we have defined in the GMPLS
LBM I-D the Circuit ID and the LSP Sequence Number for that 
purpose (see Section 5.2). Together with the following rule: 

"All LSPs belonging to the same circuit MUST have the same
Circuit ID. All LSPs MUST have a unique LSP sequence number 
in that Circuit ID, the LSP sequence number MUST be the 
sequence number of the first SPE/VC of the overall virtually 
concatenated circuit."

Therefore, the scenarios you have defined are a combination
of the methods described in Section 5.1 and 5.2.

To illustrate this, let's take your example back:

> Assume the connection controller selects VC-4 SNPs with addresses G1, G2 to
> connect to route A, and G3, G4 to connect to route B. G5 to G7 are not connected
> VC-4 SNPs.
> 
>         VC-4 with G1    via route A
>         VC-4 with G2    via route A
>         VC-4 with G3    via route B
>         VC-4 with G4    via route B
>         VC-4 with G5    not connected
>         VC-4 with G6    not connected
>         VC-4 with G7    not connected

=> Circuit ID #1 (for instance) will include LSP SEQ ID#0
   and LSP SEQ ID#1 (here we assume that Route A is link
   diverse from Route B to preserve generality of the 
   proposed method)
  
> Assume that the VC-4 trail via G2 is the first one which clears its Signal Fail
> (SF) condition, then this trail will pass through the signal with SEQ ID=0. If
> the second one is via G4, then this one passes through the signal with SEQ ID=1.
> If 3rd is via G3, then this gets SEQ ID=2 and finally via G1 gets SEQ ID=3.
> 
>         VC-4 with G1    via route A             SEQ ID=3
>         VC-4 with G2    via route A             SEQ ID=0
>         VC-4 with G3    via route B             SEQ ID=2
>         VC-4 with G4    via route B             SEQ ID=1
>         VC-4 with G5    not connected
>         VC-4 with G6    not connected
>         VC-4 with G7    not connected

=> As such LSP SEQ ID#0 corresponds to the SEQ ID=0 and LSP 
   SEQ ID#1 to the SEQ ID=0
 
> When adding the 5th VC-4 (e.g. via VC-4 SNP G5), this VC-4 will carry SEQ ID #4.
> 
>         VC-4 with G1    via route A             SEQ ID=3
>         VC-4 with G2    via route A             SEQ ID=0
>         VC-4 with G3    via route B             SEQ ID=2
>         VC-4 with G4    via route B             SEQ ID=1
>         VC-4 with G5    via route A             SEQ ID=4
>         VC-4 with G6    not connected
>         VC-4 with G7    not connected

=> To update the LSP SEQ#0 you follow the rules defined in
   the Section 5.1
 
> Now route B fails; i.e. VC-4 with SEQ ID #1 and #2 fail. There will be no change
> of SEQ ID, only there will be an indication not to transmit over those VC-4
> trails. If later on it is decided to continue over route A only, the SEQ IDs
> are adapted as follows:
> 
>         VC-4 with G1    via route A             SEQ ID=1
>         VC-4 with G2    via route A             SEQ ID=0
>         VC-4 with G3    not connected
>         VC-4 with G4    not connected
>         VC-4 with G5    via route A             SEQ ID=2
>         VC-4 with G6    not connected
>         VC-4 with G7    not connected

=> you delete the VC-4 components with the re-sequencing as described
   at the end of the Section 5.1 with the restriction that "SPEs/VCs 
   can be removed from an LSP but only at the end of that LSP (i.e. 
   starting at SPE/VC sequence number X)"
 
> If the demand for bandwidth doubles again, it is possible to add say three more
> VC-4 trails via e.g. route C (X - C - Y); e.g. via G3, G4 and G6. If the order
> those trails become available is G6, G3, G4 then the SEQ IDs will be:
> 
>         VC-4 with G1    via route A             SEQ ID=1
>         VC-4 with G2    via route A             SEQ ID=0
>         VC-4 with G3    via route C             SEQ ID=4
>         VC-4 with G4    via route C             SEQ ID=5
>         VC-4 with G5    via route A             SEQ ID=2
>         VC-4 with G6    via route C             SEQ ID=3
>         VC-4 with G7    not connected 

=> once again you follow the rule described in Section 5.1

There is no need to use the multiplier for this purpose (this 
field is used for instance to operate a change on multiple LSP 
using the same message - it has been provided to avoid lengthy
repetitions of the same operation)

Once again (i think that Eric has already provided this comment)
the scope of the LSP SEQ ID is not to reproduce the LCAS defined
structures within the control plan but to provide a consistent 
control plane definition (allowing a level of consistency checking 
between the control plane and the transport plane.)

Are we in agreement, or do you want further comparison of both
methods ?  

Regards,
- dimitri.

Maarten Vissers wrote:
> 
> Dimitri,
> 
> Assume the VC-4-4v signal consisting of 4 VC-4 signals. Each VC-4 signal has a
> SEQ ID (0,1,2,3). Which SEQ ID is associated with which VC-4 is not not fixed...
> this is under control of LCAS and may change with time...
> 
> When you set up the connection to transport the VC-4-4v signal via two routes
> (A, B), two VC-4 termination points will be connected to the A route, two other
> to the B route.
> There are typically 7 VC-4 termination points per GbE port... let's refer to
> those 7 VC-4 termination points by means of SubNetwork Point (SNP) addresses G1
> .. G7.
> 
> Assume the connection controller selects VC-4 SNPs with addresses G1, G2 to
> connect to route A, and G3, G4 to connect to route B. G5 to G7 are not connected
> VC-4 SNPs.
> 
>         VC-4 with G1    via route A
>         VC-4 with G2    via route A
>         VC-4 with G3    via route B
>         VC-4 with G4    via route B
>         VC-4 with G5    not connected
>         VC-4 with G6    not connected
>         VC-4 with G7    not connected
> 
> Assume that the VC-4 trail via G2 is the first one which clears its Signal Fail
> (SF) condition, then this trail will pass through the signal with SEQ ID=0. If
> the second one is via G4, then this one passes through the signal with SEQ ID=1.
> If 3rd is via G3, then this gets SEQ ID=2 and finally via G1 gets SEQ ID=3.
> 
>         VC-4 with G1    via route A             SEQ ID=3
>         VC-4 with G2    via route A             SEQ ID=0
>         VC-4 with G3    via route B             SEQ ID=2
>         VC-4 with G4    via route B             SEQ ID=1
>         VC-4 with G5    not connected
>         VC-4 with G6    not connected
>         VC-4 with G7    not connected
> 
> When adding the 5th VC-4 (e.g. via VC-4 SNP G5), this VC-4 will carry SEQ ID #4.
> 
>         VC-4 with G1    via route A             SEQ ID=3
>         VC-4 with G2    via route A             SEQ ID=0
>         VC-4 with G3    via route B             SEQ ID=2
>         VC-4 with G4    via route B             SEQ ID=1
>         VC-4 with G5    via route A             SEQ ID=4
>         VC-4 with G6    not connected
>         VC-4 with G7    not connected
> 
> Now route B fails; i.e. VC-4 with SEQ ID #1 and #2 fail. There will be no change
> of SEQ ID, only there will be an indication not to transmit over those VC-4
> trails. If later on it is decided to continue over route A only, the SEQ IDs
> are adapted as follows:
> 
>         VC-4 with G1    via route A             SEQ ID=1
>         VC-4 with G2    via route A             SEQ ID=0
>         VC-4 with G3    not connected
>         VC-4 with G4    not connected
>         VC-4 with G5    via route A             SEQ ID=2
>         VC-4 with G6    not connected
>         VC-4 with G7    not connected
> 
> If the demand for bandwidth doubles again, it is possible to add say three more
> VC-4 trails via e.g. route C (X - C - Y); e.g. via G3, G4 and G6. If the order
> those trails become available is G6, G3, G4 then the SEQ IDs will be:
> 
>         VC-4 with G1    via route A             SEQ ID=1
>         VC-4 with G2    via route A             SEQ ID=0
>         VC-4 with G3    via route C             SEQ ID=4
>         VC-4 with G4    via route C             SEQ ID=5
>         VC-4 with G5    via route A             SEQ ID=2
>         VC-4 with G6    via route C             SEQ ID=3
>         VC-4 with G7    not connected
> 
> Looking at the connection setup details, I do not setup a VC-4-2v via A and
> another VC-4-2v via B initially... I do setup two groups of two VC-4
> connections, which together support the  VC-4-4v trail; a VC-4-4v is not the
> same as two times a VC-4-2v. The use of NVC parameter here seems as such not
> appropriate. The only alternative present is the MT field.
> 
> Alternative is to redefine NVC as "This field indicates the number of identical
> co-routed connections that are requested for this LSP. These connections are all
> of the same type."
> 
>         But if I assume for a moment an alternative example in which the
>         virtual concatenated endpoints are outside of the network of
>         interest, then a UNI/E-NNI request using MT will result in the
>         same connections being setup compared to such request using the
>         modified NVC definition. What am I missing here?
> 
> The traffic parameters for these two group-connections supporting the VC-4-Xv
> trail are thus:
> 
> initially:
>         route A: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1]
>         route B: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1]
> 
> after 5th VC-4 trail addition:
>         route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]
>         route B: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1]
> 
> after route B connections being released:
>         route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]
> 
> after 4th, 5th, 6th connection being added via route C:
>         route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]
>         route C: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]
> 
> To add the 3rd VC-4 connection to the VC-4 group-connection over route A, a
> MODIFY message is required. In your LBM document you propose to signal the diff
> value only, and consequently let the switch nodes compute the new total (i.e.
> new = original + diff). It will work as well to signal the new value and let the
> switch nodes compute the difference (i.e. diff = new - original). We need to
> evaluate the pros/cons of both approaches before selecting one.
> 
> When the group-connection via route B is removed, this group-connection has to
> be released.
> 
> When the group-connection via route C is to be added, this group-connection has
> to be setup.
> 
> In addition to these cases, the MODIFY message has to support also the decrease
> case. E.g. assume that route A is more expensive than route C, then one would
> obviously prefer to release a VC-4 connection via route A when the total
> bandwidth of the VC-4-Xv has to be shrunk from 900 Mb/s to 750 Mbit/s.
> 
> after 3rd connection via route A is removed:
>         route A: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1]
>         route C: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]
> 
>         VC-4 with G1    via route A             SEQ ID=1
>         VC-4 with G2    via route A             SEQ ID=0
>         VC-4 with G3    via route C             SEQ ID=3
>         VC-4 with G4    via route C             SEQ ID=4
>         VC-4 with G5    not connected
>         VC-4 with G6    via route C             SEQ ID=2
>         VC-4 with G7    not connected
> 
> When using a MODIFY message which includes the new traffic parameters (and not
> the diff ones), the same MODIFY message can be used for addition and removal of
> connections to/from the group. This looks like a pro for a MODIFY message
> definition including the new traffic parameters.
> 
> One note to the above scenarios... the set of 7 VC-4 SNPs can be operated as a
> single SNP Pool (SNPP). Instead of requesting the setup of a group-connection to
> SNPs G1 and G2 (route A) and to SNPs G3 and G4 (route B), one could choose to
> request the setup of two 2-group-connections to SNPP "G1-G7" and let the local
> switch node decide which specific SNPs will be allocated.
> And the same SNPP "G1-G7" address can be used to add the 5th VC-4 connection,
> and to add the 4/5/6th VC-4 connections via route C later on.
> 
> I hope this clarifies some of the capabilities of the control plane needs to
> support when a group-connection is to be modified, and the operation of the SEQ
> ID within virtual concatenation with LCAS.
> 
> Regards,
> 
> Maarten
> 
> Dimitri Papadimitriou wrote:
> >
> > Maarten,
> >
> > As per GMPLS-LBM, the multiplier field (MT) SHOULD not be used
> > for bandwidth increase purpose since it is used for a different
> > semantic.
> >
> > SPEs/VCs can only be added at the end of an LSP. For instance,
> > when adding Y VC-4s to a VC-4-Xv (where each of the VC-4 is
> > numbered from 0 to X-1), one obtains a VC-4-(X+Y)v with the
> > sequence numbered from 0 to X+Y-1.
> >
> > The number Y of SPEs/VCs to add is given by the following
> > equation: new NVC - old NVC. The first new SPE/VC will have a
> > sequence number equals to the sequence number of the previously
> > last VC + 1 (i.e. X).
> >
> > In such a case (in your below example)
> >
> >  - Connection X - A - Y traffic parameters
> >    * Before increase VC-4-2v: ST=6, RCC=0, NCC=0, NVC=2, MT=1, T=0
> >    * Increase to     VC-4-3v: ST=6, RCC=0, NCC=0, NVC=1, MT=1, T=0
> >
> >    remember that MT = 0 is an invalid value (as per draft-ietf-ccamp
> >    -gmpls-sonet-sdh-02.txt)
> >
> > The MT field in this picture is used in the following way (the
> > number Y of SPEs/VCs to add is given by the following equation:
> > (new NVC * new MT) - (old NVC * old MT) just notice that in most
> > cases new MT will be equal to old MT):
> >
> >  - 2 Connections X - A - Y traffic paramters
> >    * Before increase VC-4-2v: ST=6, RCC=0, NCC=0, NVC=2, MT=2, T=0
> >    * Increase to     VC-4-3v: ST=6, RCC=0, NCC=0, NVC=1, MT=2, T=0
> >
> > Your second example is depicted in the section 5.2 of the
> > draft-mannie-ccamp-gmpls-lbm-tdm-00.txt but again the use
> > of the multiplier (MT) in that context is not recommended.
> >
> > Regards,
> > - dimitri.
> >
> > Maarten Vissers wrote:
> > >
> > > Manoj,
> > >
> > > There is a difference between
> > > 1) modifying the bandwidth of a connection and
> > > 2) replacing the connection by a different connection.
> > >
> > > Add 2) A VC-3 connection is a connection in a VC-3 network layer, whereas a VC-4
> > > connection is a connection in a VC-4 network layer. These network layers are
> > > independent, and as such you can only replace a VC-3 connection by a VC-4
> > > connection by releasing the VC-3 connection and requesting to set up a VC-4
> > > connection.
> > >
> > > Add 1) You can modify the "bandwidth" of a group-connection (i.e. NVC(*) or MT
> > > >= 1), by adding/removing connection members. If this group-connection supports a virtual concatenated trail (VC-n-Xv, ODUk-Xv) then the supported client link's bandwidth is modified as a result.
> > >
> > >         Example: Consider VC-4-Xv trail between nodes X and Y which
> > >         supports an Ethernet link between these two nodes. When X is
> > >         increased from 4 to 5, the Ethernet link bandwdith is increased
> > >         from 600 Mb/s to 750 Mbit/s.
> > >
> > >         Assume that the VC-4-Xv trail is supported via two diverse
> > >         routes (X - A - Y and X - B - Y), each providing two VC-4
> > >         connections. Then the bandwidth modification will increase
> > >         the number of connections on one of the two routes; e.g. the
> > >         route via A. The associated traffic parameters will be:
> > >
> > >         - Connection X - A - Y traffic parameters
> > >                 * Before increase: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0
> > >                 * After increase:  ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0
> > >         - Connection X - B - Y traffic parameters (unchanged)
> > >                 * ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0
> > >
> > > What is needed is a MODIFY request which allows for an identified connection to
> > > modify the MT value.
> > >
> > > (*) Note that the parameter NVC is interpreted as to represent the number of
> > > components in a virtual concatenated signal connection... in this example NVC=4
> > > and grows to NVC=5. As the virtual concatenated signal is transported via two
> > > routes, each having half of the member connections, I have the impression that
> > > MT is the parameter to use.
> > >
> > > Or to turn this around and look at the source for the bandwidth modification
> > > first, we may assume that over the e.g. Ethernet UNI the call controller
> > > (G.8080) at the network side receives a request to increase the enthernet link
> > > from 600 to 750 Mbit/s. The call controller then decides to support this
> > > ehternet bandwidth modification request by means of a modification of the
> > > group-connection via route A... it then issues a connection modification request
> > > for this group-connection... etc.
> > >
> > > Add 1) True bandwidth modification of an individual connection is possible for
> > > e.g. ATM VP, ATM VC and MPLS connections. As long as the ATM VP, ATM VC or MPLS
> > > links (G.805) over which the connection is transported have spare capacity, the
> > > bandwidth of an individual VP, VC or LSP can be increased.
> > >
> > > Regards,
> > >
> > > Maarten
> > >
> > > manoj juneja wrote:
> > > >
> > > > Hi All,
> > > >          If the bandwidth modification is not supported by GMPLS then
> > > > it should be clearly mentioned in the drafts (at least the architecture
> > > > draft). Please see the attached mail for reference.
> > > >
> > > > I am still not clear whether GMPLS supports SE-style of reservation.
> > > > My original question related to SE-style of reservation was and I didn't
> > > > get any reply on the mailing list :
> > > >
> > > >       "  I have a doubt related to SE style of reservation in GMPLS. As
> > > > in RSVP-TE, multiple senders can share the reservation but they can be
> > > > assigned different labels to distinguish different senders from one
> > > > other.
> > > > In GMPLS, as the label itself is a resource on the link, it means that
> > > > if there are multiple senders in the same session sharing reservation,
> > > > they should be assigned the same label. They can't be assigned
> > > > different labels or is it that GMPLS does not support SE style of
> > > > reservation ?"
> > > >
> > > > Please correct me if I am missing something.
> > > >
> > > > Regards,
> > > > manoj.
> > > >
> > > > >From: Maarten Vissers <[email-masked]>
> > > > >To: manoj juneja <[email-masked]>
> > > > >CC: [email-masked]
> > > > >Subject: Re: Bandwidth modification in GMPLS
> > > > >Date: Fri, 30 Nov 2001 11:45:25 +0100
> > > > >
> > > > >Manoj,
> > > > >
> > > > >manoj juneja wrote:
> > > > > >
> > > > > > Hi All,
> > > > > >         Is it possible to modify/increase the bandwidth of an existing
> > > > >GMPLS
> > > > > > tunnel ? I mean to say if I establish a VC-3 SDH LSP, will it be
> > > > >possible to
> > > > > > increase the bandwidth to say VC-4 ?
> > > > >
> > > > >No, this is not possible.
> > > > >
> > > > >Regards,
> > > > >
> > > > >Maarten
> > > > >
> > > > > >
> > > > > > Should the new request be considered independent of previous one ?
> > > > > >
> > > > > > Regards,
> > > > > > manoj.
> > > > > >
> > > > > > _________________________________________________________________
> > > > > > Get your FREE download of MSN Explorer at
> > > > >http://explorer.msn.com/intl.asp
> > > > ><< mvissers.vcf >>
> > > >
> > > > _________________________________________________________________
> > > > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
--------------B286F227B1DAE0F570364138
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------B286F227B1DAE0F570364138--

Delivery-date: Mon, 03 Dec 2001 10:51:35 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: LSC Interface Doubt ...
Date: Mon, 03 Dec 2001 11:47:39 -0700

Hi All,
        If I need to establish a bi-directional LSC LSP then do I
need to configure the remote end wavelengths on an LSC interface ? Is there 
any case where both the upstream and downstream labels of an bi-directional 
LSC LSP be same ?

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Mon, 03 Dec 2001 09:32:13 -0800
Date: Mon, 03 Dec 2001 18:28:43 +0100
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: "Brungard, Deborah A, ALCTA" <[email-masked]>
CC: "'Maarten Vissers'" <[email-masked]>, ccamp <[email-masked]>, q14/15 <[email-masked]>
Subject: Re: draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt

This is a multi-part message in MIME format.
--------------22AC4632B1AD86832A33DBA8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Deborah, all,

The "label" format issue is orthogonal to the discussion we
are engaging with this I-D. Nevertheless we have already 
received numerous comments and lengthy discuss this issue; 
therefore i think the decision will be endorsed during the 
next IETF meeting (... from the control plane viewpoint) but 
this orthogonality implies that different LSP Encoding Type 
for SDH and Sonet do not preclude "same" or better "equivalent" 
SUKLM label notation. So please do not take this I-D in this
context.

Now, you (Maarten as well by the way) are arguing since a long 
time now to merge the two corresponding SDH and SONET LSP 
Encoding Type codepoints into a single unique SDH/Sonet value. 
This is an different issue. My point of view on this issue has 
always been the same if the transmission plane defines inter-
working between both "encoding" without any explicit processing 
coming from control plane then your proposal can be considered. 
This would result in merging of the SDH and SONET codepoints 
into a G.707 codepoint for instance for the LSP Encoding Type.

Nevertheless it seems that when comparing your statement (as 
well as the conclusion of Maarten) and the differences listed 
it looks like there is a contradiction: if differences may 
appear between ETSI SDH interfaces themselves these differences 
can't be fewer when including ANSI SONET interfaces within 
the same set. I am not saying these differences are significative
for the control plane (Maarten describes them as "noise") but i
would like to open the discussion and clearly determine if they 
are impacting the control plane specification and corresponding 
processing - and to which extend of course: if we define a common
value and then plenty of exceptions what's the advantage ? -

This is one of the objective of the document, it is not at all 
the aim to "redefine" the interworking section 6.4 of G.707. Your 
point of view seems to be very clear: abstract these differences... 
we will see in our future discussions if this can be achieved 
without any impact on the control plane definition. Remember
also that this I-D is informational.

Hope this clarifies a little bit the situation. 

Regards,
- dimitri.

"Brungard, Deborah A, ALCTA" wrote:
> 
> Just back from vacation, my comments may be late but they are not much
> different from my previous comments. It seems we are still discussing one
> label vs. two...
> 
> I, and others, have continually commented that G.707 contains both ETSI SDH
> and ANSI SONET. It has always contained both. Supporting two gmpls general
> labels - one for ANSI T1.105 and one for ITU-T G.707 - is incorrect and adds
> unnecessary complexity for both equipment and operators. If by sdh, the
> implication is the TUG-3 structure, than refer to this explicitly in the
> label. Or say ETSI sdh. The preference by international operators is to
> simplify - we prefer one general label with technology specific details
> (TUG3 vs. TUG2) to be addressed by the technology specific documents. Other
> international operators have supported my comments on this exploder.  If
> this comment is not acceptable by the editors of the mpls-gen signaling
> document, it would be productive to have a response as to why?
> 
> If the draft on sonet-sdh-interwork is intended to be a rationale for
> maintaining two different labels, we can grueling go thru the exercise on
> this exploder and comment on it. I would propose (as Randy has already
> requested) for sdh/sonet technology discussions, let's take the discussion
> to the ITU-T exploder i.e. my first comment on this draft is the incorrect
> assumption that one needs to do transport level processing to interwork a
> VC-3 with a STS-1 SPE. This is incorrect - one does not touch the signal -
> no removal of fixed stuff bytes is required - the VC-3 and STS-1 SPE are
> equivalent for DS3 mappings and 34M (note the DS3 mapping is different than
> a 34M mapping). It is simply transporting a VC-3 containing a DS3 (or 34M)
> via AU3 or via AU4 (both supported in G.707!). If the authors of this
> document need additional info, just ask via the ITU-T Q11 exploder. Or we
> can discuss here...
> 
> We can continue to go thru the draft line by line, or to move this
> discussion quickly, if we go to section 4, the only interworking rule which
> is listed as needed, is the conversion of the LSP encoding type from sdh to
> sonet. IF the same label would apply, there would be no need for gmpls
> sdh-sonet interworking.
> 
> As Maarten notes below, there are many capabilities (positive
> connotation)/differences (negative connotation) within ETSI SDH and within
> ANSI SONET which do not allow for simply connecting two pieces of equipment
> either at a link level or end-to-end path level. A simple connection request
> may not even work between the same vendor's equipment :-( Defining different
> gmpls labels for sdh vs. sonet does not guarantee transport connectivity for
> SDH equipment or SONET equipment.
> 
> Deborah Brungard
> AT&T
> 
> 
> 
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Friday, November 23, 2001 4:49 AM
> To: Dimitri Papadimitriou
> Cc: ccamp; q14/15
> Subject: Re: draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt
> 
> Dimitri,
> 
> These differences are not specifically between SDH and SONET, you will also
> find
> a number of those between SDH and SDH or between SONET and SONET.
> Furthermore
> there are many more items that may require negotiation between elements in
> the
> connection.
> 
> If you look into the items you will notice that they are associated with the
> ports at the end of the connection or at intermediate points along the
> connection. As such a generic mechanism is required that establishes
> interworking for the case two ports (monitoring points) have different
> options
> selected.
> 
> Port types to be considered (just a first quick list; still very
> incomplete):
> 
> VC-m (m=11,12,2) port
> - Path Trace Identifier (J2): 16-byte and 64-byte path trace identifier
> strings
> - performance monitoring: BIP violation counting, Errored Block (EB)
> counting
> 
> VC-m (m=11,12,2) SNC protected port
> - all kind of SNC protection related parameters; e.g. SNC protection type,
> operation type, holdoff timer, etc.
> 
> VC-n (n=3,4,4-4c,4-16c,4-64c,4-256c) port
> - Path Trace Identifier (J1): 16-byte and 64-byte path trace identifier
> strings
> - Path Trace Identifier (J1): 64-byte path trace identifier formats
> - performance monitoring: BIP violation counting, Errored Block (EB)
> counting
> - user channel support: none/F2/F2F3/F3
> 
> VC-n (n=3,4,4-4c,4-16c,4-64c,4-256c) TCM port
> - Tandem connection monitoring: option I and II
> 
> VC-n (n=3,4,4-4c,4-16c,4-64c,4-256c) SNC protected port
> - all kind of SNC protection related parameters; e.g. SNC protection type,
> operation type, holdoff timer, etc.
> 
> STM-N (N=0,1,4,16,64,256) RS port
> - Regenerator Section Trace Identifier (J0): 1-byte and 16-byte section
> trace
> identifier strings
> - RS-DCC support
> - RS orderwire support
> - RS user channel support
> 
> STM-N MS port
> - older AU/STS pointer processors: ss-bits source processing: generation of
> "10" or "00" pattern, sink processing: verify presence of ss-bit pattern or
> ignore ss-bit pattern
> - newer AU/STS pointer processors: source generates ss-bits "10", sink
> ignores
> ss-bits ==> i.e. no interworking issue
> - Synchronisation Status Message (SSM) code set: option I, II or III (see
> G.781)
> - MS-REI: MS-REI supported/not-supported
> - STM-64 MS-REI: M0M1 or M1 only
> - MS-DCC support
> - RS orderwire support
> 
> STM-N (N=0,1,4,16,64,256) MS protected port
> - K1K2 MSP-APS switching type codes (uni-/bi-directional) in K2[6-8] for
> case of
> 1:n
> - all kind of MS protection related parameters (see G.841 and G.783); e.g.
> switching type, operation type, architecture type, etc.
> 
> STM-N (N=16,64,256) MS SPRing protected port
> - all kind of MS SPring protection related parameters
> 
> In general, the setup of the connection may have more than one phase
> associated:
>         1) connection bearer setup
>         2) connection monitoring setup
>         3) connection protection setup
> 
> The latter two phases require a detailed review of the MI_XXX parameters in
> the
> atomic functions in G.705, G.781, G.783, G.798 as well as a review of the
> set of
> atomic functions that represent normally optional functionality. Everything
> that
> allows selectivity on a per connection basis needs to be identified and
> allocated to connection monitoring and protection service signalling.
> 
> As you can see the few specific SONET/SDH differences are like noise and
> don't
> deserve separate LSP encoding types. Different LSP encoding types will
> complicate things more than help.
> 
> Regards,
> 
> Maarten
> 
> Dimitri Papadimitriou wrote:
> >
> > Hi Maarten,
> >
> > Thanks for these comments, it has been left for further consideration
> > within this document, but you know that they are "differences" between
> > Sonet and SDH OH in particular at the POH: J1/J2, B3, G3/K4 others are
> > mainly J0 at RS/SOH and K2 MS/LOH.
> >
> > Nevertheless, the key question is does it impact the control plane
> > specification ? And this is one of the purpose of this document (again
> > at a first stage).
> >
> > So, prior to propose a merge of the control plane code-points i would
> > like first to ask you if the current proposals made in order to provide
> > interoperability have been accepted and integrated. Knowing that we can
> > then evaluate the impact on the control plane and after we could
> > consider
> > your proposal.
> >
> > Many thanks,
> > - dimitri.
> >
> > Maarten Vissers wrote:
> > >
> > > All,
> > >
> > > I had a look on contribution
> > > "draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt" and would like to
> provide
> > > some comment.
> > >
> > > 1) I "liked" :-( the first sentence in section 2: "This section
> describes how
> > > SDH and SONET can interwork at the transport plane level." I only
> thought that
> > > this was already defined for many years in G.707. :-)
> > > A reference to section 6.4/G.707 seems more appropriate, as it will show
> > > interconnection in general between VC-3 transport in multiplex sections
> (AU-3,
> > > STS-1) and VC-4 paths (TU-3).
> > > It will also show interconnection between VC-11 transport in VC-11 link
> > > connections (TU-11, VT1.5) and VC-12 link connections (TU-12).
> > >
> > > 2) From a connection management perspective (scope of the control
> plane), the
> > > STS-1, Higher Order VC-3 and Lower Order VC-3 can be treated as one
> signal type.
> > > Interworking happens simply within the VC-3 layer network by means of
> connecting
> > > a (HO)VC-3/STS-1/(LO)VC-3 SNP with another (HO)VC-3/STS-1/(LO)VC-3 SNP.
> > > It is unimportant how the VC-3/STS-1 arrives/departs at/from the
> VC-3/STS-1 SNP;
> > > i.e. it could be within a STM-N/OC-N multiplex section, VC-4, E4 or E3.
> > >
> > > Links (link bundles) which support VC-3/STS-1 link connections will
> simply
> > > advertise this capability via their LSAs. A VC-3 fabric having two VC-3
> > > supporting links (link bundles) can "blindly" connect a VC-3/STS-1 SNP
> within
> > > the first link to a VC-3/STS-1 SNP within the second link.
> > >
> > > 3) SONET/SDH interworking GMPLS gateway function seems only necessary
> due to the
> > > fact that two LSP Encoding Types were allocated. If just one LSP
> Encoding Type
> > > would be allocated for both SDH and SONET, we would not require any
> GMPLS
> > > SDH-SONET interworking functionality.
> > >
> > > Therefore my proposal to merge SDH and SONET LSP Encoding types into one
> > > codepoint referred to as SDH/SONET.
> > >
> > > Regards,
> > >
> > > Maarten
--------------22AC4632B1AD86832A33DBA8
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------22AC4632B1AD86832A33DBA8--

Delivery-date: Mon, 03 Dec 2001 08:51:25 -0800
From: Jonathan Lang <[email-masked]>
To: 'Robin Qiu' <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Two week Last Call on LMP
Date: Mon, 3 Dec 2001 08:44:39 -0800 

Robin,
  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: Robin Qiu [mailto:[email-masked]]
> Sent: Tuesday, November 27, 2001 8:05 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: Two week Last Call on LMP
> 
> 
> 
> Hi,
> 
> A few comments/questions/requests. Appreciate your response:
> 1. In secion 2 "LMP Overview", paragraph 7, it says "however,
>    (for link connectivity verification procedure) the
>    control channel MUST terminate on the same two nodes that the
>    TE link spans". Why is this a requirement? This prevents a
>    "proxy" LMP implementation.
I'm not sure of the application here...

> 2. In section 3.2.1, it says "Once it has both sent and received a
>    Hello message, the control channel moves to the UP state". Should
>    a "valid" (expected RcvSeqNum) Hello be received before moving to
>    UP state?
We will add text to clarify that the received Hello must be "valid" as you
say.

> 3. In section 4 "Link Property Correlation MUST be done before the
>    link is brought up". Is it necessary to be "MUST"? Ramesh S.
>    brought up this issue too and Jonathan answered.
This will be changed to a SHOULD.

> 4. Section 5 "Verify Link Connectivity", paragraph 9 "It is also
>    permissible for the sender to terminate the Test procedure
>    without receiving a TestStatusSuccess or TestStatusFailure
>    message by sending an EndVerify message". This seems misleading
>    that the sender can't terminate the Test procedure in other
>    situations. Can it be more straightforward like this "It is also
>    permissible for the sender to terminate the Test procedure anytime
>    after sending BeginVerify. An EndVerify message SHOULD be sent
>    for this purpose."?
ok.

> 5. In section 7 "Message_Id Usage", can something be added to describe
>    how to identify a message_id value wrapping? Because the message_id
>    is made by the other node, it is impossible to know when it wraps
>    without some common rule. For example, can we dictate that
>    message_id be incremented by 1?
In the draft it states that the Message_Id value is incremental.  We will
change "incremental" to "monotonically increasing".

> 6. In section 8 "Graceful Restart", it doesn't cover the scenario where
>    both ends restart. In this case, both sides must process the
>    LinkSummary process as described in section 4.
Thanks.  We'll update the text.

> 7. In section 12.1 "Control Channel FSM", if a CC is brought down
>    administratively by one side, should it only be brought up by that
>    same side? Based on the current specification, either side can bring
>    it up again.
It seems to me that this is an implementation issue that I don't think needs
to be specified in the protocol spec.

> 8. In section 13, is 140 officially assigned to LMP?
no.  The protocol Id needs to be assigned by IANA.

> 9. In 13.6.5, 13.6.6, can object <VERIFY_ID> be put at the end of the
>    object list for both EndVerifyAck and Test, i.e.
>    <EndVerifyAck>::=<CommonHeader><MESSAGE_ID_ACK><VERIFY_ID>
>    <Test>::=<CommonHeader><LOCAL_INTERFACE_ID><VERIFY_ID>
>    This is consistent with other messages, so that it is easier to
>    comply with the recommendation "The transmission order SHOULD be
>    followed".
ok
> 10. In general, can default values be suggested for various LMP timers?
These are very closely related to the transmission medium for the control
channel, so I'm not sure it is appropriate.

> 11. In section 14.9 "BEGIN_VERIFY Class", what is the expected usage
>     for "Number of Data Links" on the receiving side? The Test process
>     is driven by the sending side until a EndVerify is received. Should
>     receiving side count the number of data links tested and take some
>     action after it exceeds "number of data links"?
After the receive side meets the "number of data links", it no longer has to
look for Test messages for that Verification procedure.

> 12. In section 14.12 "TE_LINK Class", don't know who has the authority
>     to request this, but C-Type=4 should be reserved for OIF, just as
>     in LOCAL_LINK_ID Class (14.3.1).
We will add C-Type=4 for OIF.

> 
> Regards,
> 
> Robin Qiu
> 
> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Monday, November 12, 2001 9:00 PM
> To: [email-masked]
> Subject: Two week Last Call on LMP
> 
> 
> Hi All,
> 
> This is to announce a two week Last Call on the LMP draft:
> draft-ietf-ccamp-lmp-02.txt.  This Last Call ends COB Wed Nov 28.
> 
> Please send questions, comments and requests for clarifications
> to the CCAMP list.
> 
> Kireeti.
> 
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at 
> http://explorer.msn.com/intl.asp
> 
> 

Delivery-date: Mon, 03 Dec 2001 06:55:37 -0800
Cc: manoj juneja <[email-masked]>, [email-masked], [email-masked], [email-masked], "Helvoort, Huub van" <[email-masked]>
Date: Mon, 03 Dec 2001 15:53:43 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Dimitri Papadimitriou <[email-masked]>
Original-CC: manoj juneja <[email-masked]>, [email-masked], [email-masked], [email-masked], "Helvoort, Huub van" <[email-masked]>
Subject: Re: Bandwidth modification in GMPLS

This is a multi-part message in MIME format.
--------------F2A3021FF59DA1AD3F1B7E40
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dimitri,

Assume the VC-4-4v signal consisting of 4 VC-4 signals. Each VC-4 signal has a
SEQ ID (0,1,2,3). Which SEQ ID is associated with which VC-4 is not not fixed...
this is under control of LCAS and may change with time...

When you set up the connection to transport the VC-4-4v signal via two routes
(A, B), two VC-4 termination points will be connected to the A route, two other
to the B route.
There are typically 7 VC-4 termination points per GbE port... let's refer to
those 7 VC-4 termination points by means of SubNetwork Point (SNP) addresses G1
.. G7.

Assume the connection controller selects VC-4 SNPs with addresses G1, G2 to
connect to route A, and G3, G4 to connect to route B. G5 to G7 are not connected
VC-4 SNPs.

	VC-4 with G1	via route A
	VC-4 with G2	via route A
	VC-4 with G3	via route B
	VC-4 with G4	via route B
	VC-4 with G5	not connected
	VC-4 with G6	not connected
	VC-4 with G7	not connected

Assume that the VC-4 trail via G2 is the first one which clears its Signal Fail
(SF) condition, then this trail will pass through the signal with SEQ ID=0. If
the second one is via G4, then this one passes through the signal with SEQ ID=1.
If 3rd is via G3, then this gets SEQ ID=2 and finally via G1 gets SEQ ID=3.

	VC-4 with G1	via route A		SEQ ID=3
	VC-4 with G2	via route A		SEQ ID=0
	VC-4 with G3	via route B		SEQ ID=2
	VC-4 with G4	via route B		SEQ ID=1
	VC-4 with G5	not connected
	VC-4 with G6	not connected
	VC-4 with G7	not connected

When adding the 5th VC-4 (e.g. via VC-4 SNP G5), this VC-4 will carry SEQ ID #4. 

	VC-4 with G1	via route A		SEQ ID=3
	VC-4 with G2	via route A		SEQ ID=0
	VC-4 with G3	via route B		SEQ ID=2
	VC-4 with G4	via route B		SEQ ID=1
	VC-4 with G5	via route A		SEQ ID=4
	VC-4 with G6	not connected
	VC-4 with G7	not connected

Now route B fails; i.e. VC-4 with SEQ ID #1 and #2 fail. There will be no change
of SEQ ID, only there will be an indication not to transmit over those VC-4
trails. If later on it is decided to continue over route A only, the SEQ IDs
are adapted as follows:

	VC-4 with G1	via route A		SEQ ID=1
	VC-4 with G2	via route A		SEQ ID=0
	VC-4 with G3	not connected
	VC-4 with G4	not connected
	VC-4 with G5	via route A		SEQ ID=2
	VC-4 with G6	not connected
	VC-4 with G7	not connected 

If the demand for bandwidth doubles again, it is possible to add say three more
VC-4 trails via e.g. route C (X - C - Y); e.g. via G3, G4 and G6. If the order
those trails become available is G6, G3, G4 then the SEQ IDs will be:

	VC-4 with G1	via route A		SEQ ID=1
	VC-4 with G2	via route A		SEQ ID=0
	VC-4 with G3	via route C		SEQ ID=4
	VC-4 with G4	via route C		SEQ ID=5
	VC-4 with G5	via route A		SEQ ID=2
	VC-4 with G6	via route C		SEQ ID=3
	VC-4 with G7	not connected 

Looking at the connection setup details, I do not setup a VC-4-2v via A and
another VC-4-2v via B initially... I do setup two groups of two VC-4
connections, which together support the  VC-4-4v trail; a VC-4-4v is not the
same as two times a VC-4-2v. The use of NVC parameter here seems as such not
appropriate. The only alternative present is the MT field. 

Alternative is to redefine NVC as "This field indicates the number of identical
co-routed connections that are requested for this LSP. These connections are all
of the same type."

	But if I assume for a moment an alternative example in which the
	virtual concatenated endpoints are outside of the network of 
	interest, then a UNI/E-NNI request using MT will result in the
	same connections being setup compared to such request using the
	modified NVC definition. What am I missing here?

The traffic parameters for these two group-connections supporting the VC-4-Xv
trail are thus:

initially:
	route A: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1]
	route B: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1]

after 5th VC-4 trail addition:
	route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]
	route B: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1]

after route B connections being released:
	route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]

after 4th, 5th, 6th connection being added via route C:
	route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]
	route C: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]

To add the 3rd VC-4 connection to the VC-4 group-connection over route A, a
MODIFY message is required. In your LBM document you propose to signal the diff
value only, and consequently let the switch nodes compute the new total (i.e.
new = original + diff). It will work as well to signal the new value and let the
switch nodes compute the difference (i.e. diff = new - original). We need to
evaluate the pros/cons of both approaches before selecting one.

When the group-connection via route B is removed, this group-connection has to
be released. 

When the group-connection via route C is to be added, this group-connection has
to be setup.

In addition to these cases, the MODIFY message has to support also the decrease
case. E.g. assume that route A is more expensive than route C, then one would
obviously prefer to release a VC-4 connection via route A when the total
bandwidth of the VC-4-Xv has to be shrunk from 900 Mb/s to 750 Mbit/s.

after 3rd connection via route A is removed:
	route A: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1]
	route C: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]

	VC-4 with G1	via route A		SEQ ID=1
	VC-4 with G2	via route A		SEQ ID=0
	VC-4 with G3	via route C		SEQ ID=3
	VC-4 with G4	via route C		SEQ ID=4
	VC-4 with G5	not connected
	VC-4 with G6	via route C		SEQ ID=2
	VC-4 with G7	not connected 

When using a MODIFY message which includes the new traffic parameters (and not
the diff ones), the same MODIFY message can be used for addition and removal of
connections to/from the group. This looks like a pro for a MODIFY message
definition including the new traffic parameters.

One note to the above scenarios... the set of 7 VC-4 SNPs can be operated as a
single SNP Pool (SNPP). Instead of requesting the setup of a group-connection to
SNPs G1 and G2 (route A) and to SNPs G3 and G4 (route B), one could choose to
request the setup of two 2-group-connections to SNPP "G1-G7" and let the local
switch node decide which specific SNPs will be allocated.
And the same SNPP "G1-G7" address can be used to add the 5th VC-4 connection,
and to add the 4/5/6th VC-4 connections via route C later on.

I hope this clarifies some of the capabilities of the control plane needs to
support when a group-connection is to be modified, and the operation of the SEQ
ID within virtual concatenation with LCAS.

Regards,

Maarten

Dimitri Papadimitriou wrote:
> 
> Maarten,
> 
> As per GMPLS-LBM, the multiplier field (MT) SHOULD not be used
> for bandwidth increase purpose since it is used for a different
> semantic.
> 
> SPEs/VCs can only be added at the end of an LSP. For instance,
> when adding Y VC-4s to a VC-4-Xv (where each of the VC-4 is
> numbered from 0 to X-1), one obtains a VC-4-(X+Y)v with the
> sequence numbered from 0 to X+Y-1.
> 
> The number Y of SPEs/VCs to add is given by the following
> equation: new NVC - old NVC. The first new SPE/VC will have a
> sequence number equals to the sequence number of the previously
> last VC + 1 (i.e. X).
> 
> In such a case (in your below example)
> 
>  - Connection X - A - Y traffic parameters
>    * Before increase VC-4-2v: ST=6, RCC=0, NCC=0, NVC=2, MT=1, T=0
>    * Increase to     VC-4-3v: ST=6, RCC=0, NCC=0, NVC=1, MT=1, T=0
> 
>    remember that MT = 0 is an invalid value (as per draft-ietf-ccamp
>    -gmpls-sonet-sdh-02.txt)
> 
> The MT field in this picture is used in the following way (the
> number Y of SPEs/VCs to add is given by the following equation:
> (new NVC * new MT) - (old NVC * old MT) just notice that in most
> cases new MT will be equal to old MT):
> 
>  - 2 Connections X - A - Y traffic paramters
>    * Before increase VC-4-2v: ST=6, RCC=0, NCC=0, NVC=2, MT=2, T=0
>    * Increase to     VC-4-3v: ST=6, RCC=0, NCC=0, NVC=1, MT=2, T=0
> 
> Your second example is depicted in the section 5.2 of the
> draft-mannie-ccamp-gmpls-lbm-tdm-00.txt but again the use
> of the multiplier (MT) in that context is not recommended.
> 
> Regards,
> - dimitri.
> 
> Maarten Vissers wrote:
> >
> > Manoj,
> >
> > There is a difference between
> > 1) modifying the bandwidth of a connection and
> > 2) replacing the connection by a different connection.
> >
> > Add 2) A VC-3 connection is a connection in a VC-3 network layer, whereas a VC-4
> > connection is a connection in a VC-4 network layer. These network layers are
> > independent, and as such you can only replace a VC-3 connection by a VC-4
> > connection by releasing the VC-3 connection and requesting to set up a VC-4
> > connection.
> >
> > Add 1) You can modify the "bandwidth" of a group-connection (i.e. NVC(*) or MT
> > >= 1), by adding/removing connection members. If this group-connection supports a virtual concatenated trail (VC-n-Xv, ODUk-Xv) then the supported client link's bandwidth is modified as a result.
> >
> >         Example: Consider VC-4-Xv trail between nodes X and Y which
> >         supports an Ethernet link between these two nodes. When X is
> >         increased from 4 to 5, the Ethernet link bandwdith is increased
> >         from 600 Mb/s to 750 Mbit/s.
> >
> >         Assume that the VC-4-Xv trail is supported via two diverse
> >         routes (X - A - Y and X - B - Y), each providing two VC-4
> >         connections. Then the bandwidth modification will increase
> >         the number of connections on one of the two routes; e.g. the
> >         route via A. The associated traffic parameters will be:
> >
> >         - Connection X - A - Y traffic parameters
> >                 * Before increase: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0
> >                 * After increase:  ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0
> >         - Connection X - B - Y traffic parameters (unchanged)
> >                 * ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0
> >
> > What is needed is a MODIFY request which allows for an identified connection to
> > modify the MT value.
> >
> > (*) Note that the parameter NVC is interpreted as to represent the number of
> > components in a virtual concatenated signal connection... in this example NVC=4
> > and grows to NVC=5. As the virtual concatenated signal is transported via two
> > routes, each having half of the member connections, I have the impression that
> > MT is the parameter to use.
> >
> > Or to turn this around and look at the source for the bandwidth modification
> > first, we may assume that over the e.g. Ethernet UNI the call controller
> > (G.8080) at the network side receives a request to increase the enthernet link
> > from 600 to 750 Mbit/s. The call controller then decides to support this
> > ehternet bandwidth modification request by means of a modification of the
> > group-connection via route A... it then issues a connection modification request
> > for this group-connection... etc.
> >
> > Add 1) True bandwidth modification of an individual connection is possible for
> > e.g. ATM VP, ATM VC and MPLS connections. As long as the ATM VP, ATM VC or MPLS
> > links (G.805) over which the connection is transported have spare capacity, the
> > bandwidth of an individual VP, VC or LSP can be increased.
> >
> > Regards,
> >
> > Maarten
> >
> > manoj juneja wrote:
> > >
> > > Hi All,
> > >          If the bandwidth modification is not supported by GMPLS then
> > > it should be clearly mentioned in the drafts (at least the architecture
> > > draft). Please see the attached mail for reference.
> > >
> > > I am still not clear whether GMPLS supports SE-style of reservation.
> > > My original question related to SE-style of reservation was and I didn't
> > > get any reply on the mailing list :
> > >
> > >       "  I have a doubt related to SE style of reservation in GMPLS. As
> > > in RSVP-TE, multiple senders can share the reservation but they can be
> > > assigned different labels to distinguish different senders from one
> > > other.
> > > In GMPLS, as the label itself is a resource on the link, it means that
> > > if there are multiple senders in the same session sharing reservation,
> > > they should be assigned the same label. They can't be assigned
> > > different labels or is it that GMPLS does not support SE style of
> > > reservation ?"
> > >
> > > Please correct me if I am missing something.
> > >
> > > Regards,
> > > manoj.
> > >
> > > >From: Maarten Vissers <[email-masked]>
> > > >To: manoj juneja <[email-masked]>
> > > >CC: [email-masked]
> > > >Subject: Re: Bandwidth modification in GMPLS
> > > >Date: Fri, 30 Nov 2001 11:45:25 +0100
> > > >
> > > >Manoj,
> > > >
> > > >manoj juneja wrote:
> > > > >
> > > > > Hi All,
> > > > >         Is it possible to modify/increase the bandwidth of an existing
> > > >GMPLS
> > > > > tunnel ? I mean to say if I establish a VC-3 SDH LSP, will it be
> > > >possible to
> > > > > increase the bandwidth to say VC-4 ?
> > > >
> > > >No, this is not possible.
> > > >
> > > >Regards,
> > > >
> > > >Maarten
> > > >
> > > > >
> > > > > Should the new request be considered independent of previous one ?
> > > > >
> > > > > Regards,
> > > > > manoj.
> > > > >
> > > > > _________________________________________________________________
> > > > > Get your FREE download of MSN Explorer at
> > > >http://explorer.msn.com/intl.asp
> > > ><< mvissers.vcf >>
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
--------------F2A3021FF59DA1AD3F1B7E40
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------F2A3021FF59DA1AD3F1B7E40--

Delivery-date: Mon, 03 Dec 2001 04:08:30 -0800
Date: Mon, 03 Dec 2001 13:05:20 +0100
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: Maarten Vissers <[email-masked]>
CC: manoj juneja <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Bandwidth modification in GMPLS

This is a multi-part message in MIME format.
--------------6C57299699DB8646AC2737A1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Maarten,

As per GMPLS-LBM, the multiplier field (MT) SHOULD not be used 
for bandwidth increase purpose since it is used for a different 
semantic. 

SPEs/VCs can only be added at the end of an LSP. For instance, 
when adding Y VC-4s to a VC-4-Xv (where each of the VC-4 is 
numbered from 0 to X-1), one obtains a VC-4-(X+Y)v with the 
sequence numbered from 0 to X+Y-1. 
    
The number Y of SPEs/VCs to add is given by the following 
equation: new NVC - old NVC. The first new SPE/VC will have a 
sequence number equals to the sequence number of the previously 
last VC + 1 (i.e. X). 

In such a case (in your below example)

 - Connection X - A - Y traffic parameters
   * Before increase VC-4-2v: ST=6, RCC=0, NCC=0, NVC=2, MT=1, T=0
   * Increase to     VC-4-3v: ST=6, RCC=0, NCC=0, NVC=1, MT=1, T=0
 
   remember that MT = 0 is an invalid value (as per draft-ietf-ccamp
   -gmpls-sonet-sdh-02.txt)
   
The MT field in this picture is used in the following way (the 
number Y of SPEs/VCs to add is given by the following equation: 
(new NVC * new MT) - (old NVC * old MT) just notice that in most
cases new MT will be equal to old MT):

 - 2 Connections X - A - Y traffic paramters
   * Before increase VC-4-2v: ST=6, RCC=0, NCC=0, NVC=2, MT=2, T=0
   * Increase to     VC-4-3v: ST=6, RCC=0, NCC=0, NVC=1, MT=2, T=0   

Your second example is depicted in the section 5.2 of the
draft-mannie-ccamp-gmpls-lbm-tdm-00.txt but again the use
of the multiplier (MT) in that context is not recommended.

Regards,
- dimitri.

Maarten Vissers wrote:
> 
> Manoj,
> 
> There is a difference between
> 1) modifying the bandwidth of a connection and
> 2) replacing the connection by a different connection.
> 
> Add 2) A VC-3 connection is a connection in a VC-3 network layer, whereas a VC-4
> connection is a connection in a VC-4 network layer. These network layers are
> independent, and as such you can only replace a VC-3 connection by a VC-4
> connection by releasing the VC-3 connection and requesting to set up a VC-4
> connection.
> 
> Add 1) You can modify the "bandwidth" of a group-connection (i.e. NVC(*) or MT
> >= 1), by adding/removing connection members. If this group-connection supports a virtual concatenated trail (VC-n-Xv, ODUk-Xv) then the supported client link's bandwidth is modified as a result.
> 
>         Example: Consider VC-4-Xv trail between nodes X and Y which
>         supports an Ethernet link between these two nodes. When X is
>         increased from 4 to 5, the Ethernet link bandwdith is increased
>         from 600 Mb/s to 750 Mbit/s.
> 
>         Assume that the VC-4-Xv trail is supported via two diverse
>         routes (X - A - Y and X - B - Y), each providing two VC-4
>         connections. Then the bandwidth modification will increase
>         the number of connections on one of the two routes; e.g. the
>         route via A. The associated traffic parameters will be:
> 
>         - Connection X - A - Y traffic parameters
>                 * Before increase: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0
>                 * After increase:  ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0
>         - Connection X - B - Y traffic parameters (unchanged)
>                 * ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0
> 
> What is needed is a MODIFY request which allows for an identified connection to
> modify the MT value.
> 
> (*) Note that the parameter NVC is interpreted as to represent the number of
> components in a virtual concatenated signal connection... in this example NVC=4
> and grows to NVC=5. As the virtual concatenated signal is transported via two
> routes, each having half of the member connections, I have the impression that
> MT is the parameter to use.
> 
> Or to turn this around and look at the source for the bandwidth modification
> first, we may assume that over the e.g. Ethernet UNI the call controller
> (G.8080) at the network side receives a request to increase the enthernet link
> from 600 to 750 Mbit/s. The call controller then decides to support this
> ehternet bandwidth modification request by means of a modification of the
> group-connection via route A... it then issues a connection modification request
> for this group-connection... etc.
> 
> Add 1) True bandwidth modification of an individual connection is possible for
> e.g. ATM VP, ATM VC and MPLS connections. As long as the ATM VP, ATM VC or MPLS
> links (G.805) over which the connection is transported have spare capacity, the
> bandwidth of an individual VP, VC or LSP can be increased.
> 
> Regards,
> 
> Maarten
> 
> manoj juneja wrote:
> >
> > Hi All,
> >          If the bandwidth modification is not supported by GMPLS then
> > it should be clearly mentioned in the drafts (at least the architecture
> > draft). Please see the attached mail for reference.
> >
> > I am still not clear whether GMPLS supports SE-style of reservation.
> > My original question related to SE-style of reservation was and I didn't
> > get any reply on the mailing list :
> >
> >       "  I have a doubt related to SE style of reservation in GMPLS. As
> > in RSVP-TE, multiple senders can share the reservation but they can be
> > assigned different labels to distinguish different senders from one
> > other.
> > In GMPLS, as the label itself is a resource on the link, it means that
> > if there are multiple senders in the same session sharing reservation,
> > they should be assigned the same label. They can't be assigned
> > different labels or is it that GMPLS does not support SE style of
> > reservation ?"
> >
> > Please correct me if I am missing something.
> >
> > Regards,
> > manoj.
> >
> > >From: Maarten Vissers <[email-masked]>
> > >To: manoj juneja <[email-masked]>
> > >CC: [email-masked]
> > >Subject: Re: Bandwidth modification in GMPLS
> > >Date: Fri, 30 Nov 2001 11:45:25 +0100
> > >
> > >Manoj,
> > >
> > >manoj juneja wrote:
> > > >
> > > > Hi All,
> > > >         Is it possible to modify/increase the bandwidth of an existing
> > >GMPLS
> > > > tunnel ? I mean to say if I establish a VC-3 SDH LSP, will it be
> > >possible to
> > > > increase the bandwidth to say VC-4 ?
> > >
> > >No, this is not possible.
> > >
> > >Regards,
> > >
> > >Maarten
> > >
> > > >
> > > > Should the new request be considered independent of previous one ?
> > > >
> > > > Regards,
> > > > manoj.
> > > >
> > > > _________________________________________________________________
> > > > Get your FREE download of MSN Explorer at
> > >http://explorer.msn.com/intl.asp
> > ><< mvissers.vcf >>
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
--------------6C57299699DB8646AC2737A1
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------6C57299699DB8646AC2737A1--

Delivery-date: Mon, 03 Dec 2001 03:38:19 -0800
Cc: [email-masked], [email-masked], [email-masked]
Date: Mon, 03 Dec 2001 12:32:13 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: manoj juneja <[email-masked]>
Original-CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Bandwidth modification in GMPLS

This is a multi-part message in MIME format.
--------------99607886477D13FE72C680C3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Manoj,

There is a difference between 
1) modifying the bandwidth of a connection and 
2) replacing the connection by a different connection.

Add 2) A VC-3 connection is a connection in a VC-3 network layer, whereas a VC-4
connection is a connection in a VC-4 network layer. These network layers are
independent, and as such you can only replace a VC-3 connection by a VC-4
connection by releasing the VC-3 connection and requesting to set up a VC-4
connection.

Add 1) You can modify the "bandwidth" of a group-connection (i.e. NVC(*) or MT
>= 1), by adding/removing connection members. If this group-connection supports a virtual concatenated trail (VC-n-Xv, ODUk-Xv) then the supported client link's bandwidth is modified as a result.

	Example: Consider VC-4-Xv trail between nodes X and Y which
	supports an Ethernet link between these two nodes. When X is
	increased from 4 to 5, the Ethernet link bandwdith is increased
	from 600 Mb/s to 750 Mbit/s. 

	Assume that the VC-4-Xv trail is supported via two diverse 
	routes (X - A - Y and X - B - Y), each providing two VC-4 
	connections. Then the bandwidth modification will increase 
	the number of connections on one of the two routes; e.g. the
	route via A. The associated traffic parameters will be:

	- Connection X - A - Y traffic parameters
		* Before increase: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0
		* After increase:  ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0
	- Connection X - B - Y traffic parameters (unchanged)
		* ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0

What is needed is a MODIFY request which allows for an identified connection to
modify the MT value.

(*) Note that the parameter NVC is interpreted as to represent the number of
components in a virtual concatenated signal connection... in this example NVC=4
and grows to NVC=5. As the virtual concatenated signal is transported via two
routes, each having half of the member connections, I have the impression that
MT is the parameter to use.

Or to turn this around and look at the source for the bandwidth modification
first, we may assume that over the e.g. Ethernet UNI the call controller
(G.8080) at the network side receives a request to increase the enthernet link
from 600 to 750 Mbit/s. The call controller then decides to support this
ehternet bandwidth modification request by means of a modification of the
group-connection via route A... it then issues a connection modification request
for this group-connection... etc.

Add 1) True bandwidth modification of an individual connection is possible for
e.g. ATM VP, ATM VC and MPLS connections. As long as the ATM VP, ATM VC or MPLS
links (G.805) over which the connection is transported have spare capacity, the
bandwidth of an individual VP, VC or LSP can be increased.

Regards,

Maarten

manoj juneja wrote:
> 
> Hi All,
>          If the bandwidth modification is not supported by GMPLS then
> it should be clearly mentioned in the drafts (at least the architecture
> draft). Please see the attached mail for reference.
> 
> I am still not clear whether GMPLS supports SE-style of reservation.
> My original question related to SE-style of reservation was and I didn't
> get any reply on the mailing list :
> 
>       "  I have a doubt related to SE style of reservation in GMPLS. As
> in RSVP-TE, multiple senders can share the reservation but they can be
> assigned different labels to distinguish different senders from one
> other.
> In GMPLS, as the label itself is a resource on the link, it means that
> if there are multiple senders in the same session sharing reservation,
> they should be assigned the same label. They can't be assigned
> different labels or is it that GMPLS does not support SE style of
> reservation ?"
> 
> Please correct me if I am missing something.
> 
> Regards,
> manoj.
> 
> >From: Maarten Vissers <[email-masked]>
> >To: manoj juneja <[email-masked]>
> >CC: [email-masked]
> >Subject: Re: Bandwidth modification in GMPLS
> >Date: Fri, 30 Nov 2001 11:45:25 +0100
> >
> >Manoj,
> >
> >manoj juneja wrote:
> > >
> > > Hi All,
> > >         Is it possible to modify/increase the bandwidth of an existing
> >GMPLS
> > > tunnel ? I mean to say if I establish a VC-3 SDH LSP, will it be
> >possible to
> > > increase the bandwidth to say VC-4 ?
> >
> >No, this is not possible.
> >
> >Regards,
> >
> >Maarten
> >
> > >
> > > Should the new request be considered independent of previous one ?
> > >
> > > Regards,
> > > manoj.
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at
> >http://explorer.msn.com/intl.asp
> ><< mvissers.vcf >>
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
--------------99607886477D13FE72C680C3
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------99607886477D13FE72C680C3--