Tags:
create new tag
, view all tags
-- XiYang - 2012-02-15

OSCARS PCE message contains a PCEData element with the following content:

   <xsd:complexType name="PCEDataContent">
       <xsd:sequence>
           <xsd:element name="userRequestConstraint" type="api:userRequestConstraintType" maxOccurs="1" minOccurs="1" />
           <xsd:element name="reservedConstraint" type="api:reservedConstraintType" maxOccurs="1" minOccurs="0" />
           <xsd:element name="optionalConstraint" type="api:optionalConstraintType" maxOccurs="unbounded" minOccurs="0"/>
           <xsd:element name="topology" type="ctrlp:CtrlPlaneTopologyContent" maxOccurs="1" minOccurs="0" />
       </xsd:sequence>
   </xsd:complexType>

Current use of PCEData in initial PCECreate call does not require <topology>. The point-to-point request is represented by srcEndpoint and dstEndpoint in pathInfo of <userRequestConstraint>. The same information is repeated in <reservedConstrint> with more details in switchingCapabilityDescriptor. These need to be changed.

In order to represent ARCHSTONE Request and Service Topology, particularly for multi-point requests, the following convention is proposed:

  • Carrying <topology> element is mandated for both request and reply messages. The <topology> here is not the 'raw' (or 'workbench') topology to run computation on. Instead, it is the Request and Service Topology defined by the extended ARCHSTONE NML schema. The 'raw' topology should be obained from other channels.
  • <pathInfo> carried in <userRequestConstraint> and <reservedConstrint> will no longer describe "end points". It should only include <pathSetupMode> and <pathType> elements. No <layer2Info>, <layer3Info> or <path> element should be included. the <pathType> will have value 'RequestTopoloy' and 'ServiceTopology' to indicate the nature of the PCEData and point the API handler to use <topology> element instead for request and reply information.
  • <optionalConstraint> element will be used as is. We will continue to use <optionalConstraint> to carry extended information such as coScheduling request and reply. Extra information may need to be added to reference to IDs in the Requset and Service <topology> for correlated handling.

To smmarize, if following the above proposed convention-based semantics, we can accomodate the ARCHSTONE service topology without any change to the PCE API schema.

Topic revision: r1 - 2012-02-15 - XiYang
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback