Network Working Group A. Farrel
Internet-Draft Huawei Technologies
Intended status: Standards Track
Created: July 12, 2010 H. Endo
Expires: January 12, 2010 Hitachi
Handling MPLS-TP OAM Packets Targeted at Internal MIPs
draft-farrel-mpls-tp-mip-mep-map-02.txt
Abstract
The Framework for Operations, Administration and Maintenance (OAM)
within the MPLS Transport Profile (MPLS-TP) describes how
Maintenance Intermediate Points (MIPs) may be situated within network
nodes at the incoming and outgoing interfaces.
This document describes a way of forming OAM messages so that they
can be targeted at incoming MIPs and outgoing MIPs, forwarded
correctly through the "switch fabric", and handled efficiently in
optimized node implementations where there is no distinction between
the incoming and outgoing MIP.
The material in this document is provided for discussion within the
MPLS-TP community in the expectation that this idea or some similar
mechanism will be subsumed into a more general MPLS-TP OAM document.
This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunication Union Telecommunication
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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."
Farrel and Endo draft-farrel-mpls-tp-mip-mep-map-01.txt [Page 1]
Internet-Draft Internal MIP Handling February 2010
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.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
1. Introduction
The Framework for Operations, Administration and Maintenance (OAM)
within the MPLS Transport Profile (MPLS-TP) (the MPLS-TP OAM
Framework, [OAM-FWK]) describes how Maintenance Intermediate Points
(MIPs) may be situated within network nodes at the incoming and
outgoing interfaces.
In-band OAM messages are sent using the Generic Associated Channel
(G-ACh) [RFC5586]. OAM messages for the transit points of pseudowires
(PWs) or Label Switched Paths (LSPs) are delivered using the
expiration of the MPLS shim header time-to-live (TTL) field. OAM
messages for the end points of PWs and LSPs are simply delivered as
normal.
OAM messages delivered to end points or transit points are
distinguished from other (data) packets so that they can be processed
as OAM. In LSPs, the mechanism used is the presence of the Generic
Associated Channel Label (GAL) in the Label Stack Entry (LSE) under
the top LSE [RFC5586]. In PWs, the mechanism used is the presence of
the PW Associated Channel Header (PWACH) [RFC4385].
These mechanisms mean that all OAM messages intended for any MIPs on
a node are delivered to the MIP at the incoming interface.
This document describes a way of forming OAM messages so that they
can be targeted at incoming MIPs and outgoing MIPs, forwarded
Farrel and Endo draft-farrel-mpls-tp-mip-mep-map-01.txt [Page 2]
Internet-Draft Internal MIP Handling February 2010
correctly through the "switch fabric", and handled efficiently in
optimized node implementations where there is no distinction between
the incoming and outgoing MIP.
The material in this document is provided for discussion within the
MPLS-TP community in the expectation that this idea or some similar
mechanisms will be subsumed into a more general MPLS-TP OAM document.
This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunication Union Telecommunication
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architecture to support the
capabilities and functionalities of a packet transport network.
Note that the acronym "OAM" is used in conformance with [OAM-SOUP].
2. Summary of Problem Statement
Figure 1 shows an abstract functional representation of an MPLS-TP
node. It is decomposed as an incoming interface, a cross-connect
(XC), and an outgoing interface. As per the discussion in
[OAM-FWK], MIPs may be placed in each of the functional interface
components.
------------------------
| |
|----- -----|
| MIP | | MIP |
| | ---- | |
----->-| In |->-| XC |->-| Out |->----
| i/f | ---- | i/f |
|----- -----|
| |
------------------------
Figure 1 : Abstract Functional Representation of an MPLS-TP Node
Several distinct OAM functions are required within this architectural
model:
- CV between a MEP and a MIP
- traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing MIPs
- delay, performance, or whatever measurement at a MIP
- OAM control at a MIP
- data-plane loopback at a MIP
The MIPs in these OAM functions may equally be the MIPs at the input
or output interfaces.
Farrel and Endo draft-farrel-mpls-tp-mip-mep-map-01.txt [Page 3]
Internet-Draft Internal MIP Handling February 2010
In-band OAM messages are sent using the G-ACh [RFC5586] and the
ACH-TLVs [ACH-TLV] for MPLS-TP LSPs and MPLS-TP PWs, respectively.
OAM messages for the transit points of PWs or LSPs are delivered using
the expiration of the time-to-live (TTL) field in the top LSE of the
MPLS packet header. OAM messages for the end points of PWs and LSPs are
simply delivered as normal.
OAM messages delivered to end points or transit points are
distinguished from other (data) packets so that they can be processed
as OAM. In LSPs, the mechanism used is the presence of the Generic
Associated Channel Label (GAL) in the LSE under the top LSE
[RFC5586]. In PWs, the mechanism used is the presence of the PW
Associated Channel Header [RFC4385].
Any solution for sending OAM to the in and out MIPs must fit within
these existing models of handling OAM.
Additionally, many MPLS-TP nodes contain an optimization such that
all queuing and forwarding function is performed at the incoming
interface. The abstract functional representation of such a node is
shown in Figure 2. As shown in the figure, the outgoing interfaces
are minimal and for this reason it may not be possible to include MIP
function on those interfaces. This is particularly the case for
existing deployed implementations.
Any solution that attempts to send OAM to the outgoing interface of
an MPLS-TP node must not cause any problems when such implementations
are present.
------------------
| |
|------------ |
| MIP | |
| ---- | |
----->-| In | XC | |-->--|->---
| i/f ---- | |
|------------ |
| |
------------------
Figure 2 : Abstract Functional Representation of
an Optimized MPLS-TP Node
Lastly, OAM must operate on MPLS-TP nodes that are branch points on
point-to-multipoint (P2MP) trees. That means that it must be possible to
target individual outgoing MIPs as well as all outgoing MIPs in the
abstract functional representation shown in Figure 3, as well as to
handle the optimized P2MP node as shown in Figure 4.
Farrel and Endo draft-farrel-mpls-tp-mip-mep-map-01.txt [Page 4]
Internet-Draft Internal MIP Handling February 2010
--------------------------
| |
| -----|
| | MIP |
| ->-| |->----
| | | Out |
| | | i/f |
| | -----|
|----- | -----|
| MIP | ---- | | MIP |
| | | |- | |
----->-| In |->-| XC |--->-| Out |->----
| i/f | | |- | i/f |
|----- ---- | -----|
| | -----|
| | | MIP |
| | | |
| ->-| Out |->----
| | i/f |
| -----|
--------------------------
Figure 3 : Abstract Functional Representation of an
MPLS-TP Node Supporting P2MP
------------------
| |
| ->-|->----
| | |
|------------ | |
| | | |
| MIP ---- | | |
| | | |- |
----->-| In | XC | |--->-|->----
| i/f | | |- |
| ---- | | |
| | | |
|------------ | |
| | |
| ->-|->----
| |
------------------
Figure 4 : Abstract Functional Representation of an
Optimized MPLS-TP Node Supporting P2MP
Farrel and Endo draft-farrel-mpls-tp-mip-mep-map-01.txt [Page 5]
Internet-Draft Internal MIP Handling February 2010
In summary, the solution for OAM message delivery must support the
following features:
- Forwarding of OAM packets exactly as data packets.
- Delivery of OAM messages to the correct MPLS-TP node.
- Direction of OAM instructions to the correct MIP within an MPLS-TP
node.
- Packet inspection at the incoming and outgoing interfaces must be
minimized.
Note that although this issue appears superficially to be an
implementation matter local to an individual node, the format of the
message needs to be standardised so that:
- An upstream MEP can correctly target the outgoing MIP of a specific
MPLS-TP node.
- A downstream node can correctly filter out any OAM messages that
were intended for its upstream neighbor's outgoing MIP, but which
were not handled there because the upstream neighbor is an
optimized implementation.
2.1. Rejected Partial Solution
A reject solution is depicted in Figure 5. All data and non-local OAM
is handled as normal. Local OAM is intercepted at the incoming
interface and delivered to the MIP at the incoming interface. If the
OAM is intended for the incoming MIP it is handled there with no
issue. If the OAM is intended for the outgoing MIP it is forwarded
to that MIP using some internal messaging system that is
implementation-specific.
------------------------
| |
|----- -----|
local OAM ----->-| MIP |----->------| MIP |
| | ---- | |
data =====>=| In |=>=| XC |=>=| Out |=>==== data
non-local OAM ~~~~~>~| i/f |~>~| |~>~| i/f |~>~~~~ non-local OAM
|----- ---- -----|
| |
------------------------
Figure 5 : OAM Control Message Delivery Bypassing
the Switching Fabric
Farrel and Endo draft-farrel-mpls-tp-mip-mep-map-01.txt [Page 6]
Internet-Draft Internal MIP Handling February 2010
This solution is fully functional for the incoming MIP. It also
supports control of data loopback for the outgoing MIP, and can
adequately perform some OAM features such as interface identity
reporting at the outgoing MIP.
However, because the OAM message is not forwarded through the
switch fabric, this solution cannot correctly perform OAM loopback,
connectivity verification, LSP tracing, or performance measurement.
Note that the local OAM message means that the OAM message which
must be terminated, inspected and processed at the in or out MIP
of depicted MPLS-TP node in Figure 5.
3. Proposed Solution
Figure 6 shows a proposed message format for handling the OAM messages in different
cases described in Section 2. The subsections that follow describe
the processing rules for each case.
Note that this proposed solution requires a packet to be sent with
TTL=0. An alternative approach is described in Section 4.
Farrel and Endo draft-farrel-mpls-tp-mip-mep-map-01.txt [Page 7]
Internet-Draft Internal MIP Handling February 2010
------------------------
|----- -----|
| MIP | ---- | MIP |
----->-| In |->-| XC |->-| Out |->----
| i/f | ---- | i/f |
|----- -----|
------------------------
----------------- -------------------
data | Label=x | TTL=n |--------------->| Label=y | TTL=n-1 |
----------------- -------------------
----------------- -----------------
non-local | Label=x | TTL=2 |--------------->| Label=y | TTL=1 |
OAM |-----------------| |-----------------|
| GAL | | | GAL | |
|-----------------| |-----------------|
| ACH Type = OAM | | ACH Type = OAM |
----------------- -----------------
-----------------
in-MIP | Label=x | TTL=1 |---
OAM |-----------------| |
| GAL | | |
|-----------------| |
| ACH Type = OAM | |
----------------- |
<------
----------------- -----------------
out-MIP | Label=x | TTL=1 |--------------->| Label=y | TTL=0 |---
OAM |-----------------| |-----------------| |
| GAL | | | GAL | | |
|-----------------| |-----------------| |
| ACH Type = OAM | | ACH Type = OAM | |
|-----------------| |-----------------| |
| ACH TLV=out-MIP | | ACH TLV=out-MIP | |
----------------- ----------------- |
<-------
----------------- -----------------
out-MIP | Label=x | TTL=1 |--------------->| Label=y | TTL=0 |--->
not |-----------------| |-----------------|
supported | GAL | | | GAL | |
|-----------------| |-----------------|
| ACH Type = OAM | | ACH Type = OAM |
|-----------------| |-----------------|
| ACH TLV=out-MIP | | ACH TLV=out-MIP |
----------------- -----------------
Figure 6 : Packet Formats for In and Out MIP OAM in the case of LSPs
Farrel and Endo draft-farrel-mpls-tp-mip-mep-map-01.txt [Page 8]
Internet-Draft Internal MIP Handling February 2010
------------------------
|----- -----|
| MIP | ---- | MIP |
----->-| In |->-| XC |->-| Out |->----
| i/f | ---- | i/f |
|----- -----|
------------------------
----------------- -------------------
data | Label=x | TTL=n |-------------->| Label=y | TTL=n-1 |
----------------- -------------------
------------------ ------------------
non-local | Label=x | TTL=2 |------------->| Label=y | TTL=1 |
OAM |------------------| |------------------|
| PWACH Type = OAM | | PWACH Type = OAM |
------------------ ------------------
------------------
in-MIP | Label=x | TTL=1 |---
OAM |------------------| |
| PWACH Type = OAM | |
------------------ |
<------
------------------ ------------------
out-MIP | Label=x | TTL=1 |------------->| Label=y | TTL=0 |---
OAM |------------------| |------------------| |
| PWACH Type = OAM | | PWACH Type = OAM | |
|------------------| |------------------| |
| ACH TLV=out-MIP | | ACH TLV=out-MIP | |
------------------ ------------------ |
<-------
------------------ ------------------
out-MIP | Label=x | TTL=1 |------------->| Label=y | TTL=0 |--->
not |------------------| |------------------|
supported | PWACH Type = OAM | | PWACH Type = OAM |
|------------------| |------------------|
| ACH TLV=out-MIP | | ACH TLV=out-MIP |
------------------ ------------------
Figure 7 : Packet Formats for In and Out MIP OAM
in the case of PW OAM
Farrel and Endo draft-farrel-mpls-tp-mip-mep-map-01.txt [Page 9]
Internet-Draft Internal MIP Handling February 2010
3.1. Processing of Data and Non-Local OAM
The message formats and processing rules for data and non-local OAM
are not changed by this proposal.
The top-of-stack label is swapped and the top-of-stack TTL is
decremented.
3.2. Processing of In-MIP OAM
The message formats and processing rules for in-MIP OAM are not
changed by this proposal.
3.2.1. LSP Processing
The top-of-stack label is swapped and the top-of-stack TTL is
decremented and expires. The packet is examined further and the
GAL is discovered. Further inspection of the packet identifies that
the Associated Channel Header (ACH) type indicating that the packet
is OAM, and the packet is delivered to the in-MIP.
Note that an ACH TLV could be included to identify the in-MIP (as in
Section 3.3), but this is not required since the absence of such a
TLV could be inferred to indicate the in-MIP as the target (thus
achieving backward compatibility with existing in-MIP-only systems).
However, the CV or other OAM messages which need to verify the target
point must have the TLV of MIP ID described in [IDENT].
Detailed mechanism will be subsumed into a more general MPLS-TP OAM
document.
3.2.2. PW Processing
The top-of-stack TTL is decremented and expires. The S bit [RFC3032]
is found to be set, and the next nibble is examined. This shows that
a PWACH is present. The Channel Type field of the PWACH [RFC4385]
indicates that the packet is OAM, and the packet is delivered to the
in-MIP.
Note that an ACH TLV could be included to identify the in-MIP (as in
Section 3.3), but this is not required since the absence of such a
TLV could be inferred to indicate the in-MIP as the target (thus
achieving backward compatibility with existing in-MIP-only systems).
However, the CV or other OAM messages which need to verify the target
point must have the TLV of MIP ID described in [IDENT].
Detailed mechanism will be subsumed into a more general MPLS-TP OAM
document.
Farrel and Endo draft-farrel-mpls-tp-mip-mep-map-01.txt [Page 10]
Internet-Draft Internal MIP Handling February 2010
3.3. Processing of Out-MIP OAM
OAM messages intended for the out-MIP on a node are initially
intercepted as described in Section 3.2. That is the TTL expires and
further inspection of the packet indicates that it is OAM.
The incoming interface must forward the OAM message through the
switch fabric as if it was data. So, the packet is passed on
unchanged except that the TTL has been decremented and expired.
3.3.1. LSP Processing
When the top-of-stack TTL expires (i.e., is decremented to zero) the
next label is inspected and found to be the GAL. Further inspection
of the packet identifies the Channel type indicating that the packet
is OAM. An ACH TLV is required to indicate that the out-MIP is the
target. The packet is forwarded in the data plane.
If the outgoing interface is capable of packet inspection, the top-
level TTL is found to be zero and the packet is removed from the data
stream (i.e., not sent). The ACH type
confirms that the packet is OAM, and the ACH TLV indicates that the
out-MIP is the target.
If the outgoing interface is not capable of packet inspection the
packet will be forwarded out of the outgoing interface. See Section
3.5 for more details.
3.3.2. PW Processing
When the top-of-stack TTL expires and the PWACH is found, the Channel
Type shows that the packet is OAM. An ACH TLV is required to indicate
that the out-MIP is the target. The packet is forwarded in the data
plane.
If the outgoing interface is capable of packet inspection, the top-
level TTL is found to be zero and the packet is removed from the data
stream (i.e., not sent). The PWACH indicates that the packet is OAM,
and the ACH TLV indicates that the out-MIP is the target.
If the outgoing interface is not capable of packet inspection the
packet will be forwarded out of the outgoing interface. See Section
3.5 for more details.
3.4. Processing at P2MP Branch Nodes
At P2MP branch nodes, the OAM messages may be targeted at one or all
outgoing interfaces. It should be noted that packet replication is a
Farrel and Endo draft-farrel-mpls-tp-mip-mep-map-01.txt [Page 11]
Internet-Draft Internal MIP Handling February 2010
function of the switch fabric so that any OAM message forwarded by
the incoming interface will be passed to all outgoing interfaces.
The procedures operate as described in section 3.3 and ACH TLVs are
required to limit the OAM to one or more out-MIPs.
3.4.1. LSP Processing
The outgoing interfaces are able to determine whether the OAM message
is intended for the local out-MIP by examining a MIP identifier
carried in an ACH TLV. More than one MIP identifier can be included
to allow multiple out-MIPs on the same P2MP tree to be targeted by
the same OAM message.
A special MIP identifier number is used to indicate that all out-MIPs
on the P2MP PW are targets. This identifier must include an
identifier that is unique to the local node as described in [IDENT].
An OAM message received at an outgoing interface for a P2MP LSP but
not including any ACH TLVs to indicate the out-MIPs, should be
silently discarded.
OAM messages received at outgoing interfaces that support out-MIP
OAM, but not intended for the local MIP are silently dropped.
If the outgoing interface is not capable of packet inspection the
packet will be forwarded out of the outgoing interface. See Section
3.5 for more details.
3.4.2. PW Processing
The outgoing interfaces are able to determine whether the OAM message
is intended for the local out-MIP by examining a MIP identifier
carried in an ACH TLV. More than one MIP identifier can be included
to allow multiple out-MIPs on the same P2MP tree to be targeted by
the same OAM message. As described in Section 3.3.2, such ACH TLVs
are required for any out-MIP processing.
A special MIP identifier number is used to indicate that all out-MIPs
on the P2MP PW are targets. This identifier must include an
identifier that is unique to the local node as described in [IDENT].
OAM messages received at outgoing interfaces that support out-MIP
OAM, but not intended for the local MIP are silently dropped.
If the outgoing interface is not capable of packet inspection the
packet will be forwarded out of the outgoing interface. See Section
3.5 for more details.
Farrel and Endo draft-farrel-mpls-tp-mip-mep-map-01.txt [Page 12]
Internet-Draft Internal MIP Handling February 2010
3.5. Processing When There is No Out-MIP
When there is no out-MIP supported on an optimized switch
implementation there are two options.
1. The OAM message is intercepted at the incoming interface as
described in Section 3.3, but the incoming interface is aware that
it forms part of an optimized implementation that does not support
an out-MIP. It can discard the received OAM message, or respond to
indicate that the out-MIP is not supported.
2. The OAM message is intercepted and forwarded as described in
Section 3.3. Since there is no out-MIP, the message is forwarded
out of the outgoing interface to the next downstream MPLS-TP node
as shown at the bottom of Figures 6and 7. This means that the
packet will be received at the downstream node carrying a TTL that
has already expired (before it is decremented at the downstream
node) indicating that the packet should be silently discarded.
If the packet is examined in this case, it will reveal an ACH TLV
identifying a MIP that is not local to the downstream node. This
will result in the packet being dropped or a negative response
being sent.
4. Enhanced Proposed Solution
The mechanisms described in Section 3 can be enhanced by the use of a
new reserved label, the Outgoing MIP Label (OML). This label is
substituted for the GAL when an OAM message intended for an outgoing
MIP is processed at an incoming interface as shown in Figure 8.
The advantage of this mechanism is that the outgoing interface of the
local node and the incoming interface of the downstream node have
something more substantial to check than just the TTL value being
zero. In fact, it allows the message to be sent with TTL of one so
that the rules for sending packets with zero TTL are not compromised.
The disadvantage is that a further reserved label is used.
Note that an option is to allocate the OML as a purely local matter.
That means that the implementation allocates the value of the OML
from its local label space and assigns the meaning as described. This
approach, however, would be risky if the packet escaped and was
processed by the downstream node.
Farrel and Endo draft-farrel-mpls-tp-mip-mep-map-01.txt [Page 13]
Internet-Draft Internal MIP Handling February 2010
----------------- -----------------
out-MIP | Label=x | TTL=1 |--------------->| Label=y | TTL=1 |---
OAM |-----------------| |-----------------| |
| GAL | | | OML | | |
|-----------------| |-----------------| |
| ACH TLV=out-MIP | | ACH TLV=out-MIP | |
----------------- ----------------- |
<-------
----------------- -----------------
out-MIP | Label=x | TTL=1 |--------------->| Label=y | TTL=1 |--->
not |-----------------| |-----------------|
supported | GAL | | | OML | |
|-----------------| |-----------------|
| ACH TLV=out-MIP | | ACH TLV=out-MIP |
----------------- -----------------
Figure 8 : Use of the Outgoing MIP Label
5. Security Considerations
OAM security is discussed in [OAM-FWK] and [OAM-SEC].
OAM can provide useful information for detecting and tracing security
attacks.
OAM can also be used to illicitly gather information or for denial of
service attacks. Implementations are required to offer security
mechanisms for OAM. Deployments are strongly advised to use such
mechanisms.
6. IANA Considerations
This revision of this document does not make any requests of IANA.
If the solution described in Section 4 is adopted, a request will be
made to IANA for the allocation of a new reserved label.
7. Acknowledgments
TBD
Farrel and Endo draft-farrel-mpls-tp-mip-mep-map-01.txt [Page 14]
Internet-Draft Internal MIP Handling February 2010
8. References
8.1. Normative References
[RFC3032] E. Rosen et al., "MPLS Label Stack Encoding", RFC 3032,
January 2001.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and McPherson, D.,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word
for Use over an MPLS PSN", RFC 4385, February 2006
[RFC5586] Bocci, M., Vigoureux, M., and Bryant, S., "MPLS Generic
Associated Channel", RFC 5586, June 2009.
8.2. Informative References
[OAM-FWK] Busi, I., Niven-Jenkins, B., and Allan, D., "MPLS-TP OAM
Framework", draft-ietf-mpls-tp-oam-framework, work in
progress.
[OAM-SOUP] Andersson, L., Betts, M., van Helvoort, H., Bonica, R.,
and Romascanu, D., "The OAM Acronym Soup", draft-ietf-
opsawg-mpls-tp-oam-def, work in progress.
[OAM-SEC] Manral, V., "MPLS-TP General Authentication TLV for
G-ACH", draft-manral-mpls-tp-oam-security-tlv, work in
progress.
[ACH-TLV] Boutros, S., Bryant, S., Sivabalan, S., Swallow, G.,
Ward, D., and Manral, V., "Definition of ACH TLV
Structure", draft-ietf-mpls-tp-ach-tlv, work in progress.
[IDENT] Bocci, M., and Swallow, G., "MPLS-TP Identifiers",
draft-ietf-mpls-tp-identifiers, work in progress.
Authors' Addresses
Adrian Farrel
Huawei Technologies
Email: adrian.farrel@huawei.com
Hideki Endo
Hitachi, Ltd.
Email: hideki.endo.es@hitachi.com
Farrel and Endo Expires: August 26, 2010 [Page 15]