[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ASTN Layer Network Architecture
Hi Tammy, Maarten,
I have fundamental questions about some of the capabilities you've
discussed. For example, you mentioned that a connection should be able
to move from control plane to management plane.
What would trigger such a move?
And in the case that such move is possible, and assuming a connection is
initially set up as a switched connection (SC), then move to the
management plane, who would be responsible for tearing it down,
monitoring it, modifying it, protecting it?
Also, if a connection can move into the management plane, do we then
need to define all these maintenance capabilities for the control plane?
Maybe a subset but not the entire list?
How likely is it for a network to have control plane but no management
plane?
Would these capabilities considered as part of a link management agent?
Thanks!
Zhi
Tammy.Ferris@mail.sprint.com wrote:
>
> Maarten,
> See my replies to your comments below.
> Tammy
>
> -----Original Message-----
> From: mvissers [mailto:mvissers@lucent.com]
> Sent: Tuesday, May 15, 2001 09:54
> To: Tammy.Ferris
> Cc: tsg13q10; tsg15q12; tsg15q14; ccamp; t1x15; mvissers
> Subject: Re: ASTN Layer Network Architecture
>
> > 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"...
>
> ***TLF reply
> I agree with the comments you just made here. I currently don't see
> that the text in your CD reflects what you have just said. I think it
> is a traffic engineering function to know average hold times and
> connection request rates, do traffic estimates, and then monitor actual
> traffic. Traffic engineering collects capacity and usage data and
> improves upon previous traffic estimates and requests for capacity in
> the next round...
> *****
> 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... :-) ).
> ***TLF reply
> I will bring my estimates to Turin :)...
> *****
> >
> > 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?
> ***TLF reply
> I think this is a core capability and belongs to the first 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.
>
> Perhaps you can take the lead here and create a complete
> definition...
> ***TLF reply
> I will see if I have time to put together a contribution on this for
> Turin.
> *****
> 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"?
> ***TLF reply
> yes
> *****
> - "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?
>
> ***TLF reply
> We can ignore the usage state in terms of maintenance capacity. Other
> attributes to consider relating to maintenance capacity are
> "availability status" and "control status" (for consideration of
> degraded resources and resources under test). And if we want to strech
> it even further there is another attribute that can be used to indicate
> that we don't know the status of the resource (e.g. cannot communicate
> to resource so currently state is unknown).
> *****
>
> 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.
> ***TLF reply
> In some of my past experiences this has been useful for planning and
> monitoring purposes to know how much of the network is typically
> undergoing maintenance and what the fluctuation patterns are relating
> to maintenance activity, etc. Further, it is useful for traffic
> engineering and network engineering purpose to know how much planned
> capacity is expected to be under maintenance during normal operations.
>
> It would be important for routing engines to know that certain
> resources were not available for maintenance but don't really need to
> know what type of maintenance is being done (e.g. new installation,
> repair, waiting for circuit to be torn down, reconfiguration, etc.).
> *****
>
> 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
> ***TLF reply
> I am not sure about this. Isn't pamAvailableLinkCapacity +
> pamMaintenanceLinkCapacity = pamProvisionedLinkCapacity? Or maybe
> pamAvailableLinkCapacity + pamMaintenanceLinkCapacity + ?? =
> pamProvisionedLinkCapacity?
>
> It seems to me like pamAvailableLinkCapacity represents both usage and
> capacity information (which is a bit confusing to me). Are you
> intending to use pamAvailableLinkCapacity to represent the total
> dynamic capacity available to the control plane or the capacity in the
> control plane that has not yet be assigned to connections under the
> control of the control plane? It looked, from your definition that you
> may have meant the later, but then where are you factoring in the
> former in this equation?
> *****
>
> 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.
> ***TLF reply
> I think that the transition from unlocked to shutting down does not
> change the capacity category for the resource. I think the transition
> from shutting down to locked is the trigger to put into maintenance
> capacity.
> *****
>
> 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?
> ***TLF reply
> Admin state, operational state,... + other considerations include
> (non-preemptible?) test connections?, degraded connections?
> connections in unknown state??
> *****
>
> 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...
> ***TLF reply
> Maarten, I am not sure what you mean by this last comment.
> *****
>
> >
> > 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.
> ***TLF reply
> Okay.
> *****
>
> >
> > 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.
> ***TLF reply
> Consider the following hypotheticals: there exists a management plane
> instance that is not capable or calculating a diverse route and there
> is a control plane instance that is not capable of pre-provisioning (by
> this I mean creating a connection in the database for the transmission
> plane even if the transmission resources do not yet exist that will
> become operational once resources become available to support the
> connection). This management plane and control plane need to interface
> to one another.
>
> Now, given the above, assume that the management plane has provided a
> pc for a given user and with no protection route because at the time
> the user did not want one. Then subsequently, the user asks for the
> addition of a diverse route protection for the existing connection. It
> would seem natural that one would want to make use of the intelligence
> of the control plane in determining diverse routes.
>
> Or, maybe another scenario... The user has requested a connection that
> requires network build-out to support. To reserve the resource, the
> connection is pre-provisioned in the management plane (note cannot be
> done in the control plane in this scenario as the control plane does
> not support pre-provisioning according to initial assumptions). This
> connection is to be protected by an m:n protection group where the
> protection connections have been configured using the control plane.
> *****
>
> >
> > 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.
> ***TLF reply
> There are a lot of facets to this which I cannot adequately cover here,
> but for now.... here are some random thoughts to trigger much more work
> later.
>
> Some service management functions include:
> Credit Checks
> Service Order Entry
> Service Order Tracking
> Customer Trouble Tickets
> Assignment of service to network resources (crosses multiple layers)
> Reservation systems
> Interace to Billing functions (e.g. billing profile assignment)
> Interface to Network Management functions (e.g. Network fault
> correlation to affect on service, inventory/service discovery( ;) ?)
>
> This is to name a few... where does the UNI fit into all of this?
>
> *****
>
> >
> > Tammy
>
> Regards,
>
> Maarten