RTGWG WG Ting. Liao
Internet-Draft Ting. Ao
Intended status: Standards Track ZTE Corporation
Expires: June 26, 2016 December 24, 2015
RTGWG PathID Engineering
draft-lt-rtgwg-pathid-engineering-00.txt
Abstract
With the deployment of centralized control, the traffic scheduling
can be easier to accomplish with PathID carried in the data plane. A
PathID used to indicate a flow through a forwarding path which is not
the default shortest path. It is encapsulated in the packet at the
ingress node, carried to indicate the forwarding at the transit node
and decapsulated at the egress node.
This document describes how to accomplish flexible forwarding with
PathID in traffic scheduling.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on June 26, 2016.
Copyright Notice
Copyright (c) 2015 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
Liao & Ao Expires June 26, 2016 [Page 1]
Internet-Draft RTGWG PathID Engineering December 2015
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Abbreviations . . . . . . . . . . . . . . . . 3
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3
4. Control plane . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Data plane . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. A new type of Ether Header . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
By the deployment of centralized control, the traffic scheduling is
becoming more and more important. Combining with the centralized
control and the provision of dynamic route learning in current
device, we propose a method using PathID to indicate how to schedule
the traffic. With this method, the controller under pure SDN is not
required to sent update forwarding message to every forwarding device
frequently, so that reduce the complexity of the controller, and make
the scheduling be easier.
This draft proposes a method by identifying a pathID to a specified
path, and carrying the pathID in the header of frames and forwarding
the frames along the specified path. The PathID is an ID used to
identify a Path which needs to be explicitly specified when frames
transit from source to destination. It means when the frames are not
transit on the default shortest path ( such as calculated by SPF OR
CSPF algorithm ), the non-default path specified by the operator or
controller is identified by a pathID.
The pathID is encapsulated in the packet at the ingress node, carried
to indicate the forwarding at the transit node and decapsulated at
the egress node. To get it, PathID status also needs to be
maintained in the intermediate forwarding node. But when the
application changes the path, the controller needs to re-calculate a
new dedicated path, and assign the old PID or a new PID to this path,
and send the mapping information of the PID and the path to all the
nodes on the new path. Every node needs to update or generate the
forwarding entry according to the mapping information received.
Liao & Ao Expires June 26, 2016 [Page 2]
Internet-Draft RTGWG PathID Engineering December 2015
With this method, the controller needn't control all the nodes for
their forwarding entry separately, but only needs to send the same
mapping information to all the nodes.
2. Conventions and Abbreviations
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] .
The following notations and abbreviations are used throughout this
draft.
PID: Path Identifier, a specified path or a non-default path is
identified by a Path ID (PID). The PID may be an unused label or an
unused ipv4 address or an unused ipv6 address. If the forwarding
table for PID is an isolated table, the PID could be any length
value, no matter it is used or not.
3. Solution Overview
In this document, we define the Path Identifier (PID) and a new type
of Ether Header. The path calculating and traffic scheduling are all
managed by a centralized node(controller).
1. Controller calculates a best dedicated path (non-default path)
that meets all the requirements according to the application, and
assign a PID to the corresponding path. Controller take the
responsibility of the management,assignment, distribution and relaim
of the PID.
2. Controller sends the mapping information between PID and the
dedicated path to all the nodes on the path.
3. The node receives the mapping information and generates the
forwarding entry.
4. The ingress node needs to encapsulate the traffic with PID so
that the traffic can be forwarded alone the dedicate path and then
the egress node will de-capsulate the traffic.
4. Control plane
In the deployment of centralized control scenario, the controller
obtains the topology of the network. And the controller calculates
different specified path based on different service requirement as
policy control needed. Then the controller allocates an PID for a
non-default path and sends the mapping message of the PID and all the
Liao & Ao Expires June 26, 2016 [Page 3]
Internet-Draft RTGWG PathID Engineering December 2015
addresses of nodes or links on this path to all the nodes on this
path. When the nodes receives the mapping message, it generates a
forwarding item of the PID, and in the item, the egress-interface and
nexthop of the PID is the egress-interface and nexthop of the next
hop of itself on this path of itself.
The details shown as in the figure 1.
__ +----------------------+
/ _ | Controller | __
/ / +----------------------+_ \
/ / | | | | | \ \ \
/ / | | | | | \ \ \
+---+ / +---+ | | +---+ | +---+ \ \+---+
-------- |R1 |---/---|R3 |--|---|--|R5 |---|-|R7 |---\-- |R9 |
+---+ / +---+ | | +---+ | +---+ \ +---+
| / | / \ | \ | \ |
| / | / \ | \ | \ |
+---+ +---+ +---+ +---+ +---+
|R2 |-------|R4 |--------|R6 |-----|R8 |-------|R10|-----------
+---+ +---+ +---+ +---+ +---+
Figure 1 Scenario 1
o The controller has the topology as figure 1 shown.
o The controller calculates a path from R1 to R10 that must forward
step to step as {R1, R2, R4, R3, R5, R6, R8, R7, R9, and R10} .
o The controller allocates an unused PID 10010(an unused label for
example) to identify the path {R1, R2, R4, R3, R5, R6, R8, R7, R9,
and R10}.
o The controller sends the mapping message about (PID) 10010 to the
path {R1, R2, R4, R3, R5, R6, R8, R7, R9, and R10(the loopback
address may used to identify the nodes)} to all the nodes on the
path.
o Each node (R1-R10) receives the mapping message, generates a
forwarding item of the PID. Take R4 for example, R4 learns the
mapping message, and it knows the next hop of itself on this path is
R3, then it looks up the forwarding table, and finds that the nexthop
and egress-interface to R3 is the link and adjacency to R3, so it
generates the next hop and egress-interface to the PID is the link
and adjacency to R3.
Liao & Ao Expires June 26, 2016 [Page 4]
Internet-Draft RTGWG PathID Engineering December 2015
5. Data plane
A flow needs to transit on this path with the PID encapsulated in the
header. When the forwarding table about PID is a new table, the PID
header could be a new type of Ether Header. When PID is a label or a
IPv4 addres or IPv6 address that is compatible to the existing
encapsulation, the PID must be a new global label or IP address. If
it is a 20 bits lebal, the PID can also be encapsulated at the outer
layer of the label layer. If it is an IP address, the ingress node
and egress node could take a mapping action, that is on the ingress
node, mapping the destination address to PID, and on the egress node,
mapping the PID to destination address.
5.1. A new type of Ether Header
A new type( TBD,to be assigned by IANA) of Ether Headers is shown in
the figure 2 for example. The ingress node could encapsulate frames
with PID carried.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | Len |NHeader| ENTROPY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID (veriable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 A new type of Ether Header
o TYPE: 4-bit. To identify the PID type is a label or an ipv4
addresses or an ipv6 addresses or other.
o NHeader: 4-bit. Identifies the type of payload immediately
following the PID Header. The field may take any of the following
values:
1: MPLS packet with downstream-assigned label at top of stack. 2:
MPLS packet with upstream-assigned label at top of stack (see
[RFC5331]). If this value of the Proto field is used, the I bit MUST
be set, and the BFR-id of the BFIR must be placed in the BFIR-id
field. The BFIR-id provides the "context" in which the upstream-
assigned label is interpreted. 3: Ethernet frame. 4: IPv4 packet.
6: IPv6 packet.
o Len: 4-bit unsigned integer, is the length of the PID header in
8-octet units, not including the first 4 octets.
Liao & Ao Expires June 26, 2016 [Page 5]
Internet-Draft RTGWG PathID Engineering December 2015
o ENTROPY: This 20-bit field specifies an "entropy" value that can be
used for load balancing purposes. The BIER forwarding process may do
equal cost load balancing, but the load balancing procedure MUST
choose the same path for any two packets have the same entropy value
o PID: The PID assigned to the path, it could be a label or an ipv4
addresses or an ipv6 addresses or other length to identify the path.
If the forwarding table for pathID is an isolated table, the pathID
could be any length value, no matter it is used or not.
6. Security Considerations
TBD.
7. Acknowledgements
In progress.
8. IANA Considerations
TBD.
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
Authors' Addresses
Ting Liao
ZTE Corporation
No.50 Software Avenue
Nanjing, Jiangsu 210012
China
Phone: +86 25 88016576
Email: liao.ting@zte.com.cn
Liao & Ao Expires June 26, 2016 [Page 6]
Internet-Draft RTGWG PathID Engineering December 2015
Ting Ao
ZTE Corporation
No.889 Bibo Rd
Shanghai 201203
China
Phone: +86 21 68897642
Email: ao.ting@zte.com.cn
Liao & Ao Expires June 26, 2016 [Page 7]