< draft-shyam-real-ip-framework-59.txt   draft-shyam-real-ip-framework-60.txt >
INTERNET DRAFT S. Bandyopadhyay INTERNET DRAFT S. Bandyopadhyay
draft-shyam-real-ip-framework-59.txt June 28, 2019 draft-shyam-real-ip-framework-60.txt July 03, 2019
Intended status: Experimental Intended status: Experimental
Expires: December 28, 2019 Expires: January 03, 2019
An Architectural Framework of the Internet for the Real IP World An Architectural Framework of the Internet for the Real IP World
draft-shyam-real-ip-framework-59.txt draft-shyam-real-ip-framework-60.txt
Abstract Abstract
This document tries to propose an architectural framework of the This document tries to propose an architectural framework of the
internet in the real IP world. It describes how a three-tier mesh internet in the real IP world. It describes how a three-tier mesh
structured hierarchy can be established in a large address space structured hierarchy can be established in a large address space
based on fragmenting it into some regions and some sub regions inside based on fragmenting it into some regions and some sub regions inside
each of them. It shows how to make a transition from private IP to each of them. It shows how to make a transition from private IP to
real IP without making significant changes with the existing network. real IP without making significant changes with the existing network.
It introduces VLSM tree routing protocol. It introduces another It introduces VLSM tree routing protocol. It introduces another
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 28, 2019. This Internet-Draft will expire on January 03, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
3.2.1. A pseudo optimal distribution of prefixes in 3.2.1. A pseudo optimal distribution of prefixes in
a 64 bit architecture................................9 a 64 bit architecture................................9
3.2.2. Whether to go for a two tier or three tier hierarchy 3.2.2. Whether to go for a two tier or three tier hierarchy
....................................................11 ....................................................11
3.3. Issues related to Satellite communications.................12 3.3. Issues related to Satellite communications.................12
4. VLSM tree routing protocol......................................12 4. VLSM tree routing protocol......................................12
4.1. Setting default route inside VLSM tree.....................12 4.1. Setting default route inside VLSM tree.....................12
4.2. Router address space.......................................14 4.2. Router address space.......................................14
4.3. Network management and support of explicit route option....15 4.3. Network management and support of explicit route option....15
4.3.1. VLSM tree routing protocol messages.................16 4.3.1. VLSM tree routing protocol messages.................16
4.3.1.1. The Hello packet...........................17 4.3.1.1. The Hello packet...........................18
4.3.1.2. The Add Node packet........................17 4.3.1.2. The Add Node packet........................18
4.3.1.3. The Delete Node packet.....................18 4.3.1.3. The Delete Node packet.....................19
4.3.1.4. The Link Down packet.......................19 4.3.1.4. The Link Down packet.......................19
4.3.1.5. The Link Up packet.........................19 4.3.1.5. The Link Up packet.........................19
4.3.1.6. The Get Child Nodes packet.................19 4.3.1.6. The Get Child Nodes packet.................19
4.3.1.7. The Acknowledgment packet..................19 4.3.1.7. The Acknowledgment packet..................19
4.4. IP VPN with MPLS inside VLSM tree..........................20 4.4. IP VPN with MPLS inside VLSM tree..........................20
4.4.1. Extension to RSVP-TE to support IP VPN inside VLSM 4.4.1. Extension to RSVP-TE to support IP VPN inside VLSM
tree................................................20 tree................................................20
5. Provider Independent addressing, name services and multihoming..22 5. Provider Independent addressing, name services and multihoming..22
5.1. PI address Resolution......................................24 5.1. PI address Resolution......................................24
5.1.1. Record Format.......................................27 5.1.1. Record Format.......................................27
skipping to change at page 15, line 36 skipping to change at page 15, line 36
management by means of pooling and generation of trap on network management by means of pooling and generation of trap on network
failure. This section shows how it is done with the approach of failure. This section shows how it is done with the approach of
routing protocol. It adopts "Hello protocol" and authentication routing protocol. It adopts "Hello protocol" and authentication
mechanism of OSPF protocol leaving behind the SPF part and mechanism of OSPF protocol leaving behind the SPF part and
introducing new message types relevant to VLSM tree. introducing new message types relevant to VLSM tree.
The router at the root constructs the tree the way it appears in the The router at the root constructs the tree the way it appears in the
figure above. Every router in the tree is configured with the router- figure above. Every router in the tree is configured with the router-
id of the root i.e. the domain of the tree it belongs to. Whenever a id of the root i.e. the domain of the tree it belongs to. Whenever a
router adds a node (it may be a customer network or another router) router adds a node (it may be a customer network or another router)
as a child, it sends an "Add Node" message. The message gets as a child, it sends an "Add Node" message. The message is sent to
propagated to the root. On getting an "Add Node" message, root traces the root. On getting an "Add Node" message, root traces the tree and
the tree and identifies the node with "Router ID" as specified in the identifies the node with "Router ID" as specified in the message and
message and adds a node underneath. Similarly, whenever a node gets adds a node underneath. Similarly, whenever a node gets deleted, a
deleted, "Delete Node" message gets propagated to the root. On "Delete Node" message is sent to the root. On getting "Delete Node"
getting "Delete Node" message, root deletes the entire sub-tree under message, root deletes the entire sub-tree under that node in the
that node in the tree. Whenever a link goes down, "Link Down" message tree. Whenever a link goes down, a "Link Down" message is sent to the
gets propagated to the root. On receiving "Link Down" message, root root. On receiving "Link Down" message, root marks the link status as
marks the link status as not active. Whenever a link comes up, on not active. Whenever a link comes up, on receiving "Link Up" message,
receiving "Link Up" message, root builds the subtree under the node root builds the subtree under the node whose link was down (if it
whose link was down (if it happens to be a router) and sets the happens to be a router) and sets the status of the link as active.
status of the link as active. This is to get the up-to-date status of This is to get the up-to-date status of the subtree whose link went
the subtree whose link went down. Root calls "GetSubtree" routine down. Root calls "GetSubtree" routine recursively to build the
recursively to build the subtree as follows: subtree as follows:
void GetSubtree(struct TreeNode *node) void GetSubtree(struct TreeNode *node)
{ {
send "Get Child Nodes" message to the router designated by node. send "Get Child Nodes" message to the router designated by node.
for all the children under "node" construct a TreeNode underneath. for all the children under node, construct a TreeNode underneath.
for all the children as a router call GetSubtree(&childNode[i]). for all the children as a router call GetSubtree(&childNode).
} }
Where TreeNode may be defined as: Where TreeNode may be defined as:
struct TreeNode{ struct TreeNode{
uint32 nodeId; /* RouterId, 32 bits in IPv4 */ uint32 nodeId; /* RouterId, 32 bits in IPv4 */
uint16 nodeType /* Customer Network (1)/Router(2) */ uint16 nodeType /* Customer Network (1)/Router(2) */
uint16 noOfChildren; /* Number of children */ uint16 noOfChildren; /* Number of children */
struct TreeNode *childNode; struct TreeNode *parent; /* pointer to the parent */
struct TreeNode *parent; struct TreeNode *childList; /* List of child nodes */
struct TreeNode *nextSibling; /* Next sibling in childList */
uint16 linkStatus; /* Link status with parent UP(1)/Down(2) */
} }
Root can also call "GetSubtree" routine for all of its child to build Root can also call "GetSubtree" routine for all of its child to build
the entire tree at the time of transition from old protocol to new or the entire tree at the time of transition from old protocol to new or
whenever required. whenever required.
4.3.1. VLSM tree routing protocol messages 4.3.1. VLSM tree routing protocol messages
It maintains same message format of OSPF protocol such that existing It maintains same message format of OSPF protocol such that existing
source code can be directly ported. This section describes new source code can be directly ported. This section describes new
skipping to change at page 19, line 8 skipping to change at page 19, line 8
Number. Usually it increments the Sequence Number on completion of Number. Usually it increments the Sequence Number on completion of
the transaction. the transaction.
Node ID Node ID
Node ID is the router ID of the domain associated with the Node ID is the router ID of the domain associated with the
router/customer network. router/customer network.
4.3.1.3. The Delete Node packet 4.3.1.3. The Delete Node packet
"Delete Node" message gets generated by a router when a child node "Delete Node" message gets generated by a router when a child node
gets deleted. The message gets transported to the root. On receiving gets deleted. The message is sent to the root. On receiving "Delete
"Delete Node" message, root deletes the node (i.e. the entire Node" message, root deletes the node (i.e. the entire subtree) under
subtree) under the node designated as "Node ID". All the fields of a the node designated as "Node ID". All the fields of a "Delete Node"
"Delete Node" packet are same as an "Add Node" packet apart from the packet are same as an "Add Node" packet apart from the Type(3) field.
Type(3) field.
4.3.1.4. The Link Down packet 4.3.1.4. The Link Down packet
"Link Down" message gets generated once a router failed to get "Link Down" message gets generated once a router fails to get "Hello"
"Hello" from any of its child and declares the link to be as from any of its child and declares the link to be as inactive. The
inactive. The message gets transported to the root. On receiving message is sent to the root. On receiving "Link Down" message root
"Link Down" message root marks the link in the tree to be inactive. marks the link in the tree to be inactive. All the fields of a "Link
All the fields of a "Link Down" packet are same as an "Add Node" Down" packet are same as an "Add Node" packet apart from the Type(4)
packet apart from the Type(4) field. field.
4.3.1.5. The Link Up packet 4.3.1.5. The Link Up packet
"Link Up" message gets generated once a router starts getting "Hello" "Link Up" message gets generated once a router starts getting "Hello"
messages from a child which was marked as inactive. The message gets messages from a child which was marked as inactive. The message is
transported to the root. On receiving "Link Up" message, root calls sent to the root. On receiving "Link Up" message, root calls
"GetSubtree" routine for the node as designated by "Node ID" (if it "GetSubtree" routine for the node as designated by "Node ID" (if it
happens to be a router). It updates changes in the subtree and marks happens to be a router). It updates changes in the subtree and marks
the link as active. All the fields of a "Link Up" packet are same as the link as active. All the fields of a "Link Up" packet are same as
an "Add Node" packet apart from the Type(5) field. an "Add Node" packet apart from the Type(5) field.
4.3.1.6. The Get Child Nodes packet 4.3.1.6. The Get Child Nodes packet
"Get Child Nodes" packet gets generated by root to get all the "Get Child Nodes" packet gets generated by root to get all the
children under a router. Contents of the router is expressed as children under a router. Contents of the router is expressed as
follows: follows:
 End of changes. 11 change blocks. 
38 lines changed or deleted 39 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/