One document matched: draft-mirsky-bier-path-mtu-discovery-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC1191 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1191.xml">
<!ENTITY RFC1981 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1981.xml">
<!ENTITY RFC4821 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4821.xml">
<!ENTITY I-D.ietf-bier-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-bier-architecture-03.xml">
<!ENTITY I-D.ietf-bier-oam-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-bier-oam-requirements-01.xml">
<!ENTITY I-D.kumarzheng-bier-ping SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-kumarzheng-bier-ping-02.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" ipr="trust200902" docName="draft-mirsky-bier-path-mtu-discovery-01">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<front>
<title abbrev='PMTUD for BIER'>Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit Replication (BIER) Layer</title>
<author initials='G.' surname="Mirsky" fullname='Greg Mirsky'>
<organization>Ericsson</organization>
<address>
<email>gregory.mirsky@ericsson.com</email>
</address>
</author>
<author initials='T.' surname="Przygienda" fullname='Tony Przygienda'>
<organization>Juniper Networks</organization>
<address>
<email>prz@juniper.net </email>
</address>
</author>
<author initials='A.' surname="Dolganow" fullname='Andrew Dolganow'>
<organization>Nokia</organization>
<address>
<email>andrew.dolganow@nokia.com</email>
</address>
</author>
<date day="5" month="April" year="2016" />
<area>Routing</area>
<workgroup>BIER Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>BIER</keyword>
<keyword>OAM</keyword>
<abstract>
<t>
This document describes Path Maximum Transmission Unit Discovery (PMTUD) in Bit Indexed Explicit Replication (BIER) layer.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
In packet switched networks when a host seeks to transmit a sizable amount of data to a
target destination the data is transmitted as a set of datagrams. In most
cases it is more efficient to use the largest possible datagrams but so that
these datagrams do not have to be fragmented at any point along the path from the host to
the destination in order to avoid performance degradation caused by fragmentation.
Fragmentation occurs on hops along the route where an Maximum Transmission Unit (MTU) is smaller
than the size of the datagram. To avoid such fragmentation the MTU for each hop along
a path from a host to a destination must be known to select an appropriate datagram size.
Such MTU determination along a specific path is referred to as path MTU discovery (PMTUD).
</t>
<t>
<xref target="I-D.ietf-bier-architecture"/> introduces and explains Bit Index Explicit Replication (BIER)
architecture and how it supports forwarding of multicast data packets.
A BIER domain consists of
Bit-Forwarding Routers (BFRs) that are uniquely identified by their respective BFR-ids. An ingress border router (acting as a
Bit Forwarding Ingress Router (BFIR)) inserts a Forwarding Bit Mask (F-BM) into a packet. Each targeted
egress node (referred to as a Bit Forwarding Egress Router (BFER)) is represented by Bit Mask Position (BMP)
in the BMS. A transit or intermediate BIER node, referred as BFR, forwards BIER encapsulated packets to
BFERs, identified by respective BMPs, according to a Bit Index Forwarding Table (BIFT).
</t>
<section title="Conventions used in this document">
<section title="Terminology">
<t>BFR: Bit-Forwarding Router </t>
<t>BFER: Bit-Forwarding Egress Router</t>
<t>BFIR: Bit-Forwarding Ingress Router </t>
<t>BIER: Bit Index Explicit Replication</t>
<t>BIFT: Bit Index Forwarding Tree </t>
<t>F-BM: Forwarding Bit Mask </t>
<t>MTU: Maximum Transmission Unit </t>
<t>OAM: Operations, Administration and Maintenance</t>
<t>PMTUD: Path MTU Discovery </t>
</section>
<section title="Requirements Language">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
<xref target="RFC2119"></xref>.
</t>
</section>
</section>
</section>
<section anchor="problem-state" title="Problem Statement">
<t>
<xref target="I-D.ietf-bier-oam-requirements"/> sets forth the requirement to define PMTUD
protocol for BIER domain. This document describes the extension to
<xref target="I-D.kumarzheng-bier-ping"/> for use in BIER PMTUD solution.
</t>
<t>
Current PMTUD mechanisms <xref target="RFC1191"/>, <xref target="RFC1981"/>,
and <xref target="RFC4821"/> are primarily targeted
to work on point-to-point, i.e. unicast paths. These mechanisms use packet
fragmentation control by disabling fragmentation of the probe packet. As result,
a transient node that cannot forward a probe packet that is bigger than its
link MTU sends to the ingress
node an error notification, otherwise the egress responds with a positive acknowledgement. Thus,
through series of iterations, decreasing and increasing size of the probe packet,
the ingress node discovers the MTU of the particular path.
</t>
<t>
Thus applied such existing PMTUD solutions are inefficient for point-to-multipoint paths
constructed for multicast traffic. Probe packets must be flooded through the whole set of
multicast distribution paths over and over again until the very last egress responds with a
positive acknowledgement. Consider without loss of generality an example
multicast network presented in <xref target="mcast-network"/>,
where MTU on all links but one (B,D) is the same. If MTU on link (B,D) is
smaller than the MTU on the other links, using
existing PMTUD mechanism probes will unnecessary flood to leaf nodes E, F, and G
for the second and consecutive times and positive responses will
be generated and received by root A repeatedly.
</t>
<t>
<figure align="left" anchor="mcast-network" title="Multicast network">
<artwork>
<![CDATA[
-----
--| D |
----- / -----
--| B |--
/ ----- \ -----
/ --| E |
----- / -----
| A |--- -----
----- \ --| F |
\ ----- / -----
--| C |--
----- \ -----
--| G |
-----
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="pmtud-bier-solution" title="PMTUD Mechanism for BIER">
<t>
A BFIR selects a set of BFERs for the specific multicast distribution. Such BFIR determines, by
explicitly controlling subset of targeted BFERs and transmitting series
of probe packets, the MTU of that multicast distribution path. The critical step is
that in case of failure at an intermediate BFR to forward towards the subset of
targeted downstream BFERs, the BFR responds with a partial (compared to the
one it received in the request) bitmask towards the originating BFIR in error
notification. That allows for retransmission of the next probe with smaller MTU address only
towards the failed downstream BFERs instead of all BFERs addressed in the previous probe.
In the scenario discussed in <xref target="problem-state"/> the
second and all following (if needed) probes will be sent only to the node D since
MTU discovery of E, F, and G has been completed already by the first probe successfully.
</t>
<t>
<xref target="I-D.kumarzheng-bier-ping"/> introduced BIER Ping as transport-independent
OAM mechanism to detect and localize failures in BIER data plane. This document specifies
how BIER Ping can be used to perform efficient PMTUD in BIER domain.
</t>
<t>
Consider network displayed in <xref target="mcast-network"/> to be presentation of a BIER domain
and all nodes to be BFRs. To discover MTU over BIER domain to BFERs D, F, E, and G BFIR A will use
BIER Ping with Data TLV, defined in <xref target="data-tlv"/>. Size of the first probe set to _M_max_
determined as minimal MTU value of BFIR's links to BIER domain.
As been assumed in <xref target="problem-state"/>, MTUs of all links but link (B,D) are the same.
Thus BFERs E. F, and G would receive BIER Echo Request and will send their
respective replies to BFIR A. BFR B may pass the packet which is too large to
forward over egress link (B, D) to the appropriate network layer for error processing
where it would be recognized as BIER Echo Request packet.
BFR B MUST send BIER Echo Reply to BFIR A and MUST include Downstream Mapping TLV,
defined in <xref target="I-D.kumarzheng-bier-ping"/> setting its fields in the following fashion:
<list style="symbols">
<t>MTU SHOULD be set to minimal MTU value among all egress BIER links that could be used to reach B's downstream BFERs;</t>
<t>Address Type MUST be set to 0 [Ed.note: we need to define 0 as valid value for the Address
Type field with the specific semantics to "Ignore" it.]</t>
<t>I flag MUST be cleared;</t>
<t>Downstream Interface Address field (4 octets) MUST be zeroed and
MUST include in Egress Bitstring sub-TLV the list of all BFERs that cannot be reached because
the attempted MTU turned out to be too small.
</t>
</list>
</t>
<t>
The BFIR will receive either of the two types of packets:
<list style="symbols">
<t>a positive Echo Reply from one of BFERs to which the probe has been sent. In such
case the bit corresponding to the BFER MUST be cleared from the BMS;
</t>
<t>
a negative Echo Reply with bit string listing unreached BFERs and recommended MTU
value MTU". The BFIR MUST add the bit string
to its BMS and set size of the next probe as min(MTU, MTU")
</t>
</list>
If upon expiration of the Echo Request timer BFIR didn't receive any Echo Replies,
then the size of the probe SHOULD be decreased. There are scenarios
when an implementation of the PMTUD would not decrease the size of the probe.
For example, if upon expiration of the Echo Request timer BFIR didn't receive
any Echo Reply, then BFIR MAY continue to retransmit the probe using the initial
size and MAY apply probe delay retransmission procedures. The algorithm used to
delay retransmission procedures on BFIR is outside the scope of this specification.
The BFIR
MUST continue sending probes using BMS until the bit string is clear or the discovery is
declared unsuccessful. In case of convergence of the procedure, the size of the last probe indicates the MTU size
that can be used for all BFERs in the initial BMS without incurring fragmentation.
</t>
<t>
Thus we conclude that in order to comply with the requirement in <xref target="I-D.ietf-bier-oam-requirements"/>:
<list style="symbols">
<t>a BFR SHOULD support PMTUD;</t>
<t>a BFR MAY use defined per BIER sub-domain MTU value as initial MTU
value for discovery or use it as MTU for this BIER sub-domain to reach BFERs.</t>
</list>
</t>
<section anchor="data-tlv" title="Data TLV for BIER Ping">
<t>
There need to be control of probe size in order to support the BIER PMTUD. Data TLV format
is presented in <xref target="data-tlv-fig"/>.
<figure align="left" anchor="data-tlv-fig"
title="Data TLV format">
<artwork><![CDATA[
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 (TBA1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<list style="symbols">
<t>Type: indicates Data TLV, to be allocated by IANA <xref target="iana-considerations"/>.</t>
<t>Length: the length of the Data field in octets.
</t>
<t>Data: n octets (n = Length) of arbitrary data. The receiver SHOULD ignore it.</t>
</list>
</t>
</section>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t>
IANA is requested to assign new Type value for Data TLV Type from its registry of TLV and sub-TLV Types of BIER Ping
as follows:
</t>
<texttable anchor="data-tlv-table" title="Data TLV Type">
<ttcol align='left'>Value</ttcol>
<ttcol align='center'>Description</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>TBA1</c>
<c>Data</c>
<c>This document</c>
</texttable>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>
Routers that support PMTUD based on this document are subject to the same security considerations as defined in
<xref target="I-D.kumarzheng-bier-ping"/>
</t>
</section>
<section anchor="ack" title="Acknowledgement">
<t>
TBD
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC1191;
&RFC1981;
&RFC4821;
&I-D.ietf-bier-architecture;
&I-D.kumarzheng-bier-ping;
</references>
<references title="Informative References">
&I-D.ietf-bier-oam-requirements;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 21:54:00 |