IS-IS Extensions for Path
MTUHuaweiHuawei Bld., No.156 Beiqing Rd.Beijing100095Chinahuzhibo@huawei.comChina Telecom109, West Zhongshan Rd.Guangzhou510000Chinazhuyq@gsta.comHuaweiHuawei Bld., No.156 Beiqing Rd.Beijing100095Chinalizhenbin@huawei.comHuaweiHuawei Bld., No. 156 Beiqing Rd.Beijing100095Chinalarry.dai@huawei.comSegment routing (SR) leverages the source routing mechanism. It
allows for a flexible definition of end-to-end paths with IGP topologies
by encoding paths as sequences of topological sub-paths which is called
segments. These segments are advertised by the link-state routing
protocols (IS-IS and OSPF). Unlike the MPLS, SR does not have the
specific path construction signaling so that it cannot support the Path
MTU. This draft provides the necessary IS-IS extensions about the Path
MTU that need to be used on SR.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 RFC 2119.Segment routing (SR) leverages the source routing mechanism. SR
allows for a flexible definition of end-to-end paths within IGP
topologies by encoding paths as sequences of toplogical sub-paths which
is called segments. These segments are advertised by the link-state
routing protocols (IS-SI and OSPF). The SR architecture as well as the
routing policy is proposed in and . Two types of
segments are defined, Prefix segments and Adjacency segments. Prefix
segments represent an ecmp-aware shortest-path to a prefix, as per the
state of the IGP topology. Adjacency segments represent a hop over a
specific adjacency between two nodes in the IGP. A prefix segment is
typically a multi-hop path while an adjacency segment, in most of the
cases, is a one-hop path. SR can compute the paths from end to end and
without requiring any LDP or RSVP-TE signaling. SR supports per-flow
explict routing while just maintaining per-flow state only at the source
node.SR architecture supports the distributed scenario and the centralized
scenario. In the distributed scenario, the segments are allocated and
signaled by IGP or BGP and a node needs to compute the source-routed
policy. Some necessary IS-IS extensions for SR are proposed in . In a centralized
scenario, the SR controller decides which nodes need to steer which
packets on which source-routed policies. However, in both conditions,
the MTU is not included in the SR policy. As the SR may push more MPLS
labels or SRv6 SIDs in the packet header, the packets are larger than
the minimum MTU in the path compared to the traditional MPLS forwarding
process. Unfortunately the paths do not provide the path MTU informaiton
so that the path can not assure the packet size is less than the path
MTU, which is the minimum link MTU of all the links in a path between a
source node and a destination node. The definition of the path MTU is
discussed in RFC1981 .This draft describes the necessary IS-IS extensions about the path
MTU that need to be used on SR. A new TLV is introduced into the IS-IS
protocol. With the IGP flooding process in the distributed scenario or
transmission to the controller by BGP, the ingress nodes or the
controllers compute the Path MTU for the SR policy.router: a node that forwards IP packets not explicitly addressed to
itself.interface: a node's attachment to a link.Segment: an instruction a node executes on the incoming packet. For
example, froward packet according to shortest path to destination or a
specific interface, etc..SR Policy: an ordered list of segments.MTU: Maximum Transmission Unit, the size in bytes of the largest IP
packet, including the IP header and payload, that can be transmitted on
a link or path.link MTU: the maximum transimission unit, i.e., maximum packet size
in octets, that can be conveyed in one piece over a link.path: the set of links traversed by a packet between a source node
and a destination nodePath MTU: the minimum link MTU of all the links in a path between a
source node and a destination node.This document describes an IS-IS extension to flood the router
interface MTU to each node with the IGP domain. Then the controller or
the original node collects all the link MTUs from the routers. After the
SR path is calculated, packet may be lost if the packet size is larger
than the minimum MTU along the path. So the original node can compute
the minimum link MTU of all the links in the path. The source node can
limit the packet size less than the path MTU.A new TLV called link MTU TLV is defined to be included in the
Router Information LSP. The LSP transmitted by an interface in a
router MUST include the TLV. Each such TLV is encoded as shown in
Figure 1.Type: MTU, 1 byteLength: # of octets in the value field (1bytes)Value: the value is the MTU size of a link.The use and meaning of these fields are as follows:Type - A single octet encoding the TLV type. Here the type is 1
octet.Length - One octet encoding the length in octet of the TLV. This
field identifies the length of the value part.MTU size - This field identifies the size of the router interfaces.
Two octets encoding the MTU size of the TLV.This document defines a single MTU TLV, the codepoints need to be
determined by the IANA.TBD.This document requests that IANA allocate from the IS-IS TLV
Codepoints Registry a new TLV.This extension to IS-IS does not change the underlying security
issues iherent in the existing IGP.