[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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