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
