i have one specific comment ... what i see progressively is that work item
enters into the document of specific "architectures" ... while the role of
the working group is to - per charter -
The WG will specify a protocol for communication between LSRs (termed
Path Computation Clients - PCCs) and PCEs, and between cooperating
PCEs
note: LSR = Label Switching Router
i start to have some concerns in building around a PC (functional) element
a global network architecture with all related transactional user request
and so forth... so i have a suggestion - summarize the message around
section
5 and close this section by detailing areas of standardization
Lucy Yong <[EMAIL PROTECTED]>
24/05/2006 17:06
To: "'Adrian Farrel'" <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED]
Subject: [Pce] Comments about
draft-ietf-pce-architecture-05
Adrian,
The draft layouts the basic PCE architecture and expresses the motivation
for a PCE-based architecture. It is a good document.
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.
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. 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. A path computer engine has a
capability of taking a consideration about future pending orders while it
computes a path. 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.
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 |<-+----------+-> |
| | | | | |
| --------- | ----------
---------------
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.
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.
Regards,
Lucy Yong
Huawei Technologies, U.S.
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
