Re: ASTN Layer Network Architecture

[Maarten Vissers <mvissers@lucent.com>]

Tammy,

Thanks for your comments. See below for my thoughts...

Tammy.Ferris@mail.sprint.com wrote:
> 
> Maarten,
> I found your contribution very helpful and I have some
> comments/questions.
> 
> 1) You said Network Engineering does:
> ***
> Monitored are how much of the available links are utilized. After
> reaching a threshold (which could be % utilization & rate of change of
> utilization & possibly also # of failed connection attempts), a request
> to the server LNCP is made for new trails. Network engineering should
> also monitor the bandwidth demand from a source/destination
> relationship, in order to identify the traffic patterns in the network.
> Where necessary, a layer network's architecture can be optimised by
> e.g. adding direct links between two heavily interconnected nodes.
> Decisions are taken based on policies set by the network operator.
> It is also worth being able to calculate the number of current open
> connections and the maximum number of open connections allowed (due to
> limits in either capacity or connection identifiers). To do network
> engineering you need to know something about the average holding time
> of the connection and the call request rate
> ***
> But I currently see these as traffic engineering functions.
> 
> You said Traffic Engineering does:
> ***
> - creates connections in the LNCP interconnecting the layer network
> links via matrix connections in the fabrics
> ****
> But I currently see these as network engineering functions.

It seems we have opposite understandings here. 
"Network engineering" for me relates to engineering the (layer) network,
i.e. making sure all necessary resources are available. Resources that
can be managed by the (automatic) network engineering process are the
links of the layer network.

"Traffic engineering" on the other hand relates to engineering the
traffic flows, i.e. making sure that the network is utilised to the
highest degree possible, to maximize throughput (increases customer
satisfaction) and profit (increases operator satisfaction).

It seems strange for me, to specify the opposite "network engineering
engineers the traffic flows" and "traffic engineering engineers the
network"...

> 
> 2) In figure 3, you show 3 different sized boxes for the different
> connection types contained with in each other.  It is not clear to me
> why the containment relationship and why they are different sizes.  Do
> the sizes reflect the expected ratios for the different types of
> connections?

Agree. The outer blue box (PC) should be shrunk, and not longer include
the other two boxes (SC, SPC). The PC and SC set are complementary now,
and have no overlap. The SPC set is a subset of the SC set, and the SPC
box will thus be smaller than the SC box. No further meaning is tried to
be reflected by the size of the boxes (but we may start a contest,
predict the percentages of the 3 connection types in e.g. 2007 and bury
it under a tree in Turin... :-)  ).

I will adapt the figure accordingly.


> 
> 3) I think the answer to the question in figure 4 is yes.  I would
> expect that as traffic and service requirements change over time,
> network resources will move between the management and control plane
> control.

OK. Consequential question is now if this is a feature that belongs
already to the first phase of ASON, or to a later phase?

> 
> 4) You have identified a pamLockedLinkCapacity.  I would like you to
> consider extending the definition to be pamMaintenanceLinkCapacity so
> that it will include all Links that are disabled as well as locked and
> possibly those under test.

I assumed that pamLockedLinkCapacity would reflect the number of link
connections in the administrative state "locked", and that a link
connection could enter this state for multiple reasons. 

I expected to trigger you here :-) as you introduced this capability
last year (during ODUk-LCK signal definition and application study) to
me. Perhaps you can take the lead here and create a complete
definition...

As far as I can see we have the 
- "administrative state" (7.1.3/X.731) with its states "unlocked",
"shutting down" and "locked"
- "operational state" (7.1.1/X.731) with its states "disabled" and
"enabled" ==> is this operational state implied when you referred to
"link (connection?)s that are disabled"?
- "usage state" (7.1.2/X.731) with its states "idle", "active" and
"busy" ==> isn't this more extensively represented by the four "pamXXX"
parameters in G.853.8? I.e. can we ignore this state?

Is pamMaintenanceLinkCapacity the best term representing all
applications as well as its usage in the traffic engineering process?
The pamMaintenanceLinkCapacity represents the number of link connections
which are currently not accessible by the routing process within traffic
engineering.

We need to define the rules for pamMaintenanceLinkCapacity (or other
term); i.e. when is its value increased, decreased and which other
pamXXX values are then consequentially decreased/increased.

Up to now:
	pamMaximumLinkCapacity =	pamPotentialLinkCapacity +
					pamProvisionedLinkCapacity +
					pamAvailableLinkCapacity

Will pamMaintenanceLinkCapacity be just an extra term in this
expression? E.g. 
	pamMaximumLinkCapacity =	pamPotentialLinkCapacity +
					pamProvisionedLinkCapacity +
					pamAvailableLinkCapacity +
					pamMaintenanceLinkCapacity

If the above will be the case, how would we address the "shutting down"
situation; if there are e.g. 5 link connections in shutting down state,
then they are still ProvisionedLinkCapacity and at the same time also
MaintenanceLinkCapacity... most likely we can ignore this detail and
consider that these e.g. 5 link connections are not longer part of
ProvisionedLinkCapacity.

What contributes to pamMaintenanceLinkCapacity? E.g. number of link
connections in admin states locked and shutting down, number of link
connections in operational state disabled, ... other?

The operational state "disabled" represents the number of link
connections that are "DOWN" (i.e. failed), we do not have to bother with
additional parameters indicting that a particular link has e.g. lost 90%
of its capacity to the a network failure... that sounds nice...



> 
> 5) In the case of the SPC, where there is sharing of provisioning
> between the control plane and the management plane, which one is
> responsible for verification of connectivity and clean-up from failed
> set-up and release operations?  I think somewhere we need to have a
> discussion of this interaction.

The control plane is responsible. The management plane has handed all
info necessary to the control plane; see also as a first example annex
E. Also when the SPC is released, the managmeent plane initiates the
release, but the control plane is responsible for correct release.

> 
> 6) I was thinking that it might be nice to be able to set up a primary
> route in the management plane (e.g. PC) and a protection route in the
> control plane (e.g. SPC).  Currently this seems to present coordination
> problems. Is this something that would be worth further investigation?

I think this is very problematic. Protection requires route diversity,
and if you use two different instances (MP, CP) for the two routes, I
don't see how route diversity can be obtained.


> 
> 7) It seems to me that the UNI brings up the subject of Service
> management which you have not addressed in this contribution.  This is
> not to reflect negatively on the contribution as you have covered quite
> a lot of material with this contribution.  I was just wondering what
> your thoughts were about this going forward.

I haven't arrived at this yet... I have had some discussions with some
of my colleagues on billing principles (use of performance monitoring
information); i.e. use of tandem connection monitoring or of
differential PM (case no TCM is available)...

Can you present some more of your thoughts behind service management...
might be helpful as we move forward to have a first reference that we
can consider at each step.

> 
> Tammy

Regards,

Maarten
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