[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Moving right along ...
Maarten,
In the interests of reconciliation consider the following:
ASON and G-MPLS are both post hoc conceptual models describing the same physical and logical network. The objectives of automation through signalling are broadly similar. Therefore it would be surprising indeed if the solutions were widely different. ASON
is indeed based on the layered model of G.805 and deals with layering issues up-front. GMPLS is derived from the Internet model which regards the physical layer as flat. When real world layering is encountered it is dealt with by refinements many of which
appear in draft-ietf-mpls-lsp-hierarchy-03.txt which is one of the source documents from which G-MPLS inherits. Here LSP regions are defined in 6.2 which are as near as I can tell exactly equivalent to G.805 layer networks. Further, precedence rules
between layers are established with the clear implication that a higher layer cannot be configured until the appropriate resources in the lower layer have been instantiated. The manner in which this may be done is considered a "local matter". The example
given indicates that a Forwarding Adjacency (equivalent to a G.805 link supported by one or more trails (LSPs) in the server layer) may be initiated in various ways including from an external manager or another (adjacent) LSR. Thus the example you gave of
a VC-1x layer being set up by signalling and VC-4 layer being set up by an external planning/management is certainly a valid implementation within the scope of the G-MPLS solution. By the same token it is undesirable (and anyway will not be possible) to
confine signalling to certain layers while reserving others for management through a standard. Operators will want to make such important architectural choices on the basis of optimising their own operation. Once you have agreed on a signalling protocol to
create connections within a layer network it is generically applicable to any layer network. Of course making such an implementation choice (ie management for VC-4, signalling for VC-1x) is an example of the "local policies" mentioned above. Such choices
frequently appear as part of some sort of application specific profile or applications framework on top of the base generic standard. Note this sort of profiling (if that is the correct term) is
generally needed to ensure interworking amongst elements which implement the same generic standard.
On the last occasion that we studied application of signalling for transport networks in ITU (over 10 years ago at the time G.805 was first issued) we had concluded that connection set-up within a layer was the easy part ie there were several well
established candidates to choose from (B-ISUP was the favorite. Neither PNNI nor RSVP existed at that time. ISIS had already been adopted for DCN in SDH and thus provided basic neighbour discovery and xSPF computation if required). The major new problem to
resolve for multi-layer transport networks was indeed considered to be the desired behaviour at inter-layer boundaries. It seems that both initiatives have sidelined this issue as out of scope for the time being.
regards,
Mike Sexton
Maarten Vissers <mvissers@lucent.com> on 25/10/2001 06:03:38
To: Sudheer Dharanikota <sudheer@nayna.com>
cc: ccamp@ops.ietf.org(bcc: Michael J
SEXTON/GB/ALCATEL)
Subject: Re: Moving right along ...
Sudheer,
Another issue is ...
- ASON is layer network based, GMPLS is not
i.e. a request for a connection within ASON is treated within the boundaries of
one layer network (e.g. within the boundaries of a VT1.5/VC-11 layer network, or
within the boundaries of a STS-3c/VC-4 layer network). A VT1.5/VC-11 connection
request is processed within the VT1.5/VC-11 layer network, using existing
VT1.5/VC-11 links (GMPLS: link bundles). If there is not enough capacity in the
VT1.5/VC-11 links to support the request, the call fails. There is no "hidden"
set up of a STS-1 or VC-4 trail supporting an additional VT/LOVC link or
extending an existing VT/LOVC link. The set up of an additional STS-1 or VC-4
trail is supported within the scope of network planning and/or network
engineering. This is separated from the connection set up.
Regards,
Maarten
Sudheer Dharanikota wrote:
>
> Hi Maarten:
>
> Maarten Vissers wrote:
>
> > Sudheer,
> >
> > At the moment I am unable to briefly summarize the differences between GMPLS and
> > ASON. I was working from the perception that GMPLS could be one of the protocols
> > supporting ASON. The technical comments I made during the last 10 months were
> > based on this perception. Also the last comment describing the concept of serial
> > compound link had this basis. Reading Yanhe's reply I had the impression that
> > GMPLS is able to support serial compound links, but reading Eric's reply I got
> > the opposite impression. Furthermore being very surprised by Eric's reaction on
> > a pure technical issue, I composed a few challenging words to attrack more
> > people to participate in the discussion... :-)
>
> I see one of the issue here being ...
>
> - Does GMPLS support serial compound links?
>
> Let us enumerate few more questions and move the discussion to a technical
> level again, we need participation especially from the folks who are involved
> in ASON architecture work.
>
> >
> > Being impressed by the few hundred people attending the last ccamp sessions in
> > London, I am surprised by the low percentage of those people being actively
> > contributing to the correspondence. It can't be the case that only a handful of
> > people have an opinion on these matters... and I believe the discussions would
> > stay technical if more people express their opinion... there would not be a
> > yes/no game between just a few people.
> >
>
> I thought this is how most of the standards meetings work. 5 % work, 95 %
> try to gather industry intelligence ( :-) ) either by attending IETF or by following
>
> the mailing list.
>
> >
> > With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available it will be possible to
> > start an evaluation of GMPLS as a specific protocol for ASON. As indicated in a
> > previous email from Steve Trowbridge, ITU-T will make those ASON documents
> > available to IETF so we can jointly work this evaluation.
> >
>
> Most of these documents are available on the t1x1 site. But what we need here is
> the "delta" that is missing between ASON architecture and the view of GMPLS
> architecture. Can you help us with this? We may start with a short list...
>
> >
> > The approval of the current ASON recommendations is just a first step within the
> > larger ASON task. Work is started on other elements of ASON (G.rtg (routing),
> > G.lm (link management) and pnni based specific protocol as an implementation of
> > the protocol neutral specification in G.7713)), discussions are started
> > identifying further ASON elements, and work to extend G.8080 is planned to start
> > after this SG15 meeting.
> >
>
> Obviously GMPLS is a potential candidate to solve the ASON issues. It may be
> ahead of its time as far as ITU and ANSI are concerned. So let us ammend or
> modify it to the ITU view on the transport control plane.
>
> Regards,
>
> sudheer
>
> >
> > Up to so far... {time to shut down my computer and go to the concert hall in
> > Geneva... time to relax after a week and a half of hectic work over here...}
> >
> > Regards,
> >
> > Maarten
> >
> > Sudheer Dharanikota wrote:
> > >
> > > Hi Marteen:
> > >
> > > Can you briefly summarize the differences you see between
> > > GMPLS architecture and ASON architecture? This has been
> > > asked by many of the folks at IETF.
> > >
> > > Regards,
> > >
> > > sudheer
> > >
> > > PS: I thought these mails were about label format and suddenly
> > > this is turning into an ITU versus IETF discussion :-(
mvissers.vcf