Subject: Re: [Pce] Pce Digest, Vol 100, Issue 5

From: Quintin Zhao <[email-masked]>
Date: Thu, 17 Jan 2013 21:42:43 -0500

Adrian,

Thanks and I will be glad to join you and Dan to work on this.

Quintin

----------------------------------------------------------------------------
------------------------
Message: 1
Date: Thu, 17 Jan 2013 16:46:29 -0000
From: "Adrian Farrel" <[email-masked]>
To: "'Quintin Zhao'" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Pce] A new draft on an architecture for
	application-based	network operations
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

Hi Quintin,
 
Thanks for this text. Looks good. Dan and I will work to fold it into the
document. 
 
It is quite a substantial piece of text. Do you mind if we name you as a
Contributing Author?
 
Wrt a scenario for GCO and VNT, that also sounds interesting. Slightly
worried
that it may get a bit complicated, but if you are capable of documenting it,
I
think it would be a fine addition to the document.
 
Thanks,
Adrian
 
From: Quintin Zhao [mailto:[email-masked]] 
Sent: 16 January 2013 23:06
To: [email-masked]; 'Daniel King'
Cc: [email-masked]
Subject: Re: [Pce] A new draft on an architecture for application-based
network
operations
 
Dear Dan and Adrian, 
 
As we discussed I focused on providing text for GCO. The text and diagrams
may
not be formatted correctly so I also attach text file. If it would be good,
I
will create some more text for a GCO and VNT scenario. 
 
3.5 Global Concurrent Optimization
 
Global Concurrent Optimization (GCO) is defined in [RFC5557] and represents
a
key technology for maximizing network efficiency by computing a set of
traffic
engineered paths concurrently. A GCO path computation request will
simultaneously consider the entire topology of the network, and existing
LSPs,
when computing new services (TE LSPs) or an existing set of services.

A GCO may be requested in a number of scenarios, these include:
 
o Routing of new services where the PCE should consider existing    
  services or network topology.  
 
o A reoptimization of existing services due to fragmented network
  resources or sub-optimized placement of sequential computed services. 
 
o Recovery of connectivity for bulk services in the event of a
  large network failure. 
 
[RFC5557] states that a GCO is primarily an NMS or a PCE-Server-based
solution,
due to nature of GCO path computation requests and the need for network and
service synchronization. Therefore the ABNO architecture represents a
suitable
framework for implementing GCO capable path 
computation functionality.   
 
It may be possible that a service provider would want to compute and deploy
new
services based on predicted traffic matrix. The GCO functionality and
capability
to perform concurrent computation, provides a significant network
optimization
advantage to avoid blocking and utilize network resources optimally. 
 
The following use case shows how the ABNO architecture and components are
used
to deploy GCO-enabled services. Furthermore, this use case also includes a
capability to consider multi-layer network (MLN) concurrency, in order to
optimize network efficiency or meet client network connectivity or bandwidth
requirements. 
 
3.5.1 GCO with MLN Use Case
 
The following IP over optical network represents a typical Client and Server
network:

         +-----+
         | NMS |
         |     |
         +--+--+
            |
         +--+---------------------------------------+
         |                  ABNO                    |
         |                                          |
         +---------------------------------------+-++
                                                 | |
                                                 | |
         +---------------------------------------+--+
        /        IP/MPLS (Client) Network Layer      \
       +----------------------------------------------+
                                                   |
      +--------------------------------------------+---+
     /           Optical (Server) Network Layer         \
    +----------------------------------------------------+
 
                 Figure x: Network Architecture
 
The above network uses an IP/MPLS network layer which is Packet Switching
Capable (PSC). The optical layer is Lambda Switching Capable (LSC). The IP
packets are aggregated into lambda optical channels using TE LSP tunnels.
The lambda optical channels using within the optical network layer may be
fixed
or convertible.
 
When considering the GCO path computation problem, we can split the
requirements
into two categories of concurrency optimization objectives, these are:
 
o Minimize aggregate Bandwidth Consumption (MBC).
 
o Minimize the load of the Most Loaded Link (MLL).
 
o Minimize Cumulative Cost of a set of paths (MCC).
 
The use case assumes the GCO request will be offline and be initiated from
an
NMS, that is it will take significant time to compute the service and the
paths
reported as part of the request response may want to be verified by the user
before being provisioned within the relevant network layer. 
 
1. Request Management
 
The NMS issues a request for new service connectivity for bulk services. 
The ABNO Controller verifies that the Application Service Coordinator has
sufficient rights to make the service request and apply a GCO attribute.
 
Each service request has a source and destination location, bandwidth
request
and a fixed starting time and duration. The bandwidth request could vary
from a
few Mbps to the maximum capacity of a lambda optical channel.
Various algorithms and computation techniques may be applied to compute the
services on a specific set of network planning constraints, 
but are not described in this procedure.   
 
2. Service Path Computation in the Packet Layer 
 
The ABNO Controller sends a GCO-enabled path computation request to the
packet
layer PCE to compute a suitable path for the requested services. 
Upon receipt of the service requests the packet PCE then computes the
requested
paths concurrently applying relevant concurrent capable algorithms. 
 
The PCE uses the appropriate policy for the request and consults the TED for
the
packet network layer. If required, the PCE may compute two bulk service
requests
based on the requested objective (MBC, MLL or MCC). To compute a set of
services
for the GCO application, PCEP supports synchronization VECtor (SVEC) lists
for
synchronized dependent path computations requests as defined in [RFC5440]
and
described in [RFC6007]. 
 
Once the requested GCO service path computation completes, the PCE sends the
resulting paths back to the ABNO Controller. The response includes a fully
computed explicit path for each service (TE LSP) that needs to be
established.
The ABNO Controller will forward the candidate paths back to the NMS for
user
approval before being provisioned within the relevant network layer. 
 
3. Coordination of MLN resources using VNTM and Path Computation in the
Optical
Layer
 
The ABNO architecture supports both immediate connectivity requirements and
advanced scheduling (reservation) of resources. Given a service request that
exceeds the current capability of the current packet layer the PCE may
invoke
the VNTM for the creation of necessary links in the virtual network topology
to
meet the requirements of immediate or scheduled resources. This interaction
is
documented in Figure 11 ( Invocation of VNTM and Optical Layer Path
Computation). 
 
Triggers for VNT reconfiguration, such as traffic demand changes, network
failures, and topological configuration changes may require a set of
existing TE
LSPs to be re-computed, or new virtual TE links to be added to the VNT. 
 
4. Provisioning in the Optical Layer
 
These may be immediate or scheduled optical resources (lambdas) dependent on
if
the initial service requests are immediate or scheduled. 
 
5. Reoptimization of Existing Services (Defragmentation of Network)
 
If it is not possible to provision new resources to meet the bulk service
request then it may be possible via traffic grooming of existing LSPs
(either
packet or optical) to optimize the capacity utilization of the network
layer. 
 
   1. The packet or optical PCE will compute the new service 
   request and provide a response to the ABNO Controller with the order 
   in which existing TE LSPs should be reoptimized so as to minimize 
   traffic disruption. 
 
   2. The PCE will compute the make-before-break replacement service. 
   The PCE will also need to indicate for each request the order in which 
   the old TE LSP should be removed and the order in which the new TE LSP 
   should be setup.  
   
   If the removal order is lower than the setup order, then the 
   make-before-break may not be performed for the request.
 
   3. Once the initial defragmentation of the network resources has been 
   performed then the new bulk request for services can be performed.
 
Thanks Quintin!  

*	To: "'Daniel King'" <daniel at olddog.co.uk
<mailto:[email-masked]> >, "'Quintin Zhao'" <quintin.zhao at
huawei.com
<mailto:[email-masked]> > 
*	Subject: Re: [Pce] A new draft on an architecture for
application-based
network operations 
*	From: "Adrian Farrel" <adrian at olddog.co.uk
<mailto:[email-masked]> > 
*	Date: Fri, 7 Dec 2012 15:13:08 -0000 
*	Cc: pce at ietf.org <mailto:[email-masked]>  
*	Delivered-to: pce at ietfa.amsl.com <mailto:[email-masked]>  
*	In-reply-to: <008601cdd48a$674f7b90$35ee72b0$ at olddog.co.uk
<mailto:[email-masked]> > 
*	List-archive: <http://www.ietf.org/mail-archive/web/pce> 
*	List-help: <mailto:[email-masked]?subject=help> 
*	List-id: Path Computation Element <pce.ietf.org> 
*	List-post: <mailto:[email-masked]> 
*	List-subscribe: <https://www.ietf.org/mailman/listinfo/pce>,
<mailto:[email-masked]?subject=subscribe> 
*	List-unsubscribe: <https://www.ietf.org/mailman/options/pce>,
<mailto:[email-masked]?subject=unsubscribe> 
*	References: <50c0f8a1.2218b40a.2c1e.48c1SMTPIN_ADDED_BROKEN at
mx.google.com
<mailto:[email-masked]> >
<008601cdd48a$674f7b90$35ee72b0$ at olddog.co.uk
<mailto:[email-masked]> > 
*	Reply-to: adrian at olddog.co.uk <mailto:[email-masked]>  
*	Thread-index: AQFrZjbRxLc5+InYH8ThqvcxIMjyVAEBEe1kmMpCNpA= 
  _____  

Hi Quintin,
 
Following up with some more detail on top of Dan's email.
 
>> The draft is very good and is helpful coordinate PCE and TE technologies
>> between applications and network. I focused on some sections and have
>> following questions and suggestions. 
 
Thanks for reading and commenting.
Answers in line.
 
>> (1) Applicability of ABNO Architecture. 
>> Your document abstract and introduction discusses scenarios including
>> content and data-center interconnection ("Services such as content
>> distribution, distributed databases, or inter-data center connectivity
>> place a set of new requirements on the operation of networks."). I
>> think the architecture is also relevant to lots of other environments:
>> mobile backhaul, core transport, packet switch network, etc. Do you
>> agree? 
> 
> DK>> Yes, that?s true. We did focus on the data center applicability as
> we presented some slides at MPLS Washington 2012 which discussed
> that specific scenario and the draft followed some of the same language.
 
I agree. We were trying to describe some service environments rather than
network environments, and we certainly don't want to imply any limitations
on
the uses or the network environments. We expect that the architecture could
be
used in a whole range of applications: both at the static end of the
spectrum
(such as mobile backhaul), and for more dynamic services.
 
We will highlight this point in the next revision.
 
>> (2) ABNO Controller.
>> Section 2.2.13 (ABNO controller) needs to be discussed in more detail.
>> Do you think multiple ABNO controllers or just one ABNO controller
>> will be required? Maybe an implementation will use a ABNO Controller
>> per "application" (Service Coordinator/NMS/OSS)? 
> 
> DK>> When we were white boarding and discussing the architecture we
> certainly considered that a number of the ABNO components would require
> multiple instances per deployment, including the ABNO Controller. As per
> your next point we will try to be more specific in the ABNO text. 
> 
>> (3) PCE or PCE's?
>> Figure 1 shows *a* PCE. It is expected that multiple PCE' would be used,
>> this is important for VNTM Use Case. Maybe you can show more PCE's
>> in the figure 1 or describe it?
> 
> DK>> As Above, yes.
 
As Dan says, there can certainly be multiple instances of the functional
components in the figure. This could arise within an implementation to
load-share, provide specialist capabilities (as you suggest for the ABNO
Controller), to maintain confidentiality or separation of function (as you
suggest for PCE), or to distribute the function across platforms. We are
keen to
stress that this is a functional architecture, not an implementation
road-map. I
think we will add a section on "Implementation of the Architecture" to
discuss
these points.
 
>> (4) Network Resiliency.
>> I am interested in ABNO managing network failures that may be 
>> protected with shared mesh protection at the network which could
>> be MPLS TP or WDM. ABNO would provide a shared path protection
>> which optimizes as network conditions change. This is based on
>> client layer requirements of reliability and protection restoration
>> time. To make this possible the shared mesh protection paths would
>> need to be client layer traffic aware and have customer SLA
>> information. Do you think this is a good use case?
> 
> DK>> Cool. I think this could represent quite a complex multi-layer
> optimization problem. Please let Adrian and me have more
> information on the scenario. Ideally documenting the various
> component functions (specific for the use case) and each
> component interaction, again with some detail on what information
> needs provided and perhaps propose protocol mechanism or
> extensions. Think of the draft as a tool kit. We would like to reuse
> existing technology as much as possible. The use case should reflect
> this. 
 
Yes, this sounds like an interesting use case. Shared mesh protection (and
also
1:n protection) can be a complex provisioning problem, and changes in
services
as well as changes in network availability can require significant dynamic
reassessment of the placement of LSPs. If you would like to suggest text for
a
use case, I think we would be happy to see it.
 
>> (5) Custom (Abstracted) Topologies.       
>> Could ABNO provide abstracted topologies via the north-bound
>> interface to the requester (provisioning tool)? In China we have
>> the customers who would like IPv6 deployment in IPv4 backbone.
>> If provider can assign specific nodes and links to be used for
>> logically isolated IPv6 plane, then the ABNO (I2RS and BGP-LS)
>> architecture could be used to provide abstracted topology based
>> on the preferred equipment for carrying tunneled IPv6 traffic. Is
>> this another use case that may be useful?
> 
> DK>>Maybe we can focus on the SMP use case first. This use case
> might benefit from some of the discussion Young raised yesterday,
> in terms of the virtual topology presentation.  
 
Actually, I think the model already supports exporting information from the
TED
as described in Section 2.2.2.4. This section does not clearly explain that
the
TED could be "abstracted", but it should! We will add some text.
 
>> (6) Manageability and Security.  
>> Are you going to provide Manageability and Security sections in
>> future versions of the ABNO document or another document? 
>> It is an important area for ABNO that needs further discussion. 
> 
> DK>> We will most definitely include some discussion in the ABNO 
> framework, along with policy. 
 
Agreed. (Unless someone else writes the text first :-)
 
Thanks,
Adrian

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.ietf.org/mail-archive/web/pce/attachments/20130117/044815a5/atta
chment.htm>

------------------------------

_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce

End of Pce Digest, Vol 100, Issue 5
***********************************