draft-ietf-babel-source-specific-02.txt   draft-ietf-babel-source-specific-03.txt 
Network Working Group M. Boutier Network Working Group M. Boutier
Internet-Draft J. Chroboczek Internet-Draft J. Chroboczek
Intended status: Standards Track IRIF, University of Paris-Diderot Intended status: Standards Track IRIF, University of Paris-Diderot
Expires: July 24, 2018 January 20, 2018 Expires: August 4, 2018 January 31, 2018
Source-Specific Routing in Babel Source-Specific Routing in Babel
draft-ietf-babel-source-specific-02 draft-ietf-babel-source-specific-03
Abstract Abstract
Source-specific routing (also known as Source-Address Dependent Source-specific routing (also known as Source-Address Dependent
Routing, SADR) is an extension to traditional next-hop routing where Routing, SADR) is an extension to traditional next-hop routing where
packets are forwarded according to both their destination and their packets are forwarded according to both their destination and their
source address. This document describes an extension for source- source address. This document describes an extension for source-
specific routing to the Babel routing protocol. specific routing to the Babel routing protocol.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://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 July 24, 2018. This Internet-Draft will expire on August 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and background . . . . . . . . . . . . . . . . . 2 1. Introduction and background . . . . . . . . . . . . . . . . . 2
skipping to change at page 2, line 19 skipping to change at page 2, line 19
3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 3 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. The Source Table . . . . . . . . . . . . . . . . . . . . 3 3.1. The Source Table . . . . . . . . . . . . . . . . . . . . 3
3.2. The Route Table . . . . . . . . . . . . . . . . . . . . . 4 3.2. The Route Table . . . . . . . . . . . . . . . . . . . . . 4
3.3. The Table of Pending Seqno Requests . . . . . . . . . . . 4 3.3. The Table of Pending Seqno Requests . . . . . . . . . . . 4
4. Data Forwarding . . . . . . . . . . . . . . . . . . . . . . . 4 4. Data Forwarding . . . . . . . . . . . . . . . . . . . . . . . 4
5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 5 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 5
5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 6 5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 6
5.2. Wildcard Messages . . . . . . . . . . . . . . . . . . . . 6 5.2. Wildcard Messages . . . . . . . . . . . . . . . . . . . . 6
6. Compatibility with the base protocol . . . . . . . . . . . . 7 6. Compatibility with the base protocol . . . . . . . . . . . . 7
6.1. Loop-avoidance . . . . . . . . . . . . . . . . . . . . . 7 6.1. Loop-avoidance . . . . . . . . . . . . . . . . . . . . . 7
6.2. Starvation and Blackholes . . . . . . . . . . . . . . . . 7 6.2. Starvation and Blackholes . . . . . . . . . . . . . . . . 8
7. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 8 7. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Source Prefix sub-TLV . . . . . . . . . . . . . . . . . . 8 7.1. Source Prefix sub-TLV . . . . . . . . . . . . . . . . . . 8
7.2. Source-specific Update . . . . . . . . . . . . . . . . . 9 7.2. Source-specific Update . . . . . . . . . . . . . . . . . 9
7.3. Source-specific (Route) Request . . . . . . . . . . . . . 9 7.3. Source-specific (Route) Request . . . . . . . . . . . . . 9
7.4. Source-Specific Seqno Request . . . . . . . . . . . . . . 9 7.4. Source-Specific Seqno Request . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Security considerations . . . . . . . . . . . . . . . . . . . 9 9. Security considerations . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction and background 1. Introduction and background
The Babel routing protocol [BABEL] is a distance vector routing The Babel routing protocol [BABEL] is a distance vector routing
protocol for next-hop routing. In next-hop routing, each node protocol for next-hop routing. In next-hop routing, each node
maintains a forwarding table which maps destination prefixes to next maintains a forwarding table which maps destination prefixes to next
hops. The forwarding decision is a per-packet operation which hops. The forwarding decision is a per-packet operation which
depends on the destination address of the packets and on the entries depends on the destination address of the packets and on the entries
of the forwarding table. When a packet is about to be routed, its of the forwarding table. When a packet is about to be routed, its
skipping to change at page 2, line 52 skipping to change at page 3, line 4
address of the packet is chosen, and the packet is forwarded to the address of the packet is chosen, and the packet is forwarded to the
associated next-hop. Next-hop routing is a simple, well understood associated next-hop. Next-hop routing is a simple, well understood
paradigm that works satisfactorily in a large number of cases. paradigm that works satisfactorily in a large number of cases.
Source-specific routing [SS-ROUTING], or Source Address Dependent Source-specific routing [SS-ROUTING], or Source Address Dependent
Routing (SADR) [DSR], is a modest extension to next-hop routing where Routing (SADR) [DSR], is a modest extension to next-hop routing where
the forwarding decision depends not only on the destination address the forwarding decision depends not only on the destination address
but also on the source address of the packet being routed, which but also on the source address of the packet being routed, which
makes it possible for two packets with the same destination but makes it possible for two packets with the same destination but
different source addresses to be routed following different paths. different source addresses to be routed following different paths.
The forwarding tables are extended to map pairs of prefixes The forwarding tables are extended to map pairs of prefixes
(destination, source) to next hops. When multiple entries match a (destination, source) to next hops. When multiple entries match a
given packet, the one with the most specific destination prefix is given packet, the one with the most specific destination prefix is
chosen, and, in case of equality, the one with the most specific chosen, and, in case of equality, the one with the most specific
source prefix. source prefix.
The main application of source-specific routing is multihoming with The main application of source-specific routing is a form of
multiple addresses, a technique for multihoming which, unlike multihoming known as multihoming with multiple addresses. When using
multihoming, does not require the use of provider-independent this technique in a network connected to multiple providers, every
addresses and does not cause excessive growth of the global routing host is assigned multiple addresses, one per provider. When a host
table. In a network using this form of multihoming, each host is sources a packet, it picks one of its addresses as the source
given multiple addresses, one per upstream provider. When a host address, and source-specific routing is used to route the packet to
sources a packet, it picks one of its addresses as the source address an edge router that is connected to the corresponding provider, which
of the packet, and source-specific routing is used to route the is compatible with [BCP84]. Unlike classical multihoming, this
packet to an edge router that is connected to the corresponding technique is applicable to small networks, as it does not require the
provider, which is compatible with [BCP84]. More details are given use of provider-independent addresses, or cause excessive growth of
in [SS-ROUTING] and [DSR]. the global routing table. More details are given in [SS-ROUTING] and
[DSR].
This document describes a source-specific routing extension for the This document describes a source-specific routing extension for the
Babel routing protocol [BABEL]. This involves minor changes to the Babel routing protocol [BABEL]. This involves minor changes to the
data structures, which must include a source prefix in addition to data structures, which must include a source prefix in addition to
the destination prefix already present, and some changes to the the destination prefix already present, and some changes to the
Update, Route Request and Seqno Request TLVs, which are extended with Update, Route Request and Seqno Request TLVs, which are extended with
a source prefix. The source prefix is encoded using a mandatory sub- a source prefix. The source prefix is encoded using a mandatory sub-
TLV ([BABEL] Section 4.4). TLV ([BABEL] Section 4.4).
2. Specification of Requirements 2. Specification of Requirements
skipping to change at page 8, line 27 skipping to change at page 8, line 35
Since a source-specific routing entry is characterized by a single Since a source-specific routing entry is characterized by a single
destination prefix and a single source prefix, a source-specific destination prefix and a single source prefix, a source-specific
message contains exactly one Source Prefix sub-TLV. A node MUST NOT message contains exactly one Source Prefix sub-TLV. A node MUST NOT
send more that one Source Prefix sub-TLV in a TLV, and a node send more that one Source Prefix sub-TLV in a TLV, and a node
receiving more than one Source Prefix sub-TLV in a single TLV SHOULD receiving more than one Source Prefix sub-TLV in a single TLV SHOULD
ignore this TLV. It MAY ignore the whole packet. ignore this TLV. It MAY ignore the whole packet.
7.1. Source Prefix sub-TLV 7.1. Source Prefix sub-TLV
0 1 2 3 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 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 = TBD | Length | Source Plen | Source Prefix... | Type = 128 | Length | Source Plen | Source Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields: Fields:
Type Set to TBD to indicate a Source Prefix sub-TLV. Type Set to 128 to indicate a Source Prefix sub-TLV.
Length The length of the body, exclusive of the Type and Length Length The length of the body, exclusive of the Type and Length
fields. fields.
Source Plen The length of the advertised source prefix. This MUST Source Plen The length of the advertised source prefix. This MUST
NOT be 0. NOT be 0.
Source Prefix The source prefix being advertised. This field's size Source Prefix The source prefix being advertised. This field's size
is (Source Plen)/8 rounded upwards. is (Source Plen)/8 rounded upwards.
skipping to change at page 9, line 37 skipping to change at page 9, line 45
7.4. Source-Specific Seqno Request 7.4. Source-Specific Seqno Request
A source-specific Seqno Request is a Seqno Request TLV with a Source A source-specific Seqno Request is a Seqno Request TLV with a Source
Prefix sub-TLV. It requests the receiving node to perform the Prefix sub-TLV. It requests the receiving node to perform the
procedure described in Section 3.8.1.2 of [BABEL], but applied to a procedure described in Section 3.8.1.2 of [BABEL], but applied to a
pair of a destination and source prefix. pair of a destination and source prefix.
8. IANA Considerations 8. IANA Considerations
IANA is requested to allocate TBD, a Babel sub-TLV type from the IANA has allocated sub-TLV number 128 for the Source Prefix sub-TLV
range reserved for mandatory sub-TLVs [value 128 suggested], and to in the Babel Sub-TLV Numbers registry.
add the following entry to the "Babel mandatory sub-TLV Types"
registry:
+----------+---------------+-----------------+
| Type | Name | Reference |
+----------+---------------+-----------------+
| TBD[128] | Source Prefix | (this document) |
+----------+---------------+-----------------+
9. Security considerations 9. Security considerations
The extension defined in this document adds a new sub-TLV to three The extension defined in this document adds a new sub-TLV to three
TLVs already present in the original Babel protocol, and does not in TLVs already present in the original Babel protocol, and does not in
itself change the security properties of the protocol. However, itself change the security properties of the protocol. However,
source-specific routing gives more control over routing to the source-specific routing gives more control over routing to the
sending hosts, which might have security implications (see Section 8 sending hosts, which might have security implications (see Section 8
of [DSR]). of [DSR]).
10. References 10. Acknowledgments
10.1. Normative References The authors are grateful to Joel Halpern for his help with this
document.
11. References
11.1. Normative References
[BABEL] Chroboczek, J., "The Babel Routing Protocol", Internet [BABEL] Chroboczek, J., "The Babel Routing Protocol", Internet
Draft draft-ietf-babel-rfc6126bis-04, May 2017. Draft draft-ietf-babel-rfc6126bis-04, May 2017.
[BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997. DOI 10.17487/RFC2119, March 1997.
10.2. Informative References 11.2. Informative References
[DSR] Lamparter, D. and A. Smirnov, "Destination/Source [DSR] Lamparter, D. and A. Smirnov, "Destination/Source
Routing", Internet Draft draft-ietf-rtgwg-dst-src-routing- Routing", Internet Draft draft-ietf-rtgwg-dst-src-routing-
06, May 2018. 06, May 2018.
[RFC6126] Chroboczek, J., "The Babel Routing Protocol [RFC6126] Chroboczek, J., "The Babel Routing Protocol
(Experimental)", RFC 6126, February 2011. (Experimental)", RFC 6126, February 2011.
[SS-ROUTING] [SS-ROUTING]
Boutier, M. and J. Chroboczek, "Source-Specific Routing", Boutier, M. and J. Chroboczek, "Source-Specific Routing",
 End of changes. 16 change blocks. 
37 lines changed or deleted 37 lines changed or added

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