[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Moving right along ...
Zhi,
I am a little reticent to deepen this discussion on the list. It is difficult to avoid appearing like prevaricating philosophers. I can almost hear those CCAMP guys yawning from here. Please feel free to press delete if this is not for you. See discussion
in line.
regards,
Mike Sexton
Zhi-Wei Lin <zwlin@lucent.com> on 25/10/2001 12:04:19
To: Michael J SEXTON/GB/ALCATEL@ALCATEL
cc: Maarten Vissers <mvissers@lucent.com>, Sudheer
Dharanikota <sudheer@nayna.com>, ccamp@ops.ietf.org
Subject: Re: Moving right along ...
Hi Mike,
I agree with most of what you said. I think the forwarding adjacency is
more similar to the serial composed link connections (or serial
compound links) than to support from a trail. There is no requirement
for forwarding adjacencies to relate to trails (at least I don't think so).
MS: Not exactly so but I'd rather pass this one up for now as it may get us in even deeper.
And yes, I fully agree that the inter-layer piece is the interesting
piece. I believe Maarten has presented this in several places as the
network engineering function (what you called the "local matter") as
subject to policy control (very operator business model dependent).
MS: I did not follow this thread very closely but my understanding was that Maarten was essentially dividing what IETF call traffic engineering into two sub-domains: network engineering choosing optimum paths within a layer (LSP region) and traffic
engineering - assigning traffic selectively to one or more alternative paths available at the point the traffic is applied. At a layer boundary this implies some sort of daemon capable of making assignment decisions which may in turn be dependent on
policies implemented locally or impressed remotely. Is this in line with your interpretation.
As for the hierarchy and the layer model, I think the hierarchical model
of MPLS is more atuned to the sub-network partition (and sub-network
recursion) which is within a layer. I'm not sure that the hierarchy was
defined for layer network (although I don't see why it can't apply either).
MS: In G.805 the layer network hierarchical relationship is n:n, client:server (ie a network layer can be served by one or more servers and may in turn support one or more clients. This implies a precedence: client connections can only be provided in the
context of a server (logical) topology. The server topology is generated by the connections created between the edges of the server and so on ad infinitum. This is exactly the recursive relationship described rather more tersely in
draft-ietf-mpls-lsp-hierarchy-03.txt para 6.2. The partitioning relationship between partitioning "levels" (we normally try and avoid overusing the term layer in this context) is 1:n, superior:subordinate. The most superior subnetwork includes (contains) 1
to n subnetworks; each of these in turn includes 1 to n subnetworks and so on recursively until the subordinate subnetwork coincides exactly with a single node (matrix, forwarding engine etc) at which point the recursion efrfectively terminates. In both
GMPLS and G.805 partitioning is considered essentially an administrative activity and local policies are again cited. In practice there are externally imposed limits imposed on administrative choice (eg it is difficult to justify creating a subnetwork
which ignores the self selected boundaries imposed by protected subnetworks (eg rings)). Similarly routing domain boundaries must be honoured.
Having clarified that (I hope) it must be noted that subnetworks at any level map onto 1 or more server "layer networks". For example a subnetwork partition of an MPLS layer (eg PSC3) may be partially supported over VC-4/PoS (TSC) and partially over WDM
(LSC). These are indeed subnetworks in VC-4 and WDM layers respectively and may be offering transit services for other adjacent subnetworks in the same layers. However of particular interest here is that they are also layer network segments containing all
the points at which interlayer services are offered to this particular client. These are all the points where multiplexing choices are made, traffic is offered (or rejected) in short all the issues currently in the realm of local policy with no standard
support for bringing this under control. This was the main point I was making. There is nothing about the layered model which proscribes interlayer control interfaces and connection control planes in multiple layers which was a possible inference from
Maarten's note. I am not sure precisely whether ASON has limited its scope in this manner but if so I suppose this can be seen in the context of prioritising and phasing results as G-MPLS has also limited scope rather than an interdictory prosciption.
For completeness I should add one further comment. Although the ID referred to above and G-MPLS in general leaves the interlayer issue open as covered by "local implementation" there is a strong suggestion of a default behaviour in which a new server
FA-LSP is opened (request to the server) if there are no further link resources available for the recommended next hop and that further more this LSP is routed along the shortest path indicated by the IGP which is subsequently used until it in turn
exhausts. This exploits the unique property of shortest path trees in distributed route computation which also works across layer boundaries.
Now in terms of the layer model itself, I think (as I said many times)
that the problem is mainly in how people interpret the text in these
documents. That is why (my little rambling again) I think we need to add
text to clarify some of these concepts...people don't seem to want to
add clarifying text though...sigh...
Zhi
mike.sexton@alcatel.co.uk wrote:
>
> 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 :-(
>>>>
>>>> Part 1.1
>>>>
>>>> Content-Type:
>>>>
>>>> text/plain
>>>>
>>>>
>>>>
------------------------------------------------------------------------
>>>>
>>>> mvissers.vcf
>>>>
>>>> Content-Type:
>>>>
>>>> application/octet-stream Content-Encoding:
>>>>
>>>> base64
>>>>
>>>>