Hi Lucy,
> The draft layouts the basic PCE architecture
and expresses the motivation
> for a PCE-based architecture. It is a good document.
> for a PCE-based architecture. It is a good document.
Thanks.
> Beyond these motivation facts, I think we should have another incentive for
> a PCE-based architecture.
>
> Today, a control plane based switching architecture assumes a user-network
> model or client-server model. A LSP is initiated at an end user point
> (client), then network establishes the LSP thru. the control plane
> instantly. PCE reserves that concept too. Thus all connection paths are
> based on instant requests from end users.
I think it is true that PCE supports this model,
but I don't think it is the case that the assumptions you state are
universal.
1. The user-network model and the client-server
model are examples of how one might use a control plane-based switching network,
but they are not the only examples.
2. To say that all connection paths are based on
instant requests from end users slightly misses the point of PCE. PCE performs
computations based on requests from an external entity (the PCC), and PCE
operates on a TED. There is nothing that says that the TED must be a
representation of the network at only one instant of time, and there is nothing
that says that the computation request must demand a computation
"now".
> In carrier reality world, it is hard to see that transport service will be
> offered this way only, especially for a large bandwidth and permanent
> bandwidth request.
Hmmm. This may be why I disagreed with your
assumptions! :-)
> Typically, carrier has a service order
reservation
> system, it allows customer to book a bandwidth ahead (pending order),
> carrier will do traffic engineering based on the pending order and will
> excuse the order when the time arrives.
> system, it allows customer to book a bandwidth ahead (pending order),
> carrier will do traffic engineering based on the pending order and will
> excuse the order when the time arrives.
Yes, this is another valid model. But it is also
not the only valid model and many transport networks are operated today on a
much more flexible approach.
> A path computer engine has a
> capability of taking a consideration about future pending orders while it
> computes a path.
> capability of taking a consideration about future pending orders while it
> computes a path.
I am unsure whether what you say matches reality
perfectly.
That is, when a pending future order is entered
into the system, the reservation is made. This means that the TED reflects the
results of the order/computation/fulfilment cycle, and that computations are
still prefomred on demand (i.e. "now"). The difference is that the provisioning
(fulfilment) is some time in the future.
In this case, it seems unlikely that you would feed
your TED from the routing protocols, but rather from inventory discovery and
from the service ordering/fulfilment process. Figure 5 in the architecture shows
this model.
> The architecture is pretty close to the
PCE-based
> architecture except a lot of manual operation. I think PCE should consider
> this as its application too and revise the basic architecture to include
> this functionality.
> architecture except a lot of manual operation. I think PCE should consider
> this as its application too and revise the basic architecture to include
> this functionality.
There is nothing (IMHO) in the current architecture
that prohibits either the management plane use of PCE, or the inclusion of a
time dimension in the TED and the computaiton requests.
> Here is the recommendation for the PCE-based
architecture:
>
> ---------------
> | --------- | Routing ----------
> | | | | Protocol | |
> | | TED |<-+----------+-> |
> | | | | | |
> | --------- | | |
> | | | | |
> | | Input | | |
> | v | | |
> ---------- Response | --------- | | |
> | |Request | | | | | Adjacent |
> | SORD |<------->| | PCE | | | Node |
> | |Input | | | | | |
> ---------- | --------- | | |
> ^ | ^ | | |
> | | |Request | | |
> | | |Response| | |
> Service Order | v | | |
> | --------- | | |
> Service | | | | Signaling| |
> Request | |Signaling| | Protocol | |
> ------+->| Engine |<-+----------+-> |
> | | | | | |
> | --------- | ----------
> ---------------
>
>
> ---------------
> | --------- | Routing ----------
> | | | | Protocol | |
> | | TED |<-+----------+-> |
> | | | | | |
> | --------- | | |
> | | | | |
> | | Input | | |
> | v | | |
> ---------- Response | --------- | | |
> | |Request | | | | | Adjacent |
> | SORD |<------->| | PCE | | | Node |
> | |Input | | | | | |
> ---------- | --------- | | |
> ^ | ^ | | |
> | | |Request | | |
> | | |Response| | |
> Service Order | v | | |
> | --------- | | |
> Service | | | | Signaling| |
> Request | |Signaling| | Protocol | |
> ------+->| Engine |<-+----------+-> |
> | | | | | |
> | --------- | ----------
> ---------------
>
> Here, SORD is the service order reservation
database, it contains all
> service order requests in terms of ingress and egress points, bandwidth,
> service type, time period for the request, etc. When PCE computes a path, it
> could get input from SORD to indicate if there are some network resource is
> already blocked out. When a booking order in SORD is ready to kick off, SORD
> will send request to PCE for the path computation, then PCE will send a
> service request to signaling engine to establish the LSP.
> service order requests in terms of ingress and egress points, bandwidth,
> service type, time period for the request, etc. When PCE computes a path, it
> could get input from SORD to indicate if there are some network resource is
> already blocked out. When a booking order in SORD is ready to kick off, SORD
> will send request to PCE for the path computation, then PCE will send a
> service request to signaling engine to establish the LSP.
This would be hugely inefficient, wouldn't
it?
Since PCE cannot guess which resources might be
blocked out for future requests, it would have to make this query for every
computation. Further, if PCE only made the query for resources that satisfied
the computation, it might have to make repeated recomputations, so it would be
more efficient for it to retrieve information about every future blocking.
So, in fact, it makes more sense for SORD to feed
the information into the TED and allow PCE to operate on the full
database.
But consider: How does SORD know which resources
will be reserved and when? Presumably, it has consulted PCE as
well.
> It is clarified that not all pending orders in SORD need to reserve
the
> bandwidth ahead, carrier could have some policies in SORD to manage which
> order need to reserve the bandwidth ahead and which is not.
>
> Be glad to hear your and other people comment on this suggestion.
> bandwidth ahead, carrier could have some policies in SORD to manage which
> order need to reserve the bandwidth ahead and which is not.
>
> Be glad to hear your and other people comment on this suggestion.
If you wanted to work on some issue like "Applicability of PCE to
time-scoped service requests" this might be of interest to people. It was raised
in the early days of PCE and of L1VPN, but did not attract significant interest.
I think that the feeling at the time was that it was out of scope for PCE, but
formed part of a management system. However, it might be that there would be
value in enhancing the PCE protocol to carry time delimiters for computation
requests.
Note that the PCE working group is interested in applications of PCE and
the protocols involved, but is not so interested in abstract functional
components that are beyond the scope of the working group.
Regards,
Adrian
_______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce
