< draft-shyam-real-ip-framework-58.txt   draft-shyam-real-ip-framework-59.txt >
INTERNET DRAFT S. Bandyopadhyay INTERNET DRAFT S. Bandyopadhyay
draft-shyam-real-ip-framework-58.txt June 26, 2019 draft-shyam-real-ip-framework-59.txt June 28, 2019
Intended status: Experimental Intended status: Experimental
Expires: December 26, 2019 Expires: December 28, 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-58.txt draft-shyam-real-ip-framework-59.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 26, 2019. This Internet-Draft will expire on December 28, 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 16, line 5 skipping to change at page 16, line 5
getting "Delete Node" message, root deletes the entire sub-tree under getting "Delete Node" message, root deletes the entire sub-tree under
that node in the tree. Whenever a link goes down, "Link Down" message that node in the tree. Whenever a link goes down, "Link Down" message
gets propagated to the root. On receiving "Link Down" message, root gets propagated to the root. On receiving "Link Down" message, root
marks the link status as not active. Whenever a link comes up, on marks the link status as not active. Whenever a link comes up, on
receiving "Link Up" message, root builds the subtree under the node receiving "Link Up" message, root builds the subtree under the node
whose link was down (if it happens to be a router) and sets the whose link was down (if it happens to be a router) and sets the
status of the link as active. This is to get the up-to-date status of status of the link as active. This is to get the up-to-date status of
the subtree whose link went down. Root calls "GetSubtree" routine the subtree whose link went down. Root calls "GetSubtree" routine
recursively to build the subtree as follows: recursively to build the subtree as follows:
void GetSubtree(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). for all the children as a router call GetSubtree(&childNode[i]).
}
Where TreeNode may be defined as:
struct TreeNode{
uint32 nodeId; /* RouterId, 32 bits in IPv4 */
uint16 nodeType /* Customer Network (1)/Router(2) */
uint16 noOfChildren; /* Number of children */
struct TreeNode *childNode;
struct TreeNode *parent;
} }
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 17, line 6 skipping to change at page 17, line 16
Type Type
The message types are as follows. The message types are as follows.
Type Description Type Description
________________________________ ________________________________
1 Hello 1 Hello
2 Add Node 2 Add Node
3 Delete Node 3 Delete Node
4 Link Down 4 Link Down
5 Link Up 5 Link Up
6 Get Subtree 6 Get Child Nodes
7 Acknowledgment 7 Acknowledgment
Packet length Packet length
The length of the protocol packet in bytes. This length The length of the protocol packet in bytes. This length
includes the standard header. includes the standard header.
Router ID Router ID
The Router ID of the packet's source. The Router ID of the packet's source.
Area ID Area ID
skipping to change at page 18, line 30 skipping to change at page 18, line 42
| Authentication | | Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication | | Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Type | Sequence Number | | Node Type | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node ID | | Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Node Type Node Type
Node type is Customer Network (1)/Router (2)/Root of a Subtree(3) Node type is Customer Network (1)/Router (2)
A Node can be a Customer Network or a Router or the Root of a
Subtree. Root of a Subtree acts like a Customer Network. Under
a large tree, a router can act as the root of a Subtree
which hides the topology underneath. So, root of a Subtree needs
to be contacted to get the details underneath.
Sequence Number Sequence Number
Whenever a router generates an Add Node message it uses a Sequence Whenever a router generates an Add Node message it uses a Sequence
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.
skipping to change at page 19, line 33 skipping to change at page 19, line 39
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:
Router ID of the router (32 bits in IPv4) Router ID of the router (32 bits in IPv4) +
Number of children of the router (16 bits) + Number of children of the router (16 bits) +
for each child of the router { for each child of the router {
Add Type of the child (Customer Network/Router) (16 bits) + Type of the child (Customer Network/Router) (16 bits) +
Add Router ID of the child (32 bits in IPv4) Router ID of the child (32 bits in IPv4)
} }
Exchange of router information is just same as the operation of Exchange of router information is just same as the operation of
"Database Description" packet of OSPF (See section A.3.3 of [19]). "Database Description" packet of OSPF (See section A.3.3 of [19]).
Format of "Get Child Nodes" packet is same as "Database Description" Format of "Get Child Nodes" packet is same as "Database Description"
packet of OSPF with the "Type" field set as 6. packet of OSPF with the "Type" field set as 6.
4.3.1.7. The Acknowledgment packet 4.3.1.7. The Acknowledgment packet
An "Acknowledgment" packet is sent to acknowledge that an "Add An "Acknowledgment" packet is sent to acknowledge that an "Add
Node"/"Delete Node"/"Link Up"/"Link Down" message has been received Node"/"Delete Node"/"Link Up"/"Link Down" message has been received
to the sender. All the fields of an "Acknowledgment" packet are same to the sender. All the fields of an "Acknowledgment" packet are same
as an "Add Node" packet apart from the Type(7) field. as an "Add Node" packet apart from the Type(7) field.
4.4. IP VPN with MPLS inside VLSM tree 4.4. IP VPN with MPLS inside VLSM tree
This section describes how to make IP VPN work inside VLSM tree This section describes how to make IP VPN work inside VLSM tree
without using BGP. without using BGP.
skipping to change at page 41, line 30 skipping to change at page 41, line 30
[5] Srisuresh, P. and K. Egevang, "Traditional IP Network Address [5] Srisuresh, P. and K. Egevang, "Traditional IP Network Address
Translator (Traditional NAT)", RFC 3022, January 2001. Translator (Traditional NAT)", RFC 3022, January 2001.
[6] J. Moy., "OSPF Standardization Report", RFC 2329, April 1998 [6] J. Moy., "OSPF Standardization Report", RFC 2329, April 1998
[7] E. Rosen, Y. Rekhter, "BGP/MPLS IP Virtual Private Networks [7] E. Rosen, Y. Rekhter, "BGP/MPLS IP Virtual Private Networks
(VPNs)", RFC 4364, February 2006. (VPNs)", RFC 4364, February 2006.
[8] S. Bandyopadhyay, "Solution for Site Multihoming in a Real IP [8] S. Bandyopadhyay, "Solution for Site Multihoming in a Real IP
Environment", <draft-shyam-site-multi-44> work in progress. Environment", <draft-shyam-site-multi-43> work in progress.
[9] C. Perkins, Ed., D. Johnson, J. Arkko, "Mobility Support in [9] C. Perkins, Ed., D. Johnson, J. Arkko, "Mobility Support in
IPv6" RFC 6275, July 2011. IPv6" RFC 6275, July 2011.
[10] P.V. Mockapetris., "Domain names - concepts and facilities", [10] P.V. Mockapetris., "Domain names - concepts and facilities",
RFC 1034, November 1987. RFC 1034, November 1987.
[11] P.V. Mockapetris, "Domain names - implementation and [11] P.V. Mockapetris, "Domain names - implementation and
specification", RFC 1035, November 1987. specification", RFC 1035, November 1987.
 End of changes. 12 change blocks. 
19 lines changed or deleted 22 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/