Re: Virtual concat, LCAS and T1 documents... RE: Please Clarify Doubts regarding RGT & RNC

[Stephen Trowbridge <sjtrowbridge@lucent.com>]

Greg,
Actually, ITU-T DOES offer a similar service.
You can download up to 3 documents per email address for free. Go to
the main page:
http://www.itu.int/
choose "Electronic Bookshop", then select:
I wish to REGISTER in order to download up to three (3) Recommendations free of charge

Regards,
Steve Trowbridge
Vice Chairman, ITU-T Study Group 15


"Bernstein, Greg" wrote:
> 
> Hi folks, the only way of doing this with circuit switching is via an
> inverse multiplexing process like virtual concatenation plus a protocol such
> as the link channel adjustment scheme (LCAS).  This is a relatively new
> development, i.e., to find it you'll need to look at the letter ballot for
> the new version of the "basic SONET rates and formats" document: T1.105-200x
> T1X1.5/2000-193R1  (Draft ANSI T1.105-200x - Contents of LB809 with addendum
> information from T1X1.5/2000-129R2).  This can be found by rummaging through
> the www.t1.org web site.
> 
> Also standards documents can be obtain for free from the ATIS document
> center (look at the small print at the bottom of the web page for one free
> electronic download of the document you're interested in. Note that you can
> only download the same document once or so it says.  Hmmm I haven't tested
> this though).  Most of the SONET documents are in the T1.105 series.
> Unfortunately ITU doesn't offer a similar service.
> Hope this helps.
> 
> Greg B.
> ***********************************
> Dr. Greg M. Bernstein
> Senior Scientist, Ciena Corporation
> 
> -----Original Message-----
> From: Hai Vodinh [mailto:HVoDinh@turinnetworks.com]
> Sent: Wednesday, March 21, 2001 12:00 PM
> To: 'Vishal Sharma'; Hai Vodinh; 'Zhi-Wei Lin'
> Cc: ccamp@ops.ietf.org; Bernstein, Greg
> Subject: RE: Please Clarify Doubts regarding RGT & RNC
> 
> Vishal, Greg,
> 
> Thanks for the clarification on the difference between VC and bundling.  On
> my last question, isn't the abibility to get additional bandwidth for an
> already established signal a crucial requirement for the type of
> bandwidth-on-demand or more appropriately bandwidth-modification service
> that we are thinking of today?
> 
> Thanks,
> Hai
> 
> -----Original Message-----
> From: Vishal Sharma [mailto:vishal@JasmineNetworks.com]
> Sent: Tuesday, March 20, 2001 11:45 PM
> To: 'Hai Vodinh'; 'Zhi-Wei Lin'
> Cc: ccamp@ops.ietf.org; Greg Bernstein (E-mail)
> Subject: RE: Please Clarify Doubts regarding RGT & RNC
> 
> Hi Hai,
> 
> Greg has already provided an answer. I just wanted to add that in
> my initial explanation to Manoj, I did point out what the difference
> was between virtual concat. and bundling. For the intermediate
> nodes, there is no difference, the differene only comes in for
> the end points, which in the virtual concat. case have to know
> which channels are virtually concatenated, and compensate for
> differential delay across these channels.
> 
> > -----Original Message-----
> > From: Hai Vodinh [mailto:HVoDinh@turinnetworks.com]
> > Sent: Tuesday, March 20, 2001 5:14 PM
> > To: 'Zhi-Wei Lin'; Vishal Sharma
> > Cc: ccamp@ops.ietf.org
> > Subject: RE: Please Clarify Doubts regarding RGT & RNC
> >
> >
> > I tend to agree with Zhi-Wei that when you need to set up multiple
> > connections these should be done separately (except perhaps
> > in the virtual
> > concatenated case) to keep the signaling protocol simple.
> >
> > I'm following the discussion and still don't have a clear
> > idea why both
> > virtual concatenation and bundling RGT are needed.  What is
> > the difference
> > between the two types?
> >
> > Here is another question: let's say I have a STS-1-4v SPE
> > already set up,
> > now I need to add 2 more STS-1 to make it a STS-1-6v SPE, how
> > do I signal to
> > the network that the additional 2 STS-1s need to be co-routed
> > with the other
> 
> I am not sure that there is any easy way to day to perform such
> signaling.
> 
> >
> > -----Original Message-----
> > From: Zhi-Wei Lin [mailto:zwlin@lucent.com]
> > Sent: Tuesday, March 20, 2001 12:17 PM
> > To: Vishal Sharma
> > Cc: 'manoj juneja'; ccamp@ops.ietf.org
> > Subject: Re: Please Clarify Doubts regarding RGT & RNC
> >
> >
> > Hi Vishal,
> >
> >
> >
> > > > 3 STS-3: ??? How would you signal this? Not supported?
> > >
> > > What do you wish to signal here? Three groups of STS-3 each?
> > > What does it mean? The STS-3 is a bundle, and you wish to signal
> > > a bundle of bundles?
> > >
> > > If that is so, and unless I am missing something, I think you'd have
> > > to signal them separately.
> > >
> > > BTW, I wasn't immediately able to see how this would be signaled
> > > even using the codepoints proposed in
> > > draft-lin-ccamp-ipo-common-label-request-01.txt.
> > >
> >
> > I don't understand how that is a bundle. STS-3 as defined in
> > the T1.105
> > is the entire signal. So then if you can signal multiple STS-1s, my
> > question was why is this not supported for STS-3 or other STS-X.
> >
> > Right, draft-lin assumes that when you need to set up multiple
> > connections, these are done separately. Adding the capability for
> > multiple connection set-ups as part of the signaling mechanism is not
> > really necessary. Remember that the signaling mechanism is not the GUI
> > to the customer. The GUI that the customer sees can provide that
> > feature. The interface from GUI to the signaling can be a
> > batch function
> > that sets up the multiple connections. This simplifies the signaling
> > protocol, allows "bundling" of different connection types
> > set-up at once
> > (e.g., if customer wants to set up  3 STS-3c, 4 STS-7v, and 2
> > STS-48c at
> > once) via a batch process, and does not complicate the protocol from
> > having to handle this issue.
> >
> > Some of the points mentioned by Ewart in the OIF discussion was: when
> > multiple connections are handled at once, what are the characteristics
> > of these connections? Do they all terminate at the same location? Are
> > they all co-routed or separately routed? How many labels do
> > you return?
> > If one label is returned, what happens when one connection
> > failed? What
> > if the multiple connections have different destinations? etc.
> >
> >
> > > > 1 STS-3c: RNC=3, RGT=2 (contiguous standard) or 3 (contiguous
> > > > arbitrary)
> > > > 1 STS-4c: RNC=4, RGT=3 (contiguous arbitrary)
> > > >
> > > > ==> 3 STS-3c: ??? How would you signal this? Not supported?
> > >
> > > Again, as things stand today, you'd have to signal this separately.
> > >
> > > First, is there a requirement to signal these this way? Assuming
> > > there is, is there a proposal that allows for that?
> > >
> >
> > I wasn't sure whether there is requirement or not. I was
> > extending your
> > example with what was offered currently. My view was that it
> > seems that
> > some capabilities are available to certain signal types and
> > not to other
> > signal types. We probably need to extend or clarify the text,
> > or adopt a
> > different position in terms of what should and should not be
> > provided by
> > the signaling protocol, and leave "added features" to
> > separate functions
> > (the batch process I mentioned above).
> >
> >
> > > I cannot see how
> > draft-lin-ccamp-ipo-common-label-request-01.txt would
> > > do it either, since the RNC has been absorbed into the signal type
> > > in that case, and not all cases are enumerated.
> > >
> >
> > See above for comment.
> >
> > > > 1 STS-7v: RNC=7, RGT=1 (virtual)
> > > >
> > > > ==> 7 STS-7v: ??? How would you signal this? Not supported?
> > >
> > > Same as the two above.
> > >
> >
> > See above (sorry, too many "aboves") ;-)
> >
> > Zhi
> >