[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fwd: Re: AW: AW: VC-4-64c as forwarding adjacency

To: ccamp@ops.ietf.org
Subject: Fwd: Re: AW: AW: VC-4-64c as forwarding adjacency
From: "manoj juneja" <manojkumarjuneja@hotmail.com>
Date: Fri, 07 Dec 2001 15:38:41 -0700
Cc: Eric.Mannie@ebone.com, dimitri.papadimitriou@alcatel.be, kireeti@juniper.net, jplang@calient.net, dbasak@accelight.com, braja@tellium.com, jdrake@calient.net
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 <mvissers@lucent.com>
>>To: manoj juneja <manojkumarjuneja@hotmail.com>
>>CC: ccamp@ops.ietf.org
>>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 <mvissers@lucent.com>
>> > >To: "'manoj juneja'" <manojkumarjuneja@hotmail.com>
>> > >CC: ccamp@ops.ietf.org
>> > >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:manojkumarjuneja@hotmail.com]
>> > > > > Gesendet: Mittwoch, 5. Dezember 2001 19:49
>> > > > > An: juergen.heiles@icn.siemens.de; ccamp@ops.ietf.org
>> > > > > 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" <juergen.heiles@icn.siemens.de>
>> > > > > >To: "'manoj juneja'" <manojkumarjuneja@hotmail.com>,
>> > > > > <ccamp@ops.ietf.org>
>> > > > > >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:manojkumarjuneja@hotmail.com]
>> > > > > > > Gesendet: Dienstag, 4. Dezember 2001 23:44
>> > > > > > > An: ccamp@ops.ietf.org
>> > > > > > > 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
Prev by Date: agenda
Next by Date: Optical Equipment Vendors Input Required
Prev by thread: Re: AW: AW: VC-4-64c as forwarding adjacency
Next by thread: RE: [IP-Optical] LMP: Link verification procedure suggestions.
Index(es):
- Date
- Thread