[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt

To: 'manoj juneja ' <manojkumarjuneja@hotmail.com>, "'xuyg@lucent.com '" <xuyg@lucent.com>
Subject: RE: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt
From: Ayan Banerjee <abanerjee@calient.net>
Date: Wed, 1 Aug 2001 18:41:10 -0700
Cc: "'ccamp@ops.ietf.org '" <ccamp@ops.ietf.org>
Manoj,

I was just giving an example with respect to your query why we need to carry
encoding information along with switching capability. I am sure that there
are other examples where one can concot similar scenarios. 

I am sure that if you have a suggestion as to how to incorporate
multi-service platforms in the GMPLS framework we can look into it. 

Thanks,
Ayan

-----Original Message-----
From: manoj juneja
To: abanerjee@calient.net; xuyg@lucent.com
Cc: ccamp@ops.ietf.org
Sent: 8/1/2001 5:46 PM
Subject: RE: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt

Hi Ayan,
         I think the concept of adding both SDH and SONET links in one
TE 
link is not fine. If we restrict the definition of TE link by saying
that it 
must contain the ports/links of same technology or type. We are trying
to 
add more complexity in signalling protocols by expanding the definition
of 
TE link. U need to take care of both SDH and SONET links only at the 
gateways (SDH and SONET interworking points only). These things can be
done 
easily by restricting the definition of a TE link.

Please correct me if I am wrong.

Regards,
manoj


>From: Ayan Banerjee <abanerjee@calient.net>
>To: 'Yangguang Xu' <xuyg@lucent.com>
>CC: "'ccamp@ops.ietf.org'" <ccamp@ops.ietf.org>, 
>"'manojkumarjuneja@hotmail.com'" <manojkumarjuneja@hotmail.com>
>Subject: RE: Doubt in draft
draft-ietf-mpls-generalized-signalling-05.txt
>Date: Wed, 1 Aug 2001 17:03:48 -0700
>
>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


_________________________________________________________________
Get your FREE download of MSN Explorer at
http://explorer.msn.com/intl.asp
Prev by Date: RE: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt
Next by Date: Re: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt
Prev by thread: RE: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt
Next by thread: Re: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt
Index(es):
- Date
- Thread