[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AW: AW: VC-4-64c as forwarding adjacency
Manoj,
manoj juneja wrote:
>
> 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 ?
ATM control plane uses PNNI to support ATM VP and ATM VC connection management.
But if you consider GMPLS applicable also at these layers, then there will be an
ATM specific part in GMPLS, which defined VP labels (i.e. based on VPI) and VC
labels (i.e. based on VCI). Also, AAL2 layer network (supporting voice) would
have AAL2 labels.
ATM VP connection controllers in nodes A and D would then have a relationship
and pass ATM VP signalling messages.
Besides ATM (with its PNNI/Q.2931 protocol), we will see ethernet with/without
VLANs to become part of the transport plane. Ethernet PHYs are more and more
deployed to connect to the transport plane, and as a result the transport
equipment is extended with 10M, 100M, 1G and 10G ethernet interfaces. The
ethernet PHY is terminated immediately after the connector and the ethernet
frames are buffered and then forwarded via virtual concatenated VC-n-Xv signals.
The associated VC-n-Xv trails support Ethernet links. These ethernet links have
trib slots as well, and labels will therefore be present... e.g. with VLAN the
VLAN identifier would be the basis for the label. These labels would be
exchanged between two adjacent ethernet switches at the end of an ethernet link.
And of course not to forget, MPLS is expected to enter the transport network to
support the ethernet transmission over the backbone networks... VLAN id range is
to restricted and the industry is looking at MPLS to perform the VLAN job in the
backbone. In this case there will be a MPLS link supported by VC-n(-Xv), VC-n-Xc
and ODUk(-Xv) trails. In this case MPLS switches in nodes A and D will exchange
MPLS labels.
>
> If I am misinterpreting the concept of LSP hierarchies, please let me know
> that too.
GMPLS as connection management tool for SDH/SONET, OTN and pre-OTN needs to
recognise the layer network structure that is defined by these technologies. The
LSP hierarchy terminology is not aligned with the layer networks in these
technologies. The actual hierarchy in the SDH/SONET/(pre-)OTN transport plane is
LOVC (VC-11,VC-12,VC-2,VC-3)
HOVC (VC-3,VC-4,VC-4-4c,VC-4-16c,VC-4-64c, VC-4-256c)
[STM-N (STM-16, STM-64, STM-256)] ==> pre-OTN case
ODU1
ODU2
ODU3
OCh
ATM VP, Ethernet, MPLS, IP are clients of LOVC, HOVC, ODU1, ODU2, ODU3 layers.
Regards,
Maarten
>
> 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
begin:vcard
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:mvissers@lucent.com
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard