Internet DRAFT - draft-oki-pce-vntm-def

draft-oki-pce-vntm-def




     Network Working Group                                       Eiji Oki 
     Internet Draft                                                   NTT 
     Category: Informational                           Jean-Louis Le Roux 
     Expires: December 2006                                France Telecom 
                                                            Adrian Farrel 
                                                       Old Dog Consulting 
                                                                June 2006 
      
     Definition of Virtual Network Topology Manager (VNTM) for PCE-based 
               Inter-Layer MPLS and GMPLS Traffic Engineering 
                                       
                        draft-oki-pce-vntm-def-00.txt 
      
   
                                       
     Status of this Memo 
      
     By submitting this Internet-Draft, each author represents that any 
     applicable patent or other IPR claims of which he or she is aware 
     have been or will be disclosed, and any of which he or she becomes 
     aware will be disclosed, in accordance with Section 6 of BCP 79.   
      
     Internet-Drafts are working documents of the Internet Engineering 
     Task Force (IETF), its areas, and its working groups.  Note that 
     other groups may also distribute working documents as Internet-
     Drafts. 
      
     Internet-Drafts are draft documents valid for a maximum of six 
     months and may be updated, replaced, or obsoleted by other 
     documents at any time. It is inappropriate to use Internet- Drafts 
     as reference material or to cite them other than as "work in 
     progress." 
      
     The list of current Internet-Drafts can be accessed at 
     http://www.ietf.org/ietf/1id-abstracts.txt. 
      
     The list of Internet-Draft Shadow Directories can be accessed at 
     http://www.ietf.org/shadow.html. 
      
     Abstract 
      
     A network may be built from multiple layers that may be technology-
     specific divisions, or may be administrative divisions. It is 
     important to globally optimize network resource utilization, taking 
     into account all layers, rather than optimizing resource 
     utilization at each layer independently. This allows better network 
     efficiency to be achieved through a process that we call inter-
     layer traffic engineering (TE).  
      
     The Virtual Network Topology (VNT) is defined as the network 
     topology formed by lower-layer LSPs and advertised to the higher 
     layer as TE links. The Path Computation Element (PCE) can be a 
     powerful tool to achieve inter-layer traffic engineering, but 
     requires a separate function to manage and control the VNT. 


     Oki et al.             Expires December 2006              [Page 1] 

                 draft-oki-pce-vntm-def-00.txt June 2006 
      
     This document defines the VNT Manager (VNTM), which manages and 
     controls the VNT for PCE-based inter-layer traffic engineering. 
      
      
     Table of Contents 
      
    1. Terminology.....................................................2 
    2. Introduction....................................................3 
    2.1.  Multiple Lower-Layer Networks................................4 
    3. Cooperation model between PCE and VNTM for Inter-Layer Path 
    Control.............................................................4 
    3.1.  VNT Management...............................................4 
    4. Functions of VNT Manager........................................6 
    4.1.  Lower-layer LSP Setup........................................6 
    4.1.1.  Configuration and Management Control Triggers..............6 
    4.1.2.  Higher-Layer PCE Triggers..................................6 
    4.1.3.  Establishment of Lower-Layer LSPs..........................6 
    4.1.4.  Ownership of Lower-Layer LSPs..............................7 
    4.1.5.  Ongoing Management of VNT Resources and Lower-Layer LSPs...7 
    4.2.  Advertisement of the VNT to the Higher Layer.................7 
    4.3.  Policy Control...............................................8 
    4.3.1.  Policies for VNT Establishment.............................8 
    4.3.2.  Policies for Handling PCE Triggers.........................8 
    4.3.3.  Policies for Responding to PCEs............................9 
    4.3.4.  Policies for Control of Advertisement......................9 
    4.3.5.  Policies for Ongoing Management............................9 
    4.3.6.  Policies for Preemptive Advertisement.....................10 
    4.3.7.  Policies for Preemptive LSP Establishment.................10 
    5. Communications between PCE and VNT Manager.....................11 
    5.1.  Interface From Higher-Layer PCE to VNT Manager..............11 
    5.2.  Interface From VNT Manager to Higher-Layer PCE..............11 
    5.3.  Interfaces From VNT Manager to Lower-Layer PCE..............11 
    6. Communications between VNT Manager and LSRs....................12 
    6.1.  Interfaces From VNT Manager to LSR..........................12 
    6.2.  Interfaces From LSR to VNT Manager..........................12 
    7. Security Considerations........................................12 
    8. Management Considerations......................................13 
    9. Acknowledgment.................................................13 
    10.  References...................................................13 
    10.1. Normative Reference.........................................13 
    10.2. Informative Reference.......................................13 
    11.  Authors' Addresses...........................................14 
    12.  Intellectual Property Statement..............................14 
   
      
  1. Terminology 
      
     This document uses terminology from the PCE-based path computation 
     Architecture [PCE-ARCH] and also common terminology from Multi 
       
     Oki et al            Expires December 2006                       2 

                 draft-oki-pce-vntm-def-00.txt June 2006 
      
     Protocol Label Switching (MPLS) [RFC3031], Generalized MPLS (GMPLS) 
     [RFC3945], and Multi-Layer Networks [MLN-REQ]. 
      
     VNT Manager (VNTM): an entity that manages and controls the Virtual 
     Network Topology (VNT). 
      
  2. Introduction 
      
     A network may be built from multiple layers. These layers may 
     represent separations of technologies (e.g., packet switch capable 
     (PSC), time division multiplex (TDM) lambda switch capable (LSC)) 
     [RFC3945], separation of data plane switching granularity levels 
     (e.g. PSC-1, PSC-2, VC4, VC12) [MLN-REQ], or a distinction between 
     client and server networking roles [MLN-REQ]. In this multi-layer 
     network, LSPs in a lower layer are used to carry higher-layer LSPs 
     across the lower-layer network. The network topology formed by 
     lower-layer LSPs and advertised to the higher layer as TE links is 
     called a Virtual Network Topology (VNT) [MLN-REQ].  
      
     It is important to optimize network resource utilization globally, 
     i.e. taking into account all layers, rather than optimizing 
     resource utilization at each layer independently. This allows 
     better network efficiency to be achieved and is what we call inter-
     layer traffic engineering. This includes mechanisms allowing the 
     computation of end-to-end paths across layers (known as inter-layer 
     path computation), and mechanisms for the control and management of 
     the VNT by setting up and releasing LSPs in the lower layers [MLN-
     REQ]. 
      
     Inter-layer traffic engineering is included in the scope of the 
     PCE-based path computation architecture [PCE-ARCH], and PCE can 
     provide a suitable mechanism for resolving inter-layer path 
     computation issues. 
      
     PCE Communication Protocol requirements for inter-layer traffic 
     engineering are set forth in [PCE-INTER-LAYER-REQ]. A framework for 
     PCE-based inter-layer traffic engineering is described in [PCE-
     INTER-LAYER-FRWK]. 
      
     As a result of inter-layer path computation, a PCE may determine 
     that there is insufficient bandwidth available in the higher-layer 
     network to support this or future higher-layer LSPs. The problem 
     might be resolved if new LSPs were provisioned across the lower-
     layer network and advertised as TE links into the higher-layer 
     network. Further, the modification, re-organization and new 
     provisioning of lower-layer LSPs might enable better utilization of 
     lower-layer network resources given the demands of the higher-layer 
     network. In other words, the VNT needs to be controlled and managed 
     in cooperation with inter-layer path computation. 
      
     PCE can be a powerful tool to achieve inter-layer traffic 
     engineering. PCE has a path computation function, but does not 
     include a function to manage and control the VNT [PCE-ARCH]. A 

       
     Oki et al            Expires December 2006                       3 

                 draft-oki-pce-vntm-def-00.txt June 2006 
      
     function, separate from PCE, to manage and control the VNT needs to 
     be defined. 
      
     This document defines the VNT Manager (VNTM) that manages and 
     controls the VNT for PCE-based inter-layer traffic engineering. 
     Path computation and "VNT Management" are distinct functions that 
     may, or may not, be collocated. To describe each function clearly, 
     VNTM is considered as a functional element in this document. 
      
    2.1. Multiple Lower-Layer Networks 
      
     It may be the case that a VNT is constructed from LSPs provisioned 
     in more than one lower-layer network, in which case the VNT Manager 
     coordinates the resources of multiple lower-layer networks in order 
     to construct a VNT for use by a higher layer network. 
      
     Unless necessary to highlight a specific point, this document 
     describes just a single lower-layer network since this makes for 
     easier reading. The reader should recall, however, that anywhere 
     that a lower-layer network is mentioned, the VNT Manager may have 
     made a choice between multiple such networks. 
   
  3. Cooperation model between PCE and VNTM for Inter-Layer Path Control 
      
     Two PCE modes defined in the PCE architecture [PCE-ARCH] can be 
     used to perform inter-layer path computation, and these are 
     described as two models for inter-layer path control in [PCE-INTER-
     LAYER-FRWK]. One is a cooperation model between PCE and VNTM, and 
     the other is a higher-layer signaling trigger model, where VNTM is 
     not involved [MLN-REQ]. This document discusses VNTM and therefore 
     considers only the cooperation model between PCE and VNTM. The 
     higher-layer signaling model is out of scope in this document.  
      
     From a topology visibility point of view, there are two models: a 
     single PCE path computation model, where a single PCE has 
     visibility of both layers' topology; and a multiple PCE path 
     computation model, where each PCE has visibility of a single 
     layer’s topology. In the following discussion, both path 
     computation models can be applied. 
      
      
    3.1. VNT Management 
      
        --------      ------      -------- 
       | PCE-Hi |--->| VNTM |<-->| PCE-Lo | 
        --------      ------      -------- 
            ^            :           ^ 
            :            : ..........: 
            :            : : 
            v            V V 
          -----        -----                  -----      ----- 
         | LSR |------| LSR |................| LSR |----| LSR | 
         | H1  |      | H2  |                | H3  |    | H4  | 
          -----        -----\                /-----      ----- 
       
     Oki et al            Expires December 2006                       4 

                 draft-oki-pce-vntm-def-00.txt June 2006 
      
                             \-----    -----/ 
                             | LSR |--| LSR | 
                             | L1  |  | L2  | 
                              -----    ----- 
      
     Figure 1: Cooperation model between PCE and VNTM 
      
     A multi-layer network consists of higher-layer and lower-layer 
     networks. In Figure 1, LSRs H1, H2, H3, and H4 belong to the 
     higher-layer network, LSRs H2, L1, L2, and H3 belong to the lower-
     layer network - H2 and H3 are layer border nodes. There are two 
     PCEs: PCE-Hi has visibility in he higher-layer network, and PCE-Lo 
     can see the topology of the lower-layer network. PCE-Hi may 
     communicate with PCE-Lo. PCE-Hi and PCE-Lo can be combined to a 
     single PCE that has both layers' topology visibility. 
      
     Consider that H1 requests PCE-Hi to compute an inter-layer path 
     between H1 and H4. There is no available TE link in the higher-
     layer between H2 and H3 before the path computation request.  
      
     The roles of the PCEs and VNTM are as follows:  
      
     - PCE-Hi performs inter-layer path computation and is unable to  
       supply a path because there is no available TE link between H2  
       and H3.  
      
     - The computation fails, and PCE-Hi may suggest to VNTM that a  
       lower-layer LSP (H2-H3) could be established to support future  
       LSP requests.  
      
     - VNTM uses local policy and possibly management/configuration 
       input to determine how to process the suggestion from PCE-Hi, and 
       may request an ingress LSR (in this case H2) to establish a  
       lower-layer LSP, or may directly configure the LSRs in the lower- 
       layer network in order to achieve the lower-layer LSP.  
      
     - VNTM or the ingress LSR (H2) may use a second PCE (PCE-Lo) with  
       visibility into the lower layer to compute the path of this new  
       LSP. 
      
     If PCE-Hi cannot compute a path for the higher-layer LSP without 
     the establishment of a further lower-layer LSP, PCE-Hi that 
     notifies VNTM may wait for the lower-layer LSP to be set up and 
     advertised as a TE link. It can then compute the complete end-to-
     end path for the higher-layer LSP and return the result to the PCC. 
     In this case, the PCC may be kept waiting some time, and it is 
     important that the PCC understands this. The higher-layer PCE and 
     VNTM must have mechanisms to control the time that the PCE will 
     wait and that the PCC will be kept waiting. This may take the form 
     of any or all of the following: 
      
     - An agreement between the PCE and VNTM that the lower-layer LSP 
     will be set up in a timely manner. That is, an agreement that 

       
     Oki et al            Expires December 2006                       5 

                 draft-oki-pce-vntm-def-00.txt June 2006 
      
     following such a notification by PCE, a lower-layer LSP will be 
     provided within a well-known time period. 
      
     - A timeout operated by the PCE such that if no lower-layer LSP is 
     provided in a well-known time, the PCE will give up and fail the 
     computation request back to the PCC. Such a timeout might be a 
     default on the PCE, or might be supplied as part of the request by 
     the PCC. 
      
     - A timeout operated by the PCC such that if no response is 
     received by the PCC within a certain time it will give up and 
     cancel the computation request. 
      
     - A notification mechanism so that the VNTM can inform the PCE that 
     it is attempting to set up the necessary LSP or that no new LSP 
     will become available.  
      
     An example of such a cooperative procedure between PCE and VNTM is 
     described in [PCE-INTER-LAYER-FRWK]. 
      
      
  4. Functions of VNT Manager 
      
     This section lists the major functions performed by the VNT Manager. 
      
    4.1. Lower-layer LSP Setup 
   
     Management of the LSPs in the lower layer network falls into 
     several distinct functional elements. 
      
   4.1.1. Configuration and Management Control Triggers 
      
     The VNT may be entirely under the control of the operator through 
     configuration or management control. In this case, VNT Manager 
     performs functions to map the operator's requests onto requests to 
     provision lower-layer LSPs. For example, the operator may request 
     the establishment of a TE link in the higher-layer (that is, in the 
     VNT) between two layer border nodes leaving it to VNT Manager to 
     determine how to realize this TE link. The operator may also be 
     more specific and define how this TE link will be supported by the 
     lower-layer network. 
      
   4.1.2. Higher-Layer PCE Triggers 
      
     VNTM may receive suggestions (notification or lower-layer LSP setup 
     request) from a PCE that new TE links in the higher-layer network 
     would be helpful and that lower-layer LSPs should be established if 
     judged by VNTM to be necessary and possible, and if acceptable 
     within VNTM’s policy constraints.  
      
   4.1.3. Establishment of Lower-Layer LSPs 
      
     VNTM reviews the triggers that it receives, the existing lower-
     layer LSPs, the available resources, and the current and predicted   
     
     Oki et al            Expires December 2006                       6 

                 draft-oki-pce-vntm-def-00.txt June 2006 
      
     VNT usage, and may request ingress LSRs in the lower-layer network 
     to establish one or more lower-layer LSPs. These requests may 
     include pre-computed lower-layer LSP routes obtained from the PCE 
     responsible for the lower-layer network, or may require the ingress 
     LSRs to perform path computations (possibly using the PCE for the 
     lower layer network) in order to determine the routes of the LSPs. 
      
     The VNTM may also configure the LSRs in the lower-layer network 
     directly if that network is under management plane control. 
      
     Further, where (as described in Section 2.1) the VNT is constructed 
     from resources in more than one lower-layer network, VNT Manager 
     will apply policies to determine in which lower-layer network the 
     new LSPs should be established. 
      
   4.1.4. Ownership of Lower-Layer LSPs 
      
     VNTM is the 'owner' of the lower-layer LSPs that it causes to be 
     created. It receives notifications from the ingress LSRs when the 
     LSRs are established, and collects information about the TE 
     attributes, status, and usage of those LSPs. 
      
   4.1.5. Ongoing Management of VNT Resources and Lower-Layer LSPs 
      
     VNTM constantly monitors the demand and usage of VNT resources 
     (that is, of the TE links provided to the higher-layer network), 
     and the usage and status of the lower-layer LSPs that it has 
     created. It uses this information together with local policy (see 
     Section 4.3) to manage the lower-layer LSPs. 
      
     Such management might include: 
      
     - Teardown of unused lower-layer LSPs. 
      
     - Predictive establishment of lower-layer LSPs to increase the 
       capacity of TE links in the VNT or to provide additional TE links. 
      
     - Coordination with the higher layer to achieve controlled grooming  
       and reoptimization of the use of the higher-layer TE links in 
       order to release LSPs and resources in the lower layer. Such 
      reoptimization may require correlated path computation of lower 
      layer LSPs paths, which may be achieved using a PCE in the lower 
      layer. 
      
    4.2. Advertisement of the VNT to the Higher Layer 
     
     VNT Manager is responsible for determining which TE links provided 
     by the lower layer are advertised to the higher-layer network. That 
     is, it defines the VNT. 
      
     Advertisement may take two non exclusive forms: 
      
     - Where VNTM has received a trigger notification from a higher- 
       layer PCE, and where that notification has requested it, VNTM may 
       
     Oki et al            Expires December 2006                       7 

                 draft-oki-pce-vntm-def-00.txt June 2006 
      
       inform the PCE directly that the lower-layer LSP is established 
       and provide the related TE information (TE link ids, etc.) That is, 
       it notifies the 
       PCE of the existence of a new TE link, or of the change in  
       capabilities of an existing TE link. 
      
     - The VNTM may advertise the new TE link or changed  
       TE link capabilities into the Traffic Engineering Database (TED) 
       used by the PCE in the higher-layer network. Such an 
       advertisement might be: 
      
        - through the routing protocols (IGPs) operating in the higher 
          layer with the ingress layer border node being instructed by 
          the VNTM about what to advertise 
      
        - through the routing protocols (IGPs) operating in the higher 
          layer with the VNTM playing an active part in advertising TE  
          links. 
      
        - by other means direct to the TED on the PCE. 
      
     Thus, PCE may get to know about the existence of the new VNT 
     resources immediately or when the IGP converges. 
      
    4.3. Policy Control 
      
     VNT Manager may have significant policy control functions that can 
     be configured by the service provider. 
      
   4.3.1.  Policies for VNT Establishment 
      
     Initial VNT establishment and the establishment of the lower-layer 
     LSPs necessary to support the VNT is under the control of the 
     operator. This is a policy function for several reasons. 
      
     - The lower-layer network may have other responsibilities as well 
       as supporting the VNT. That is, it may also have to carry traffic 
       in its own right. There is a policy-based balance between the use 
       of lower-layer resources for the VNT and for native LSPs. 
      
     - There may be more than one VNT supported by the lower-layer 
       network. That is, there may be more than one higher-layer network 
       that depends on the lower-layer network to provide it with 
       connectivity and capacity. These VNTs may be entirely independent. 
       There is a role for policy in determining how lower-layer 
       resources are allocated to support the different VNTs, and to 
       what extent the VNTs are able to share lower-layer resources. 
      
   4.3.2.  Policies for Handling PCE Triggers 
   
     When VNTM receives a suggestion from PCE that new upper-layer TE 
     resources are desired, VNTM determines whether lower-layer LSPs 
     should be established and what type of LSPs are set up according to 
     the local policy, requested parameters, and network conditions. 
       
     Oki et al            Expires December 2006                       8 

                 draft-oki-pce-vntm-def-00.txt June 2006 
      
     This policy is very likely to vary depending on the PCE that sends 
     the notification - some PCEs may have higher trust levels, and some 
     may have greater authority. 
      
     Acceptable policies for VNTM include: 
     - ignoring (discarding) the notification 
     - rejecting the request by informing the PCE that no action will be 
       taken 
     - storing the notification to build a pattern of demand 
     - acting immediately to establish the necessary lower-layer LSPs 
     - responding as though lower-layer LSPs had already been  
       established (see Section 4.3.6). 
      
     Note that VNTM may choose to establish LSPs to provide a TE link 
     considerably larger than indicated by the notification from the PCE. 
     This choice, under control of local policy, could reduce the 
     requirement for small incremental change to the VNT and might 
     reduce the interactions between PCE and VNTM. Such policy might 
     also be influenced by the capacity of resources in the lower-layer 
     network. 
      
   4.3.3.  Policies for Responding to PCEs 
      
     Section 3 describes how a PCE may wait for a response from VNTM 
     before completing a computation request. But VNTM does not 
     necessarily have to provide a positive or negative response. 
     According to policy, VNTM may also either simply not respond to the 
     PCE, or may respond to say that it is not providing any further 
     information. These policies may be applicable in conjunction with 
     policies for advertisement (see Section 4.3.4). 
      
      
   4.3.4. Policies for Control of Advertisement 
      
     It is possible that a VNT Manager will choose not to advertise all 
     TE link changes into the higher-layer network immediately or at all. 
     For example, some changes may be relatively small and might cause 
     unnecessary advertisement traffic (such as in the IGP). Other TE 
     links might be notified directly to the requesting PCE, but not 
     generally advertised - such TE links are on a par with static links 
     configured only at the PCE. 
      
     Such advertising policies should be under the control of the 
     operator. 
      
   4.3.5.  Policies for Ongoing Management 
      
     Local policy will determine how VNTM handles lower-layer LSPs that 
     are not carrying traffic but support TE links in the VNT. Such LSPs 
     may be retained for use in the VNT, reassigned for other uses (such 
     as for other VNTs), or torn down. Careful consideration would be 
     necessary to prevent LSP flapping. 
             
     Oki et al            Expires December 2006                       9 

                 draft-oki-pce-vntm-def-00.txt June 2006 
      
     When an LSP is torn down or reassigned, the TE link would normally 
     be removed or appropriately reduced within the VNT. However, the 
     same policy-based considerations as described in Section 4.3.6 for 
     preemptive advertisement apply in this case. 
      
     Further, ongoing management of the VNT may determine a pattern of 
     notifications from the PCEs or a pattern of increasing traffic 
     demand and may react by increasing the TE capacity in the VNT as 
     described in Section 4.3.7. 
      
     Note that when a VNT is modified as the result of a PCE trigger, it 
     is possible that VNT Manager does not inform the PCE directly, but 
     simply causes a change to the advertisement of the available VNT 
     resources, requiring PCE to pick this information up in the usual 
     way. 
      
     A VNT Manager may implement its own policies for protection and 
     recovery of the LSPs that support the TE links in the VNT. This may 
     enable the TE links to be recovered within the lower-layers without 
     disruption of the VNT. This policy is likely to be coordinated with 
     the desired protection qualities indicated by the PCE, and the link 
     protection attributes advertised for the TE link into the higher-
     layer network. 
      
   4.3.6. Policies for Preemptive Advertisement 
      
     A VNT Manager may choose to advertise VNT resources (TE capacity) 
     before the lower-layer LSPs have been established. This may be done 
     to facilitate a better TE mesh in the higher-layer network while 
     conserving resources in the lower-layer network. 
      
     In this case the lower-layer LSPs should be theoretically possible 
     based on an analysis of the available lower-layer resources, and 
     might rely on PCE path computations within the lower-layer network. 
     Periodic reassessment of the state of the lower-layer network might 
     cause changes in the preemptively advertised TE links. 
      
     Note that if an attempt is made by the higher-layer network to use 
     such TE links, the layer border router will need to trigger the 
     establishment of the requisite lower-layer LSPs, therefore, VNT 
     Manager must also coordinate with those LSRs. 
      
     This behavior is dependent on policy configured at the VNT Manager. 
      
   4.3.7. Policies for Preemptive LSP Establishment 
      
     VNT Manager may also pre-establish LSPs that it predicts will be 
     useful to support TE links in one or more VNTs. This behavior ties 
     up lower-layer resources, but allows a more rapid response when TE 
     links are needed in the higher-layer networks. 
      
     Since there is an operational trade-off here, it is a feature that 
     should be under the control of policy at the VNT Manager. 
      
       
     Oki et al            Expires December 2006                      10 

                 draft-oki-pce-vntm-def-00.txt June 2006 
      
     Such policies might be linked to knowledge of time-based resource 
     requirements in the higher-layer network especially where resources 
     are needed at peak times or to meet certain scheduled services. 
      
  5. Communications between PCE and VNT Manager 
      
    5.1. Interface From Higher-Layer PCE to VNT Manager 
      
     PCE needs to be able to communicate to VNT Manager that it would 
     like additional TE capacity in the higher-layer network. Such a 
     notification needs at least the following information: 
     - end points of the TE link capacity desired 
     - whether a modification of existing TE links would be acceptable 
     - protection type and diversity from existing TE links 
     - desired QoS characteristics (especially delay) for the new TE  
       link 
     - switching and encoding types. 
      
     The PCE can also supply information as follows: 
     - whether the PCE intends to wait for a response, and if so, for  
       how long 
     - some measure of the urgency of the demand it is facing (for 
       example, whether it is receiving repeated requests, or whether 
       this is as a result for a high priority service) 
     - some description of the service it will place on the TE link 
       (that is, it may request a high capacity TE link, but only plan 
       on placing a low capacity service) 
     - advice about what cost metric to assign when the created TE link 
       is advertised. 
      
     Potential candidate protocols for the interfaces  are, for example, 
     PCEP extensions, SOAP, and proprietary interfaces. 
      
    5.2. Interface From VNT Manager to Higher-Layer PCE 
      
     VNT Manager may want to be able to respond to PCE as follows: 
     - No action will be taken as a result of your notification. 
     - Don't wait for a TE link to be created/modified. 
     - TE link creation/modification not possible or failed. 
     - TE link creation/modification in progress. 
     - TE link creation/modification performed. New TE link details will 
       be advertised as normal. 
     - TE link creation/modification performed. New TE link details 
       included. 
      
     Note that this response interface is optional. That is, since the 
     VNT is already advertised through normal mechanisms, there is no 
     direct need for this interface. 
      
    5.3. Interfaces From VNT Manager to Lower-Layer PCE 
      
     VNT Manager may need to consult a PCE responsible for the lower-
     layer network in order to determine the viability of new TE link 
     creation or to select the paths of new lower-layer LSPs. 
       
     Oki et al            Expires December 2006                      11 

                 draft-oki-pce-vntm-def-00.txt June 2006 
      
      
     In this relationship with the lower-layer PCE, VNTM acts as a PCC 
     and uses the normal PCC-PCE interface. 
      
  6. Communications between VNT Manager and LSRs 
      
    6.1. Interfaces From VNT Manager to LSR 
   
     When VNT Manager requires one or more LSPs to be set up or modified 
     in the lower-layer network it issues commands to the LSRs in the 
     lower-layer network. 
      
     If the lower-layer network is under management plane control, these 
     commands will be sent to each LSR along the path of the desired 
     LSPs in order to provision resources and cross-connects. In this 
     case, VNT Manager would use existing standard (for example, SNMP 
     control of MPLS-LSR-STD-MIB [RFC3813] and GMPLS-LSR-STD-MIB [GMPLS-
     LSR-MIB]) or proprietary management interfaces. 
      
     If the lower-layer network is under the control of a control plane, 
     these commands are sent to the head-end (ingress) LSRs for each of 
     the required LSPs. In this case, VNT Manager would use existing 
     standard (for example, SNMP control of MPLS-TE-STD-MIB [RFC3812] 
     and GMPLS-TE-STD-MIB [GMPLS-TE-MIB]) or proprietary management 
     interfaces. The head-end LSRs might need to consult a PCE to 
     complete the necessary path computation. 
      
     Additionally, VNT Manager needs to control the way that new TE 
     links are advertised into the higher-layer network as part of the 
     VNT. If the head-end LSR is responsible for this advertisement, 
     this information can be passed to the head-end LSR either on the 
     LSP setup request, or in a separate exchange after the LSP has been 
     set up. 
      
    6.2. Interfaces From LSR to VNT Manager 
      
     VNT Manager may need to know when lower-layer LSPs have been set up, 
     or when they have been impacted by network events. This is not a 
     requirement in all models because the head-end LSRs may be 
     responsible for managing TE link advertisement into the higher-
     layer network, and because the VNTM might not be sending responses 
     direct to the higher-layer PCE. 
      
     If this feature is required, the interface can be provided by 
     notifications from existing standard (for example, SNMP control of 
     MPLS-TE-STD-MIB [RFC3812] and GMPLS-TE-STD-MIB [GMPLS-TE-MIB]) or 
     proprietary management interfaces. 
      
  7. Security Considerations 
      
     Inter-layer traffic engineering with PCE may raise new security 
     issues in the cooperation model between PCE and VNTM.  

       
     Oki et al            Expires December 2006                      12 

                 draft-oki-pce-vntm-def-00.txt June 2006 
      
     VNTM introduces new communication flows and these must be secured 
     against all normal attacks. Using existing protocol techniques 
     (such as SNMPv3 [SNMPv3] and PCEP [PCEP]) will allow the security 
     model to be constructed easily. The introduction of new protocols 
     would require careful analysis of the protocol issues. 
      
     Further analysis of the security mechanisms necessary for VNTM to 
     ensure authenticity, privacy and integrity will be provided in a 
     later version of this document.  
      
  8. Management Considerations 
      
     TBD 
      
  9. Acknowledgment 
      
    We would like to thank Kohei Shiomoto and Ichiro Inoue for their 
    useful comments. 
      
  10.     References 
      
  10.1. Normative Reference 
      
     [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 
     Label Switching Architecture", RFC 3031, January 2001.  
      
     [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 
     Architecture", RFC 3945, October 2004. 
      
     [MLN-REQ] K. Shiomoto et al., "Requirements for GMPLS-based multi-
     region networks (MRN) ", draft-ietf-ccamp-gmpls-mln-reqs (work in 
     progress). 
      
     [PCE-ARCH] A. Farrel, JP. Vasseur and J. Ash, "Path Computation 
     Element (PCE) Architecture", draft-ietf-pce-architecture (work in 
     progress). 
      
      
  10.2. Informative Reference 
      
       
     [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, 
     "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) 
     Management Information Base (MIB)", RFC 3812, June 2004.  
      
     [RFC3813] Srinivasan, C., Viswanathan, A., and T.  Nadeau, 
     "Multiprotocol Label Switching (MPLS) Label Switching (LSR) Router 
     Management Information Base (MIB)", RFC 3813, June 2004. 
      
     [GMPLS-LSR-MIB] Nadeau, T. and A. Farrel, "Generalized 
     Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) 
     Management Information Base", draft-ietf-ccamp-gmpls-lsr-mib, (work 
     in progress).  
      
       
     Oki et al            Expires December 2006                      13 

                 draft-oki-pce-vntm-def-00.txt June 2006 
      
     [GMPLS-TE-MIB] Nadeau, T. and A. Farrel, "Generalized Multiprotocol 
     Label Switching (GMPLS) Traffic Engineering Management Information 
     Base", draft-ietf-ccamp-gmpls-te-mib, (work in progress). 
      
     [PCE-INTER-LAYER-FRWK] E. Oki et al., " Framework for PCE-Based 
     Inter-Layer MPLS and GMPLS Traffic Engineering", draft-ietf-pce-
     inter-layer-frwk (work in progress). 
      
     [PCE-INTER-LAYER-REQ] E. Oki et al., "PCC-PCE Communication 
     Requirements for Inter-Layer Traffic Engineering" draft-ietf-pce-
     inter-layer-req (work in progress). 
      
     [PCEP] JP. Vasseur et al, "Path Computation Element (PCE) 
     communication Protocol (PCEP) - Version 1 -" draft-ietf-pce-pcep 
     (work in progress). 
      
     [SNMPv3] Case, J., Mundy, R., Partain, D., and B. Stewart, 
     "Introduction and Applicability Statements for Internet-Standard 
     Management Framework", RFC 3410, December 2002. 
      
  11.     Authors' Addresses 
      
     Eiji Oki  
     NTT  
     3-9-11 Midori-cho,  
     Musashino-shi, Tokyo 180-8585, Japan 
     Email: oki.eiji@lab.ntt.co.jp 
      
     Jean-Louis Le Roux  
     France Telecom R&D,   
     Av Pierre Marzin,   
     22300 Lannion, France  
     Email: jeanlouis.leroux@francetelecom.com 
      
     Adrian Farrel 
     Old Dog Consulting 
     Email: adrian@olddog.co.uk 
      
  12.     Intellectual Property Statement 
      
     The IETF takes no position regarding the validity or scope of any 
     Intellectual Property Rights or other rights that might be claimed 
     to pertain to the implementation or use of the technology described 
     in this document or the extent to which any license under such 
     rights might or might not be available; nor does it represent that 
     it has made any independent effort to identify any such rights.  
     Information on the procedures with respect to rights in RFC 
     documents can be found in BCP 78 and BCP 79. 
      
     Copies of IPR disclosures made to the IETF Secretariat and any 
     assurances of licenses to be made available, or the result of an 
     attempt made to obtain a general license or permission for the use 
     of such proprietary rights by implementers or users of this 

       
     Oki et al            Expires December 2006                      14 

                 draft-oki-pce-vntm-def-00.txt June 2006 
      
     specification can be obtained from the IETF on-line IPR repository 
     at http://www.ietf.org/ipr. 
      
     The IETF invites any interested party to bring to its attention any 
     copyrights, patents or patent applications, or other proprietary 
     rights that may cover technology that may be required to implement 
     this standard.  Please address the information to the IETF at ietf-
     ipr@ietf.org. 
      
     Disclaimer of Validity 
      
     This document and the information contained herein are provided on 
     an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
     REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 
     THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 
     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 
     THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 
     ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 
     PARTICULAR PURPOSE. 
      
     Copyright Statement 
      
     Copyright (C) The Internet Society (2006).  This document is 
     subject to the rights, licenses and restrictions contained in BCP 
     78, and except as set forth therein, the authors retain all their 
     rights. 
      



























       
     Oki et al            Expires December 2006                      15