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