[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AW: AW: VC-4-64c as forwarding adjacency
Dieter,
Formally the VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, VC-4-16c/STS-48c,
VC-4-64c/STS-192c and VC-4-256c/STS-768c layer networks are separate layer
networks. And if we do not want any special cases to treat we should administer
and control those layer networks as separate layer networks.
Nevertheless, in todays SDH/SONET networks the network management systems
typically control those layer networks as HOVC/STS "layer" (similarly we have
the LOVC/VT "layer"). The specific layer network has been more or less converted
into a signal type parameter.
ASON is layer network based from the functional perspective. But one of the ASON
components, the "protocol controller" can however have a 1:n relation with other
ASON components. In order to support the HOVC and LOVC "layer" approach, one
protocol controller can interact with e.g. VC-3 CC, VC-4 CC, VC-4-4c CC, etc.
I.e. the signalling messages from that single protocol controller contain VC-3,
VC-4, VC-4-Xc related information elements.
Idem for a "LOVC" protocol controller of course.
Whether or not this merging will be done is a matter of HOVC [and LOVC] UNI,
E-NNI and I-NNI agreements.
Note - Within one vendor's subnetwork, a vendor may make its own
decision (there is no interconnect with other vendors's equipment).
Note - I have proposed to go for HOVC and LOVC "layer" approaches
in a June and a September contribution to Q.12/15. But, this level of
detail didn't fit in the first version of G.8080. It will again be
discussed for the next version or a related ASON recommendation.
ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/wp3/q12/0106/wd20-astn-ln-definition.pdf
http://ties.itu.int/u/tsg15/sg15/wp3/q12/0109/cd/cd-ason-lna01.doc
http://ties.itu.int/u/tsg15/sg15/wp3/q12/0109/cd/cd-ason-abc01.doc
Separate from the interface specification, there is the implementation of
control plane functionality in equipment. ASON specifies a functional
architecture, and it is up to the vendors to implement this functional
architecture. Multiple implementations will exist, some which have merged many
functional components into a single implementation component, others which are
more 1:1 with the functional architecture. But my feeling is that it is kind of
natural to combine VC-3/4/4-Xc functional components into HOVC implementation
components (as long as the functional behaviour is supported). And idem for
LOVC.
Combining multiple layer networks into a single "layer" may introduce an
"interworking" item when there is no complete orthogonality. E.g. the VC-3 is
part of both LOVC and HOVC "layers". A closer look some time ago revealed
however that there is no real issue here... I documented this in
http://ties.itu.int/u/tsg15/sg15/wp3/q12/0109/cd/lovc_hovc_ln01.doc
http://ties.itu.int/u/tsg15/sg15/wp3/q12/0109/cd/lovc_hovc_ln01.pdf (if you do
not have access to ITU-T let me know and I forward file to you)... i.e. if there
is a point in the network where AU3/VC3 signal is continued as TU3/VC3 signal
(within AU4/VC4), you have a HOVC fabric which is connected via a link to a LOVC
fabric. The HOVC fabric sees this link as a HOVC link supporting only VC-3 link
connections, the LOVC fabric sees this link as a LOVC link supporting only VC-3
link connections.
Similarly, the ODU1, ODU2 and ODU3 layer networks are each others peers with
respect to the OCh layer network, but these ODUk layer networks have also
client/server relationships. At the time of writing the June/Sept contributions
I had the feeling that ODU1, ODU2 and ODU3 should be treated as separate layer
networks, and not be combined into an ODUk "layer". At this moment, with the
concept of protocol controller, it can be expected that there is one ODUk
protocol controller supporting ODU1, ODU2 and ODU3 layer network signalling.
With respect to advertising, I have the feeling that there will be no difference
between treating HOVC [LOVC, ODUk] layer networks separate or combined. The same
information will be distributed, and the same operations will be possible. It
seems more a matter of how much of the specific details do we want to show. E.g.
take the HOVC case with its VC-3 link connections, Vc-4 link connections,
VC-4-4c link connections, etc. We can describe this set of link connections by
means of a set of parallel VC-3 link, VC-4 link, VC-4-4c link, etc. (each
containing a single link connection type), or by means of a single HOVC link
(with multiple link connection types). The G.85x.y series uses the former means,
in my correspondence documents in the middle of the year I used the latter means
(
ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/wp3/q12/0106/wd08-cd-astn-ln01.pdf
).
When we use the former and define separate VC-3, VC-4, etc links we have to add
explicit interactions between their Link Resource Managers (LRMs) or yet to
define related components to support the ability to change e.g. a group of 4
VC-4 link connections into a single VC-4-4c link connection. When we use the
latter and define a combined HOVC link with a single LRM, the change of link
structure can be taken care of within the single LRM component. But at the end
we won't notice a difference.
Up to so far... still some work to do :-)
Regards,
Maarten
Dieter Beller wrote:
>
> Maarten,
>
> I fully share your view concerning the contiguous concatenated
> signal. Moreover, I also read your mail regarding the "Lambda
> LSP Forwarding Adjacency Doubt" where you describe the
> layering of the transport plane.
>
> Now, I have the question whether e.g. the HOVC layer in SDH
> or SONET which supports multiple signal types (plain VC-4s,
> VC-4-ncs, etc.) should be considered as strictly separated layers
> at the same level, or whether they should rather be considered
> as a single layer supporting multiple services?
>
> This has of course some implications on routing (e.g. what is
> advertised and which nodes share a Forwarding Adjacency)
>
> Regards,
>
> Dieter
>
> Maarten Vissers wrote:
>
> > 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
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