Internet DRAFT - draft-choi-pcemp-ipv6
draft-choi-pcemp-ipv6
Network Working Group Jun Kyun Choi (BcN ERC)
Internet Draft Dipnarayan Guha (NTU)
Category: Informational
Expires: January 2007 August 2006
Fast IPv6 PCE peer Advertisement using PCEMP
draft-choi-pcemp-ipv6-05.txt
Status of this Memo
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.
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.
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.
Copyright (C) The Internet Society (2006).
Abstract
In this draft, we propose a guideline for an improved version of
router handling procedures in RFC 2461 that allow for improved
default router acquisition performance when an active IP host moves
from one subnet to the other using the Path Computation Element
Metric Protocol (PCEMP). Router handling procedures can be improved
by a soft configuration of PCEMP support in the context of
real-time data driven strategy on individual PCE nodes and this
draft shows how PCEMP can support that.
This draft is an informational draft that shows a guideline to
specifications of modifying existing protocols to facilitate
communication between LSRs and PCEs, and between a PCE and other
PCEs. This can also be a guideline for mobile PCE nodes changing
respective PCEDAs and thus needing fast advertisements to the
corresponding LSRs and other PCE peers using IPv6 schemes.
Choi, Guha Informational [Page 1]
Internet Draft draft-choi-pcemp-ipv6-05.txt August 2006
Table of Contents
1 Terminology ................................................. 3
2 Introduction ................................................ 4
3 Fast PCE peer advertisement ................................. 4
4 Fast processing of PCE peer solicitations ................... 4
4.1 PCE peer architecture as seen by the PCEMP protocol ..... 4
4.2 Realization of fast path computing unit architecture
using PCEMP.................................................. 5
4.3 Configuration of PCE peers for fast processing of
solicitations ............................................... 5
4.4 Protocol implementation considerations using PCEMP ...... 6
4.4.1 Inter-domain point-to-multipoint considerations ... 7
5 Security Considerations ..................................... 8
6 IANA Considerations ......................................... 8
7 Acknowledgements ............................................ 8
8 Intellectual Property Considerations ........................ 8
9 Normative References ........................................ 9
10 Informational References .................................... 9
11 Authors' Addresses .......................................... 10
12 Full Copyright Statement .................................... 10
Choi, Guha Informational [Page 2]
Internet Draft draft-choi-pcemp-ipv6-05.txt August 2006
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
This memo makes use of the following terms:
1. Path Computation Element (PCE): an entity that is responsible
for computing/finding inter/intra domain LSPs. This entity can
simultaneously act as a client and a server. Several PCEs can
be deployed in a given AS.
2. Path Computation Element node (PCE Node): a network processing
unit comprising of a PCE unit. This can be embedded in a router
or a switch.
3. Domain: Denotes an Autonomous system (AS) within the scope of
this draft.
Choi, Guha Informational [Page 3]
Internet Draft draft-choi-pcemp-ipv6-05.txt August 2006
2. Introduction
According to RFC 2461 [1] , a participating router MUST delay a
response to a Router Solicitation (RS) by a random time between 0
and MAX_RA_DELAY_TIME seconds. The idea behind MAX_RA_DELAY_TIME is
that if there is more than one router on the link, simultaneously
transmitted responses will collide if the routers try to answer
the RS immediately, and, additionally, to avoid congestion when
a link comes up and all hosts on the link solicit.
This can be a performance bottleneck in the case of default
PCE peer acquisition for PCE nodes that are moving between
PCEDAs [2]. The PCEMP protocol architecture enable the
corresponding PCE peers to exchange information tags instantaneously
upon discovery at any point of time. The concept of synchonization
of information between PCE nodes even in the case of a change in the
corresponding PCEDA can help in fast default PCE peer acquistion.
3. Fast PCE peer advertisement
To enable fast response time in PCE peer solicitation processing,
at most one PCE node on any given PCEDA SHOULD be allowed to
respond immediately to the PCE peer solicitations sent out by PCE
peers on that PCEDA.
This mechanism is enabled using the SCM based fast computation
techniques defined in [2].
4. Fast processing of PCE peer solicitations
4.1 PCE peer architecture as seen by the PCEMP protocol
These are the PCE unit architectures as seen by the PCEMP protocol
state machines during path computation:
1. A matrix and parallel vector arithmetic unit that provides
parallel data processing capabilities on the commonly used matrix
and vector mathematical data types. Performance of this unit is
independent of the size of the data vector under computation. This
is implemented in the CC and SPC [2].
2. The processing core that provides the ease of programming and
flexibility to address changing algorithms and standards. There
exists a one-to-one map from the transform computed by the core
to the high-level code generated by the PCE application. This is
implemented using soft memory techniques in the CC, SPC and SCM.
Choi, Guha Informational [Page 4]
Internet Draft draft-choi-pcemp-ipv6-05.txt August 2006
3. A high-speed I/O system that allows complex, adaptive
algorithms to be partitioned cost-effectively across multiple sub
PCE unit blocks by providing dual ports. These ports are logically
indistinguishable across the ordered pair of a data vector and the
corresponding transform that is executed.
These units are images of the PCE computing unit that are mapped
onto the PCEMP state machines.
4.2 Realization of fast path computing unit architecture using PCEMP
Concept: Iterative applications of the PCEMP DS. Two or more
IDT [2] encoders separated by an interleaver (respectively CC and
SPC). This structure suggests a decoding strategy based on the
iterative passing of soft-computing information between two
decoding algorithms. This is equivalent to dynamically partitioning
the path computing engine core into sub-units that are linked
together real-time based on the input data and the protocol handler.
Basic Computation: Configure PCEMP DS to compute soft-decisions in
terms of measures. An assigned measure is given to each branch of
the IDT.
4.3 Configuration of PCE peers for fast processing of solicitations
A PCE peer that is configured to provide fast solicitation
processing maintains a soft decision counter and multiple IDT
encoders in the form of CCs and SPCs. This might not be physical
hardware, the entities may be capable of a soft configuration on
individual LSRs and PCEs.
From [2], we know that there are two distinct finite state machine
handlings of the PCEMP protocol architecture that are configured
on each participating PCE peer. They are when the PCE unit block
is invoked for constantly changing data profiles within the time
of goodness of fit (MAX_PCE_TIME_FIT), and the case where the PCE
unit block is invoked only once for a variable data profile and
the data tagged (tags) within MAX_PCE_TIME_FIT.
When a PCE peer solicitation request is received, the corresponding
PCE node ACK MUST be sent immediately if:
CC & SPC IDT encoder count <= max tags (MAX_PCE_TIME_FIT)
where max tags determine the computing potential within
MAX_PCE_TIME_FIT [2].
A PCE peer SHOULD unicast the response directly to the soliciting
PCE node's address, else it SHOULD schedule a multicast Router
Advertisement in accordance with RFC 2461.
Choi, Guha Informational [Page 5]
Internet Draft draft-choi-pcemp-ipv6-05.txt August 2006
When a PCE node ACK is sent, the IDT encoder count is not
incremented but a corresponding flag written on the output branch
measure using the z-parameter [2].
This process ensures that the IDT encoder count never exceeds
max tags (MAX_PCE_TIME_FIT). If there is such a possibility, the
PCEDA partitioning is recomputed by the PCE node.
4.4 Protocol implementation considerations using PCEMP
|----------- (1) ------------>|
| |
|<-----------(2) -------------|
| |
|------------(3) ------------>|
| |
|<-----------(4) -------------|
| |
|------------(5) ------------>|
| |
|<-----------(6) -------------|
PCE1 PCE2
Figure 1: PCEMP message exchanges between PCE elements
For fast PCE peer advertisement, we can use PCEMP messaging for
implementing router solicitation in PCEDAs using PCE techniques.
Here is a sample sequence of messaging that helps in the PCE nodes
maintain soft PCEMP status. Details about the protocol messages can
be found in [2].
(1): Send a PCEMP Common Header with the COMPUTE_PATH enabled in the
PCEMode field and the ACK REQUESTED enabled in the PCEFlag field.
The PCEMP message MAY include a PCE SUBOBJECT to inform the
responder (PCE2) about the initiator's (PCE1)
PCEMP-LOCAL-INITIATOR-ADDRESS. In this way PCE2 is initialized
with the soft-memory based computation for PCEMP FSMs.
(2): PCE2 receives this message and is configured with the soft-memory
based path computation states. It sends back an ACK message to
PCE1 with the responder's (PCE2) PCEMP-LOCAL-RESPONDER-ADDRESS
(3): PCE1 sends a PCEMP Common Header with the ESTABLISH_PATH enabled
in the PCEMode field, the Discovery mode set in the PCEStatus
field of the Common Header and a field to indicate IPv6
addressing scheme in the PCEObject of the Common Header. It also
sends a PCEMP ESTABLISH message with the following parameters:
1. Flag field set to VARIABLE. The MAX_PCE_TIME_FIT is to be
Choi, Guha Informational [Page 6]
Internet Draft draft-choi-pcemp-ipv6-05.txt August 2006
negotiated as discussed in [2]. In case this is not able to
be negotiated, then the PCEMP ERROR message SHOULD be
generated with the ERROR CODE field set to OUT OF TIME, and
the PCE1 node MUST issue a fresh PCEMP ESTABLISH message with
the Flag field set to STATIC.
2. In case of contention in the value of the MAX_PCE_TIME_FIT
during negotiation, the node ID with the higher value wins.
The other PCE node which has won contention must send a
fresh PCEMP ESTABLISH message with the Flag field set to
STATIC and its' own MAX_PCE_TIME_FIT value. It MUST also set
the ACK requested flag in the PCEFlag of the corresponding
outgoing PCEMP Common Header. The node which has lost
contention SHOULD send out an ACK message along with a
PCE SUBOBJECT with the MAX_PCE_TIME_FIT value obtained thus.
In certain cases, the node which loses contention might
send a PCEMP ERROR message with the PCEMP NEGOTIATE OBJECT
informing of its status of getting a higher node ID through
mobility. In such a case, when higher node ID is acquired,
a PCEMP RESPONSE message MUST be sent with the PCEMP
NEGOTIATE OBJECT in the message body.
(4): PCE2 sends a PCEMP RESPOND message with the corresponding PCE
Descriptor ID. This is matched and stored statically for the
lifetime of the path computation between PCE1-PCE2 so that this
ID remains static between them till the path computation is over.
If the PCE Descriptor ID changes value, a PCEMP ERROR message
MUST be generated with the ERROR CODE field set to PROTOCOL
ERROR with its own saved PCE Descriptor ID of the wronged hop
in the PCEMP NEGOTIATE OBJECT. It MUST also set the Protection
mode in the PCEStatus field of the corresponding outgoing
PCEMP Common Header.
(5): PCE1 issues a PCEMP TEARDOWN message with the RequestType field
set to CHANGE IN COMPUTATION STYLE for PCE2 to remain PCEMP
enabled and the path computation state active.
(6): PCE2 sends a PCEMP Common Header with the COMPUTE_PATH enabled
in the PCEMode field. The PCEMP message MAY include a PCE
SUBOBJECT to inform the responder (PCE1) about the initiator's
(PCE2) PCEMP-LOCAL-INITIATOR-ADDRESS.
4.4.1 Inter-domain point-to-multipoint considerations
The protocol implementations are followed as in the previous section,
except for a few modifications.
Before Step (3) as in 4.4, PCE1 needs to send a PCEMP Common Header
with the COMPUTE_LSP_TYPE set in the PCEMode and the Peer-to-peer
mode set in the PCEStatus. This precedes Step (3) in 4.4. The
participating PCE peers thus get information that the path computation
session is a point-to-multipoint one. The paths may even be aggregated
for multipoint-to-multipoint TE LSP path computation in inter-domains.
Choi, Guha Informational [Page 7]
Internet Draft draft-choi-pcemp-ipv6-05.txt August 2006
In this mode of operation, Step (6) in 4.4 is replaced with the PCE2
(or PCEn, in the more general case) sending a PCEMP Common Header
with the COMPUTE_LSP_TYPE enabled in the PCEMode field.
Details of inter-domain operations TBD.
5. Security Considerations
The impact of the use of the PCEMP architecture is relatively much
secure as the PCEDA are computed and distributed internal to the
PCE unit. An increase in inter-domain information flows and the
facilitation of inter-domain path establishment through PCEMP does
not increase the existing vulnerability to security attacks. It
should be remembered that PCEMP works by an invoked logic scheme
local to each participating PCE unit, and the protocol scheme is
brought into play only when there is a significant change in the
data profile within the time of goodness of fit.
The corresponding upper bound
max tags (MAX_PCE_TIME_FIT) / MAX_PCE_TIME_FIT may be a useful
metric to limit the advertisement's response rate.
However, it is expected that the PCE solutions will address
security issues mentioned in [Ash] in details using authentication
and security techniques.
6. IANA Considerations
This document makes no requests for IANA action.
7. Acknowledgements
This work was supported by the BcN ITRC, Ministry of Information
and Communications (MIC), Republic of Korea
8. Intellectual Property Considerations
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.
Choi, Guha Informational [Page 8]
Internet Draft draft-choi-pcemp-ipv6-05.txt August 2006
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
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.
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004.
[RFC3668] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
10. Informational References
[1] [RFC2461] Narten, T., Nordmark, E., and Simpson, W., "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December, 1998.
[2] Choi, J.K., and Guha, D., "Path Computation Element Metric
Protocol (PCEMP)", draft-choi-pce-metric-protocol-05.txt, August
2006 (work in progress)
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell and J.
McManus, "Requirements for Traffic Engineering over MPLS", RFC 2702,
September 1999.
[RFC3209] Awduche, D., et. al., "Extensions to RSVP for LSP Tunnels",
RFC 3209, December 2001.
[RFC3473] Berger, L., et. al., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[INTER-AREA] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements for
Support of Inter-Area and Inter-AS MPLS Traffic Engineering",
draft-ietf-tewg- interarea-mpls-te-req-00.txt, March 2004 (work in
progress).
[INTER-AS] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic
Engineering requirements", draft-ietf-tewg-interas-mpls-te-req-06.txt,
January 2004 (work in progress).
Choi, Guha Informational [Page 9]
Internet Draft draft-choi-pcemp-ipv6-05.txt August 2006
[MRN] Papadimitriou, D., et. al., "Generalized MPLS Architecture for
Multi-Region Networks,"draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt,
February 2004 (work in progress).
Le Roux, J.L., Ed., "Requirements for Path Computation Element (PCE)
Discovery", draft-ietf-pce-discovery-reqs-05.txt, June 2006
Ash, J., and Le Roux, J.L., Ed., "PCE Communication Protocol Generic
Requirements", draft-ietf-pce-comm-protocol-gen-reqs-07.txt, June
2006
11. Authors' Addresses
Jun Kyun Choi
BcN Engineering Research Center
103-6 Munji-Dong, Yuseong-gu, Daejeon, 305-732, Republic of Korea
Phone: +82-42-866-6122
Email: jkchoi@icu.ac.kr
Dipnarayan Guha
Nanyang Technological University, Singapore
Email: dg236@cornell.edu
12. Full Copyright Statement
Copyright (C) The Internet Society (2006). All Rights Reserved.
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.
This document and translations of it MAY be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation MAY be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself MAY not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process MUST be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
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.
Choi, Guha Informational [Page 10]
Internet Draft draft-choi-pcemp-ipv6-05.txt August 2006
