Internet DRAFT - draft-shyam-rt-inside-vlsm-tree
draft-shyam-rt-inside-vlsm-tree
INTERNET DRAFT S. Bandyopadhyay
draft-shyam-rt-inside-vlsm-tree-01.txt July 1, 2018
Intended status: Proposed Standard
Expires: January 1, 2019
Setting Default Route Inside VLSM Tree
draft-shyam-rt-inside-vlsm-tree-01.txt
Abstract
This document shows how to set default route inside VLSM tree. With
this approach routing information of the external world need not be
passed down to the VLSM tree. It shows how RSVP-TE is extended to
support IP-VPN with MPLS to support default route inside VLSM tree.
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 January 1, 2019.
Copyright Notice
Copyright (c) 2018 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.
Bandyopadhyay Expires January 1, 2019 [Page 1]
Internet Draft Real IP Framework July 1, 2018
1. Introduction
Inside a VLSM tree of provider assigned address space, traditionally
BGP [1] is used to provide routing and to support VPN services [2].
This document shows how routing is achieved inside a VLSM tree by
setting default route instead of using BGP. With this approach
routing information of the external world need not be passed down to
the VLSM tree. Thus load inside a router gets reduced substantially.
This document shows how RSVP-TE is extended to support IP-VPN with
MPLS by setting default route inside a VLSM tree. Inside a customer
network, if address space is distributed in the form of a VLSM tree,
same approach can be applied in place of using a traditional routing
algorithm.
2. Setting default route inside VLSM tree
Inside a VLSM tree, a node of higher prefix can be divided into
number of nodes with lower prefixes. Each divided node can further be
subdivided with nodes of further lower prefixes. This process can be
continued as long as it is desired or no more division is further
possible.
+--------------+
| SW-A |
| 11.1.16.0/20 |
+-+-+------+-+-+
| | | |
+---------------+ | | +----------------+
| | | |
+------+-----+ +---------+--+ +-+----------+ +-----+------+
| SW-B | | SW-C | | SW-D | | SW-E |
|11.1.16.0/21| |11.1.24.0/22| |11.1.28.0/23| |11.1.30.0/23|
+---+----+---+ +------------+ +------------+ +--+---------+
| | |
| +-------+ |
| | +--+--+
+-------+----+ +----+-------+ |CN-D |
| SW-F | | SW-G | +-----+
|11.1.16.0/22| |11.1.20.0/22| 11.1.30.0/24
+--+---------+ +--+------+--+
| | |
| | |
+--+--+ +--+--+ +-+---+
|CN-A | |CN-B | |CN-C |
+-----+ +-----+ +-----+
11.1.16.0/24 11.1.20.0/24 11.1.21.0/24
Bandyopadhyay Expires January 1, 2019 [Page 2]
Internet Draft Real IP Framework July 1, 2018
Figure above shows a typical arrangement of VLSM tree of a service
provider's network with IPv4 address space. Switch SW-A is connected
to the outside world and maintains global routing table. It acts as
the root of a VLSM tree that acts as a stub. It has been assigned an
address block 11.1.16.0/20 which is distributed among its four
children SW-B, SW-C, SW-D and SW-E with the approach of VLSM. Switch
SW-B further divides its address space between switches SW-F and SW-
G. Switch SW-F assigns an address block 11.1.16.0/24 to customer
network CN-A. Switch SW-G assigns address block 11.1.20.0/24 and
11.1.21.0/24 to two customers CN-B and CN-C; where as switch SW-E
assigns address block 11.1.30.0/24 to customer network CN-D.
Routing inside the tree takes place with the following principle.
Inside the tree, if a node (switch/router) that is assigned a domain
(NetAddr/NetMask) receives a packet which is destined to somewhere
outside of its domain, needs to forward the packet to its parent in
the hierarchy.
If a host in CN-A wants to send a packet to an address 11.1.21.116,
CE router of CN-A forwards it to SW-F. SW-F finds the destination
address of the packet to be outside of its domain and forwards the
packet to its parent SW-B. SW-B finds that a port that has been
configured with the matching destination address and forwards it to
its child SW-G. Switch SW-G sends the packet to customer network CN-
B.
If a host in CN-B wants to send a packet to 11.1.17.120, CE router of
CN-B forwards the packet to SW-G. SW-G finds the destination address
of the packet to be outside of its domain and forwards the packet to
its parent SW-B. SW-B finds that a port that has been configured with
the matching destination address and forwards the packet to its child
SW-F. SW-F finds the destination address to be within its domain, but
no port has been configured with the matching destination address and
generates ICMP UNREACHABLE.
If a host in CN-C wants to send a packet to 16.2.22.116, CE router of
CN-C forwards the packet to SW-G. SW-G finds the destination address
of the packet to be outside its domain and forwards the packet to SW-
B. SW-B forwards the packet to its parent SW-A. SW-A find the
destination address of the packet to be outside its domain and
consults with the global forwarding table and forwards the packet
through the right port.
Section 2.5.4. of RFC 4291[3] defines the format of global unicast
addresses in IPv6 in the following manner:
Bandyopadhyay Expires January 1, 2019 [Page 3]
Internet Draft Real IP Framework July 1, 2018
| n bits | m bits | 128-n-m bits |
+------------------------+-----------+----------------------------+
| global routing prefix | subnet ID | interface ID |
+------------------------+-----------+----------------------------+
Inside a provider network in IPv6 environment, only the "global
routing prefix" portion has to be considered for setting up default
route. Inside a customer network in IPv6 environment, if VLSM tree is
used for distribution of address space, "global routing prefix" +
"subnet ID" portion has to be considered for setting up default
route.
If a new specification of IP is designed (say,with 64 bit address
space) where customer networks are assigned address space based on
their size (need), entire part of the address has to be considered
for setting up VLSM tree (the way it works with IPv4).
3. IP VPN with MPLS inside VLSM tree
Section 2 describes that there is no need to pass down the routing
information of the external world inside VLSM tree. This section
describes how to make IP VPN work inside VLSM tree without using BGP.
RFC4364 [2] describes "IP VPN" with BGP/MPLS. To support VPN, PE
routers maintain per-site forwarding table. When a packet arrives
from an associated CE router, PE router consults with this forwarding
table to forward the packet. If the packet is supposed to be
forwarded to another site of VPN through the backbone, it uses two-
level label stack. The upper label is used to forward the packet from
ingress PE router to the egress PE router; where as, the inner label
is used for the egress PE router to identify the associated CE router
where the packet is supposed to be forwarded. BGP is used by the
Service Provider to exchange the routes of a particular VPN among the
PE routers that are attached to that VPN. Configuration takes place
on PE routers of both the sides of LSP. The simplest way to achieve
this is to configure these attributes manually on PE routers. In
order to have dynamic allocation of inner label, MPLS signaling
protocols (in place of BGP) need to be extended. Allocation of inner
label has to be done by the egress PE router. Same message that is
used for the assignment of upper label may be used for the assignment
of inner label. Inside the forwarding table, each entry contains the
forwarding destination address based on a set of destination
addresses (NetAddress/NetMask) of the IP packets received from
ingress CE router. While establishing inner label, ingress PE router
needs to send these attributes with the signaling message and the
egress PE router needs to validate those before assigning label.
Bandyopadhyay Expires January 1, 2019 [Page 4]
Internet Draft Real IP Framework July 1, 2018
3.1. Extension to RSVP-TE to support IP VPN inside VLSM tree
This section describes extension to RSVP-TE[4] to support dynamic
allocation of inner label of two-level label stack used to support
VPN services.
In order to establish LSP using RSVP-TE, ingress PE router sends Path
message to the egress PE router. Path message is augmented with a
LABEL_REQUEST object. Labels are allocated downstream and
distributed (propagated upstream) by means of RSVP Resv message. For
this purpose, the RSVP Resv message is extended with a special LABEL
object. In order to support VPN to establish the inner label, Path
message is augmented with a VPN_ATTRIBUTE label. Similarly, RSVP Resv
message is extended with a VPN_LABEL object. When an egress PE router
receives a Path message, it checks the presence of VPN_ATTRIBUTE
object. On finding this object, egress PE router checks the viability
of assignment of VPN label with the parameters from the VPN_ATTRIBUTE
object and the attributes that are already configured with the egress
PE router. If the test is positive, it assigns a VPN label and does
the rest of the processing of LSP label assignment and sends the RSVP
Resv message with the extension of VPN_LABEL object towards the
ingress PE router. On receiving Resv message with VPN_LABEL object,
ingress PE router assigns VPN label along with the rest of the
processing of Resv message and completes the operation. VPN_ATTRIBUTE
and VPN_LABEL objects are described below.
VPN_LABEL class=<TBD1>, C-Type=1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (inner label) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VPN_ATTRIBUTE class=<TBD2>, C-Type=1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Unicast Address of Ingress CE Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Unicast Address of Egress CE Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Net Address of Destination IP Packet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Net Mask of Destination IP Packet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Path message is as follows:
Bandyopadhyay Expires January 1, 2019 [Page 5]
Internet Draft Real IP Framework July 1, 2018
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <VPN_ATTRIBUTE> ]
[ <SESSION_ATTRIBUTE> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
The format of the Resv message is as follows:
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <POLICY_DATA> ... ]
[ <VPN_LABEL> ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor>
<FF flow descriptor list> ::= <FLOWSPEC> <FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ]
| <FF flow descriptor list>
<FF flow descriptor>
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ]
<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
<SE filter spec list> ::= <SE filter spec>
| <SE filter spec list> <SE filter spec>
<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
Egress router generates an error with Error Code = 24, sub-code =
<TBD3> (VPN label allocation error) if the operation fails.
Bandyopadhyay Expires January 1, 2019 [Page 6]
Internet Draft Real IP Framework July 1, 2018
4. IANA Consideration
IANA has assigned RSVP class number <TBD1> for the object VPN_LABEL
and RSVP class number <TBD2> for VPN_ATTRIBUTE. IANA has also
assigned an error sub-code <TBD3> for VPN label allocation error
under Error Code = 24.
5. Security Consideration
This document does not include any security related issues.
6. Normative References
[1] Rekhter, Y., and T., Li, "A Border Gateway Protocol 4 (BGP-
4)",RFC 1771, March 1995.
[2] E. Rosen, Y. Rekhter, "BGP/MPLS IP Virtual Private Networks
(VPNs)", RFC 4364, February 2006.
[3] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture",
RFC 4291, February 2006.
[4] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow,
"RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209,
December 2001.
7. Author's Address
Shyamaprasad Bandyopadhyay
HL No 205/157/7, Kharagpur 721305, India
Phone: +91 3222 225137
e-mail: shyamb66@gmail.com
Bandyopadhyay Expires January 1, 2019 [Page 7]
