[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt



Yangguang,

The TSpec, as I understand it, carries only bandwidth information
for some label types. As a result, we do need the encoding type 
and the switching capability field for a mutli-service platform 
to allocate resources and/or validate a particular connection 
encoding type. I think we agree until here. 

For example, if a TE link has both SDH and SONET "ports" bundled 
within it (a list of interface switching capability descriptors 
allow for this), it has to be notified that this request is for a 
SONET port. This is not negotiation, it is a request to get a resource
for a port that can carry a particular type of connection. The TE-link 
should not at this time give you a resource label for a SDH port when 
you request for a SONET port. As a result, this field also needs to be 
carried while signaling setup request is made. 

Thanks,
Ayan
 



-----Original Message-----
From: Yangguang Xu [mailto:xuyg@lucent.com]
Sent: Wednesday, August 01, 2001 4:15 PM
To: Ayan Banerjee
Cc: 'ccamp@ops.ietf.org'; 'manojkumarjuneja@hotmail.com'
Subject: Re: Doubt in draft
draft-ietf-mpls-generalized-signalling-05.txt


Ayan,

I think Manoj is right. In GMPLS signaling, encoding type and signal type in
TSpec together should form one meaningful unit to specify what type of LSP
to
create. In another word, you should parse the traffic parameters according
to
the encoding type. So the encoding type is NOT for the "port". Encoding type
and
other traffic parameters together should be able to specify which type of
LSP to
create. BTW, at the signaling time, you don't need to specify/negotiate
"port"
attribute. If encoding type is a "port" attribute as you stated, it
shouldn't be
in GMPLS signaling.

Regards,

Yangguang



Ayan Banerjee wrote:
> 
> Manoj,
> 
> It is possible that a "port" on a multi-service platform may behave
> dynamically in one of two (or more) different ways depending on the
> internal switching capabilities. For example, a port may be described
> to be PSC capable and TDM capable at the same time. This capability
> of the port is the "switching capability" of a port. The "switching
> capability" and the "encoding" are orthogonal fields. For example,
> it is possible to request for a TDM switching capability with
> specific encoding of SONET (or SDH). For a distant node to be aware
> of how the LSP is to be setup (that is for the transit node to set up
> its internal switching appropriately) and to allow for a particular
> valid encoding on the port for this requested switching capability, it
> is necessary to carry both fields (in the connection setup request).
> 
> The MAX LSP bandwidth that is announced per switching capability lets
> a remote (source) node whether there is available bandwidth with respect
> to connection setup. It may be desired to restrict the switching
capability
> of a port based on the connection setup priority. The announcements
> via routing of the LSP bandwidth across each priority for a given
> switching capability serves this purpose.
> 
> Thanks,
> Ayan
> 
> 
> -----Original Message-----
> From: manoj juneja [mailto:manojkumarjuneja@hotmail.com]
> Sent: Wednesday, August 01, 2001 10:43 AM
> To: jdrake@calient.net; zwlin@lucent.com
> Cc: ccamp@ops.ietf.org; lberger@movaz.com; Eric.Mannie@ebone.com;
> kireeti@juniper.net
> Subject: RE: Doubt in draft
> draft-ietf-mpls-generalized-signalling-05.txt
> 
> Hi John,
>          There are "switching Capability" and "encoding" fields inside
> "switching type" field. The switching capability includes the same set of
> values as LSP encoding type. Even encoding field also indicate LSP
encoding
> type. What is the need for this duplication in Generalized Label Request
> Object? The max. LSP bandwidth for different priority levels (p= 0...7) is
> also specified and is only valid in case switching cap/LSP encoding type
is
> TDM. If I am establishing just a normal SDH/SONET LSP then why do I need
> different priority levels ? I think it is only valid if I establish
> SDH/SONET LSP as a forwarding adjacency (FA). Furthermore, the max. LSP
> bandwidth at different priority levels should indicate differnet LOVCs
viz.
> VT1.5...VT6 or VC-2...VC-11.
> 
> I think all the fields viz. LSP encoding type (in Generalized Label Req
> object), swiching capability (in switching type), Encoding (in switching
> type) indicate more or less the similar type of meaning.
> I think the switching type field (in generalized label request object)
> should be kept optional for LSP encoding type as PSC-[1-4], FSC and LSC.
> 
> Please correct me if I am wrong.
> 
> Regards,
> manoj.
> 
> >From: John Drake <jdrake@calient.net>
> >To: Zhi-Wei Lin <zwlin@lucent.com>, manoj juneja
> ><manojkumarjuneja@hotmail.com>
> >CC: ccamp@ops.ietf.org, lberger@movaz.com, Eric.Mannie@ebone.com, Kireeti
> >Kompella <kireeti@juniper.net>
> >Subject: RE: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt
> >Date: Wed, 1 Aug 2001 08:54:56 -0700
> >
> >Zhi,
> >
> >I thought that Vishal had answered this a while ago.  A TE Link can now
> >have
> >multiple switching (nee multiplexing) capabilities.  Given this, it's
> >necessary in signalling to identify which switching capability the LSP
> >wishes to use.
> >
> >Thanks,
> >
> >John
> >
> >-----Original Message-----
> >From: Zhi-Wei Lin [mailto:zwlin@lucent.com]
> >Sent: Tuesday, July 31, 2001 10:14 PM
> >To: manoj juneja
> >Cc: ccamp@ops.ietf.org; lberger@movaz.com; Eric.Mannie@ebone.com;
> >Kireeti Kompella
> >Subject: Re: Doubt in draft
> >draft-ietf-mpls-generalized-signalling-05.txt
> >
> >
> >Hi,
> >
> >I have not heard any response to Manoj's question from the folks who
> >added this field as to what use it is envisioned...
> >
> >Can someone enlighten me? Thanks!
> >
> >Zhi
> >
> >
> >manoj juneja wrote:
> > >
> > > Hi All,
> > >          I have following doubt in
> > > "draft-ietf-mpls-generalized-signalling-05.txt" draft.
> > > This draft has introduced new field switching type in Generalized
> > > Label Request Object. After looking at the structure of switching type
> > > field in latest OSPF document (GMPLS extensions to OSPF, Field Name :
> > > Interface switching capability descriptor), I could not make out why
> > > this is present in per LSP establishment request ? This field
> > > advertises the bandwidth (both min. and max.) for various priority
> > > levels (p = 0 -> 7). Furthermore, this field also contain Encoding
> > > (I assume LSP encoding type) field which is already there in
> > > Generalized Label Reqest object.
> > > I am not able to understand why this type of information is required
> > > in Per Connection Establishment Request ? Is the "switching type"
field
> >only
> > > applicable when FA (forwarding adjacency) need to be established ?
> > >
> > > 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