< draft-raza-mpls-ldp-olf-00.txt   draft-raza-mpls-ldp-olf-01.txt >
Network Working Group Kamran Raza Network Working Group Kamran Raza
Internet Draft Sami Boutros Internet Draft Sami Boutros
Intended status: Standards Track Pradosh Mohapatra Intended status: Standards Track Pradosh Mohapatra
Expires: December 2, 2011 Expires: October 30, 2012
Cisco Systems, Inc. Cisco Systems, Inc.
June 3, 2011 May 1, 2012
LDP Outbound Label Filtering
draft-raza-mpls-ldp-olf-00.txt
Abstract LDP Outbound Label Bindings Filtering
The Label Distribution Protocol (LDP) allows one Label Switching draft-raza-mpls-ldp-olf-01.txt
Router (LSR) to advertise to another a set of "bindings" between
MPLS labels and "Forwarding Equivalence Classes" (FECs). Suppose
LSR2 is advertising a set of label bindings to LSR1. Frequently,
LSR1 does not need to know all of LSR2's label bindings, and LSR1
may be configured to disregard bindings in which it has no interest.
This document defines an "Outbound Label Filtering" (OLF) mechanism
that allows LSR1 to inform LSR2 dynamically of the set of FECs for
which it needs to receive label bindings. LSR2 then applies this
filter before sending its label bindings to LSR1. In addition to the
generic aspects of this mechanism, this document also specifies
outbound label filter for the "Address Prefix FEC" type.
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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 2, 2011. This Internet-Draft will expire on October 30, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Abstract
The Label Distribution Protocol (LDP) allows one Label Switching
Router (LSR) to advertise to another a set of "bindings" between
MPLS labels and "Forwarding Equivalence Classes" (FECs). Suppose
LSR2 is advertising a set of label bindings to LSR1. Frequently,
LSR1 does not need to know all of LSR2's label bindings, and LSR1
may be configured to disregard bindings in which it has no interest.
This document defines an "Outbound Label Bindings Filtering" (OLF)
mechanism that allows LSR1 to inform LSR2 dynamically of the set of
FECs for which it needs to receive label bindings. LSR2 then
applies this filter before sending its label bindings to LSR1. In
addition to the generic aspects of this mechanism, this document
also specifies the format for the outbound label binding filter for
the "Address Prefix FEC" type.
Table of Contents Table of Contents
1. Introduction 3 1. Introduction 3
2. Conventions used in this document 3 2. Conventions used in this document 3
3. FEC Label Bindings 3 3. FEC Label Bindings 4
4. Outbound Label Filter 4 4. Outbound Label Filter 4
4.1. Constructs 4 4.1. Constructs 4
4.1.1. FEC-Type 4 4.1.1. FEC-Type 4
4.1.2. OLF Policy 5 4.1.2. OLF Policy 5
4.2. OLF Signaling 6 4.2. OLF Signaling 6
4.2.1. OLF Policy Status TLV 6 4.2.1. OLF Policy Status TLV 6
4.2.2. OLF Element Format 7 4.2.2. OLF Element Format 7
4.2.3. OLF Entry Format 8 4.2.3. OLF Entry Format 8
Rules for OLF Element and OLF Entry 9
4.2.4. 9
4.3. OLF Capability negotiation 10 4.3. OLF Capability negotiation 10
4.4. OLF Procedures 12 4.4. OLF Procedures 12
4.4.1. OLF Capability Negotiation At Session Estab. Time 12 4.4.1. OLF Capability Negotiation At Session Estab. Time 13
4.4.2. OLF Capability Dynamic Changes 13 4.4.2. OLF Capability Dynamic Changes 14
4.4.3. OLF Policy Updates 15 4.4.3. OLF Policy Updates 15
5. Address Prefix FEC OLF Type 16 5. OLF Specification for "Address Prefix FEC" 16
5.1. Matching Address Prefixes to OLF Entries 17 5.1. Matching Address Prefixes to OLF Entries 18
6. Operational Examples 18 6. Operational Examples 19
6.1. Label Filtering at Area Border Router 18 6.1. Label Filtering at Area Border Router 19
6.2. LSR with limited LIB size 19 6.2. LSR with limited LIB size 19
7. Security Considerations 19 6.3. Label Filtering an Address Family in an IP Dual-Stack LSR 19
8. IANA Considerations 19 7. Security Considerations 20
8. IANA Considerations 20
9. References 20 9. References 20
9.1. Normative References 20 9.1. Normative References 20
9.2. Informative References 20 9.2. Informative References 21
10. Acknowledgments 20 10. Acknowledgments 21
1. Introduction 1. Introduction
The Label Distribution Protocol (LDP) allows one Label Switching The Label Distribution Protocol (LDP) allows one Label Switching
Router (LSR) to advertise to another a set of "bindings" between MPLS Router (LSR) to advertise to another a set of "bindings" between MPLS
labels and "Forwarding Equivalence Classes" (FECs). When LDP's labels and "Forwarding Equivalence Classes" (FECs). When
"Downstream Unsolicited" mode [RFC5036] is in use, an LSR may receive "Downstream Unsolicited" mode [RFC5036] is in use for a LDP session,
label bindings for FECs in which it has no interest. The receiving an LSR may receive unsolicited label bindings for FECs in which it
LSR typically filters out these unwanted label bindings based on its has no interest. The receiving LSR typically filters out these
local policy. Since the advertisement of label binding updates by the unwanted label bindings based on its local policy. Since the
sender, as well as the processing of these updates by the receiver, advertisement of label binding updates by the sender, as well as the
consume network bandwidth and LSR resources, it may be beneficial if processing of these updates by the receiver, consume network
the advertisement of such label bindings can be avoided at the source bandwidth and LSR resources, it may be beneficial if the
advertisement of such label bindings can be avoided at the source
itself under the control of the receiver. itself under the control of the receiver.
This document defines a label filtering mechanism that allows an LDP This document defines a label filtering mechanism that allows an LDP
speaker to send to its LDP peer a set of FEC-based Outbound Label speaker to send to its LDP peer a set of FEC-based Outbound Label
Filters (OLFs). The peer would apply these filters, in addition to Filters (OLFs). The peer would apply these filters, in addition to
any local outbound filtering policy, to constrain/filter its outbound any local outbound filtering policy, to constrain/filter its outbound
label binding updates to the speaker. label binding updates to the speaker.
This document also defines the Outbound Label Filter (OLF) type This document also defines the Outbound Label Bindings Filter, named
"Address Prefix FEC Outbound Label Filter" for "Address Prefix FEC" "Address Prefix FEC Outbound Label Filter", for "Address Prefix" FEC
type, which can be used to perform label filtering for IP Prefix type. This filter, thus, can be used to perform outbound label
label bindings. filtering for IP Prefix label bindings.
This specification is modeled on [RFC5291] and [RFC5292]. This specification is modeled on [RFC5291] and [RFC5292].
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
The term "FEC-Type" is used to refer to a tuple consisting of <FEC The term "FEC-Type" is used to refer to a tuple consisting of <FEC
Element Type, Address Family>. Element Type, Address Family>.
3. FEC Label Bindings 3. FEC Label Bindings
MPLS LDP associates a FEC with each Label Switched Path (LSP) it LDP [RFC5036] associates a FEC with each Label Switched Path (LSP)
creates [RFC5036]. This means that a label is assigned for 1 or more it creates. This means that a label is assigned for one or more
FEC(s) and label bindings advertised to peers are bound to FEC(s). FEC(s) and label bindings advertised to peers are bound to FEC(s).
To define an LDP OLF, filters need to be defined for label bindings. To define an LDP OLF, filters need to be defined for label bindings.
These filter definitions need to include both FEC Element type, as These filter definitions need to include both FEC Element type, as
well as address family, if/as applicable, for a given FEC type. well as Address Family, if/as applicable, for a given FEC type.
Following is a list of most commonly used LDP FEC elements at the Following is a list of most commonly used LDP FEC elements (at the
time of writing of this document: time of writing of this document):
FEC Element Type Address Family Specification LDP FEC Element Type Address Family Specification
---------------- ------------- ------------- -------------------- ------------- -------------
Wildcard N/A [RFC5036] Wildcard N/A [RFC5036]
Address Prefix IPv4, IPv6 [RFC5036] Address Prefix IPv4, IPv6 [RFC5036]
Typed Wildcard AF of Sub-FEC [RFC5918] Typed Wildcard AF of Sub-FEC [RFC5918]
P2MP IPv4, IPv6 [mLDP] P2MP IPv4, IPv6 [RFC6388]
MP2MP-Upstream IPv4, IPv6 [mLDP] MP2MP-Upstream IPv4, IPv6 [RFC6388]
MP2MP-Downstream IPv4, IPv6 [mLDP] MP2MP-Downstream IPv4, IPv6 [RFC6388]
PWid N/A [RFC4447] PWid N/A [RFC4447]
Generalized PWid N/A [RFC4447] Generalized PWid N/A [RFC4447]
P2MP PW N/A [P2MP-PW] P2MP PW Upstream N/A [P2MP-PW]
P2P PW Downstream N/A [P2MP-PW]
Table 1: LDP FEC Types Table 1: LDP FEC Types
This document defines a framework for label filtering that applies This document defines a framework for label filtering that applies
to all of the FEC types listed under Table 1, except "Wildcard" and to all of the FEC types listed under Table 1, except "Wildcard" and
"Typed Wildcard" FEC types. The framework is also easily extensible "Typed Wildcard" FEC types. The framework is also easily extensible
for new FEC types that may get defined in the future. for new FEC types that may get defined in the future.
4. Outbound Label Filter 4. Outbound Label Filter
4.1. Constructs 4.1. Constructs
4.1.1. FEC-Type 4.1.1. FEC-Type
In the context of this document, we define "FEC-Type" as a construct In the context of this document, we define "FEC-Type" as a construct
that uniquely identifies (or maps to) a FEC. This is defined as a that uniquely identifies (or maps to) a FEC. This is defined as a
tuple of the following form: tuple of the following form:
<FEC Element Type, Address Family> <FEC Element Type, Address Family>
As shown in Table 1, not all FEC elements require qualification with As shown in Table 1, not all FEC elements are qualified with an
Address Family. For those types, the address family is not specified Address Family. For those types, the address family is not specified
(set to a reserved value). (set to a reserved value).
Following are some example of FEC-Types: Following are some example of FEC-Types:
<Address Prefix FEC Element, IPv4> <Address Prefix FEC Element, IPv4>
<Address Prefix FEC Element, IPv6> <Address Prefix FEC Element, IPv6>
<PWid, N/A> <PWid FEC Element, N/A>
4.1.2. OLF Policy 4.1.2. OLF Policy
We define an Outbound Label Filtering (OLF) Policy as a set of one or We define an OLF Policy as a set of one or more OLF Elements, each
more OLF Elements each corresponding to a given FEC-Type. Where, an corresponding to a given FEC-Type. Where, an OLF Element itself
OLF Element itself comprises one or more OLF Entries. comprises one or more OLF Entries.
4.1.2.1. OLF Element 4.1.2.1. OLF Element
An OLF Element is identified by a FEC-Type and consists of one or An OLF Element is identified by a FEC-Type and consists of one or
more OLF entries that have a common FEC-Type. The "FEC-Type" more OLF entries that have a common FEC-Type. The FEC-Type component
component uniquely identifies a FEC and is used to provide a coarse uniquely identifies a FEC and is used to provide a coarse
granularity control by limiting an OLF to only those FECs that match granularity control by limiting an OLF to only those FECs that match
the FEC-Type component. the FEC-Type component.
To define an OLF Element for a given FEC-Type, precise conditions and To define an OLF Element for a given FEC-Type, precise conditions and
rules need to be specified under which the given FEC is considered to rules need to be specified under which the given FEC is considered to
match a particular OLF entry. match a particular OLF entry.
4.1.2.2. OLF Entry 4.1.2.2. OLF Entry
An OLF entry is a tuple of the form: An OLF entry is a tuple of the form:
<Action, OLF-value> <Action, OLF-value>
The "Action" component specifies how the OLF filter is to be handled The "Action" component specifies how the OLF filter is to be handled
by the receiving LSR. The specified values for Action include by the receiving LSR. The specified values for "Action" include
"PERMIT", "DENY", and "PERMIT-ALL". PERMIT action indicates to "PERMIT", "DENY", and "PERMIT-ALL". PERMIT action indicates to
receiving LSR to allow advertisement of label bindings for the set receiving LSR to allow advertisement of label bindings for the set
of FECs that match the OLF entry, DENY is opposite of PERMIT and of FECs that match the OLF entry, DENY is opposite of PERMIT and
disallows (i.e. filters) the advertisement of label bindings for the disallows (i.e. filters) the advertisement of label bindings for the
set of FECs that match the OLF entry. PERMIT-ALL is the wildcard set of FECs that match the OLF entry. PERMIT-ALL is the wildcard
equivalent of PERMIT, and hence apply to all FECs associated with equivalent of PERMIT, and hence apply to all FECs associated with
the FEC-Type of the OLF Element corresponding to OLF entry. the FEC-Type of the OLF Element corresponding to OLF entry.
The "OLF-value" component is FEC-specific and provides the The "OLF-value" component is FEC-specific and provides the
specification of FEC for matching. This component is not mandatory specification of FEC for matching. This component is not mandatory
and is not present when Action component is PERMIT-ALL. The format and is not present when Action component is PERMIT-ALL. The format
of OLF-value for a FEC element type is to be defined by the designer of the OLF-value for a given FEC element type is to be defined by
of the given FEC element. This document defines the format of OLF- the designer of the FEC element. This document defines the format of
Value for FEC-Types corresponding to "Address Prefix" FEC Element OLF-value for FEC-Types corresponding to "Address Prefix" FEC
type [RFC5036]. Element type [RFC5036].
4.2. OLF Signaling 4.2. OLF Signaling
4.2.1. OLF Policy Status TLV 4.2.1. OLF Policy Status TLV
An OLF is signaled to a peer through LDP Notification messages. A An OLF is signaled to a peer through an LDP Notification message. A
new status TLV, named "OLF Policy Status", is introduced to carry new status TLV, named "OLF Policy Status", is introduced to carry
the OLF specifications. This TLV is carried in the optional the OLF specifications. This TLV is carried in the optional
parameter section of the LDP Notification message. Moreover, a new parameter section of the LDP Notification message. Moreover, a new
LDP Status Code, "OLF Status", is defined for use in LDP Status TLV LDP Status Code, "OLF Status", is defined for use in LDP Status TLV
to indicate the presence of "OLF Policy Status" TLV in a given to indicate the presence of "OLF Policy Status" TLV in a given
Notification message. Notification message.
A single OLF Policy Status TLV may contain one or more OLF Element A single OLF Policy Status TLV may contain one or more OLF Element
sub-TLVs. Each OLF Element TLV represents a single FEC-Type and sub-TLVs, where each OLF Element TLV represents a single FEC-Type
consists of one or more "OLF Entry" sub-TLVs. and consists of one or more "OLF Entry" sub-TLVs.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| OLF Policy Status(IANA) | Length | |U|F| OLF Policy Status(IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved | | |M| Reserved | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| | | |
~ OLF Element(s) ~ ~ OLF Element(s) ~
skipping to change at page 6, line 34 skipping to change at page 6, line 42
|U|F| OLF Policy Status(IANA) | Length | |U|F| OLF Policy Status(IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved | | |M| Reserved | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| | | |
~ OLF Element(s) ~ ~ OLF Element(s) ~
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-++-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-++-+-+-+-+-+-+-+
Figure 1: OLF Policy Status TLV Figure 1: OLF Policy Status TLV
Where: Where:
U/F bits: U-bit/F-bit MUST be set to 1/0 respectively so that a U/F bits: U-bit/F-bit MUST be set to 1/0 respectively so that a
receiver MUST silently ignore this TLV if unknown to it, and receiver MUST silently ignore this TLV if unknown to it, and
continue processing the rest of the message. continue processing the rest of the message.
Length: Total length (in octets) of "OLF Policy Status TLV" Length: Total length (in octets) of "OLF Policy Status" TLV
following the "Length" field. There is no padding requirement at following the "Length" field. There is no padding requirement at
the end of this TLV in case TLV does not end at Word boundary. the end of this TLV in case TLV does not end at Word boundary.
OLF Element(s): One or more OLF Element sub-TLVs. In a given OLF OLF Element(s): One or more OLF Element sub-TLVs. In a given OLF
Policy Status TLV, only one OLF Element for a given FEC-Type is Policy Status TLV, only one OLF Element for a given FEC-Type is
allowed. If more than one OLF Element is present for a given allowed. If more than one OLF Element is present for a given
FEC-Type, then receiving LSR MUST pick the first occurrence of FEC-Type, then receiving LSR MUST pick the first occurrence of
such an element and ignore the other occurrences corresponding such an element and ignore the other occurrences corresponding
to the given FEC-Type. to the given FEC-Type.
M-bit: "More" bit specifying if there are more/further OLF Policy M-bit: "More" bit specifying if there are more/further OLF Policy
Status to follow for the given update set. The bit is set to 1 Status to follow for the given update set. The bit is set to 1
if there are further portion of policy that will follow in if there are further portion of policy that will follow in
subsequent message(s), and set to 0 if the TLV alone constitutes subsequent message(s), and set to 0 if the TLV alone constitutes
the policy, or is the last update for the given update set. the policy, or is the last update for the given update set.
Reserved bits: Reserved for future use. MUST be set to zero on Reserved bits: Reserved for future use. MUST be set to zero on
transmit and MUST be ignored on receipt. transmit and ignored on receipt.
An LSR MAY also update its OLF with a peer by sending subsequent An LSR MAY update its OLF with a peer by sending OLF Policy Status'
"OLF Policy Status" TLVs in LDP Notification messages. The receipt TLVs in an LDP Notification message. The receipt of an OLF Policy
of an OLF Policy update from a peer for a given FEC-Type is meant to update from a peer for a given FEC-Type is meant to replace
replace (overwrite) the previously installed FEC-Type OLF policy (overwrite) the previously installed FEC-Type OLF policy
corresponding to the peer, if any, at the receiving LSR. corresponding to the peer, if any, at the receiving LSR.
A complete OLF policy can be splitted across more than one OLF A complete OLF policy can be splitted across more than one OLF
policy updates -- e.g. if the given OLF policy is big enough to fit policy updates -- e.g. if the given OLF policy is big enough to fit
in a single Notification message (due to LDP PDU size limitation in a single Notification message (due to LDP PDU size limitation
[RFC5036]). In such cases, the sender LSR sends more than one LDP [RFC5036]). In such cases, the sender LSR MAY send more than one LDP
Notification message(s) with "OLF Policy Status" TLV, splitting the Notification message(s) with "OLF Policy Status" TLV, splitting the
policy on OLF Element boundaries (i.e. an OLF Element MUST NOT span policy on OLF Element boundaries (i.e. an OLF Element MUST NOT span
across more than one message). The sender also indicates if more across more than one message). Using M-bit, the sender also
than single Policy message will be sent for the given OLF update, as indicates if more than single Policy message will be sent for the
well as indicates the last message in the given update set. The given OLF update, as well as indicates the last message in the given
receiver LSR, upon receiving OLF updates that span across more than update set. Upon receiving OLF updates that span across more than
one message, stores them in the order of receipt and processes them one message, the receiver LSR stores the received policy update(s)
only after complete policy set has been received. If an LSR receives in the order of receipt and processes them once complete policy set
an incomplete/partial update set, and does not receive end of update has been received. If an LSR receives an incomplete/partial update
(i.e. last message in the given set with M bit set to 0), it keeps set, and does not receive an end of update (i.e. last message in the
these partial updates in its temporary buffer until one of the given set with M bit be set to 0), it keeps these partial updates in
following events occur: its temporary buffer until one of the following events occur:
1. End of [policy] update received (OLF Policy Status TLV with M=0) 1. End of [policy] update received (OLF Policy Status TLV with M=0)
2. Session terminates 2. Session terminates
3. OLF capability changes 3. OLF capability changes
4.2.2. OLF Element Format 4.2.2. OLF Element Format
As shown in Figure 2, an OLF Element comprises one or more OLF As shown in Figure 2, an OLF Element comprises one or more OLF
entries grouped by FEC-Type <FEC Element Type, Address Family>: entries grouped by FEC-Type <FEC Element Type, Address Family>:
skipping to change at page 8, line 21 skipping to change at page 8, line 21
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| | | |
~ OLF Entries ~ ~ OLF Entries ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-++-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-++-+-+-+-+-+-+-+
Figure 2: OLF Element format Figure 2: OLF Element format
Where: Where:
FEC-Elem-Type/Address-Family: These fields jointly represent a FEC-Elem-Type/Address-Family: These fields jointly represent a
FEC-Type. For the FEC element types listed in Table 1 which do FEC-Type. For the FEC element types listed in Table 1 which are
not require Address Family qualification, Address-Family field not qualified with an Address Family, Address-Family field MUST
MUST be set to zero on transmit and MUST be ignored on receipt. be set to zero on transmit and MUST be ignored on receipt.
Length: Length (in octets) of the OLF Element sub-TLV following Length: Length (in octets) of the OLF Element sub-TLV following
the "Length" field; i.e. total length of OLF entries that follow the "Length" field; i.e. total length of OLF entries that follow
in the given OLF Element sub-TLV. There is no padding in the given OLF Element sub-TLV. There is no padding
requirement at the end of this TLV in case TLV does not end at requirement at the end of this TLV in case TLV does not end at
Word boundary. Word boundary.
4.2.3. OLF Entry Format 4.2.3. OLF Entry Format
Each OLF Entry is encoded as follows: Each OLF Entry is encoded as follows:
skipping to change at page 9, line 7 skipping to change at page 9, line 7
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
~ Type-specific part ~ ~ Type-specific part ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-++-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-++-+-+-+-+-+-+-+
Figure 3: OLF Entry format Figure 3: OLF Entry format
Where: Where:
Common part: Common definition that is applicable to all types of Common part: Common definition that is applicable to all types of
OLF entries. OLF entries.
Type-specific part: Type specific (variable) definition Type-specific part: FEC-Type specific (variable) definition; This
corresponding to FEC-Type; also called "OLF-value" under section field corresponds to the "OLF-value" under section 4.1.2.2.
4.1.2.2.
The "Common part" is one-octet field defined as following: The "Common part" is one-octet field defined as following:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Action | Rsvd | |Action | Rsvd |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Where: Where:
Action: Indicates the desired action (operation) to be performed Action: Indicates the desired action (operation) to be performed
by receiving LSR on received OLF entry, if FEC matches. The by receiving LSR on received OLF entry, if enclosed value (i.e.
possible values are FEC) matches. The possible values for Action are
0: PERMIT 0: PERMIT
1: DENY 1: DENY
2: PERMIT-ALL 2: PERMIT-ALL
4-15: Reserved (for future use). 4-15: Reserved (for future use).
Rsvd: Reserved for future use. MUST be set to 0 on transmit and Rsvd: Reserved for future use. MUST be set to 0 on transmit and
MUST be ignored on the receipt. MUST be ignored on the receipt.
4.2.4. Rules for OLF Element and OLF Entry 4.2.4. Rules for OLF Elements and Entries
Following rules apply to OLF Element and Entries: Following rules apply to an OLF Element and OLF Entry:
o When the Action component of an OLF entry specifies a wildcard o When the Action component of an OLF entry specifies a wildcard
operation (PERMIT-ALL), then the OLF entry MUST consist of only operation (PERMIT-ALL), then the OLF entry MUST consist of only
the Common part. the Common part.
o When an OLF Element contains more than one OLF entry, then o When an OLF Element contains more than one OLF entry, then
receiving LSR MUST process the OLF entries in the same order as receiving LSR MUST process the OLF entries in the same order as
they are specified inside the OLF element. they are specified inside the OLF element.
o When processing a received OLF Element, an LSR MUST assume an o When processing a received OLF policy for a given FEC-Type, the
implicit "DENY-ALL" as the last rule/entry. This assumption means receiving LSR MUST assume an implicit "DENY" as the last
that LSR denies all those FECs [of given FEC-Type] that have not rule/entry. This assumption means that LSR denies all those FECs
already been matched in any of the specified OLF entries. This [of given FEC-Type] that have not already been matched in any of
also means that the sender LSR needs to construct an OLF Element the specified OLF entries. This also means that the sender LSR
while keeping in mind an implicit DENY-ALL as the last rule. needs to construct an OLF Element while keeping in mind an
implicit DENY-ALL as the last rule.
4.3. OLF Capability negotiation 4.3. OLF Capability negotiation
When a session has been negotiated to operate in Downstream When a session has been negotiated to operate in Downstream
Unsolicited mode, LDP speakers exchange all of their label bindings. Unsolicited mode, LDP speakers exchange all of their label bindings.
If it is desired/required to exchange only selected label bindings If it is desired/required to exchange only selected label bindings
between peers, the "Outbound Label Filtering Capability" is between peers, the "Outbound Label Filtering Capability" (OLF) is
negotiated at session establishment time or at a later time. negotiated at session establishment time or at a later time.
An LDP speaker advertises the OLF Capability to announce to its peer An LDP speaker advertises the OLF Capability to announce to its peer
its capability [and desire] to either send or receive or both its capability [and desire] to either send, or receive, or both send
send/receive OLF filters. The OLF feature will, however, work only and receive the OLF filters. The OLF feature will, however, work
when at least one LSR is able to send and other able to receive the only when at least one LSR is able to compute and send the policy,
OLF filters. The OLF Capability can be sent either in an and other is able to receive and process the OLF filters. The OLF
Initialization message (Capability TLV's S-bit MUST be set to 1) or Capability can be sent either in an Initialization message
in a Capability message (Capability TLV's S-bit set to 1 or 0 to (Capability TLV's S-bit MUST be set to 1) or in a Capability message
advertise or withdraw this capability respectively). (Capability TLV's S-bit set to 1 or 0 to advertise or withdraw this
capability respectively).
"Outbound Label Filtering" (OLF) capability is a new LDP capability, "Outbound Label Filtering Capability" TLV is a new LDP capability,
defined in accordance with LDP Capability definition guidelines defined in accordance with LDP Capability definition guidelines
[RFC5561]. The format of "Outbound Label Filtering" capability is as [RFC5561]. An LDP speaker that advertises OLF capability MUST
support "OLF Policy Status" TLV and "OLF Status" Status Code.
The format of "Outbound Label Filtering Capability" TLV is as
follows: follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| OLF Capability(IANA) | Length | |U|F| OLF Capability(IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | | |S| Reserved | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| | | |
skipping to change at page 10, line 47 skipping to change at page 11, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-++-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-++-+-+-+-+-+-+-+
Figure 5: OLF Capability TLV Figure 5: OLF Capability TLV
Where: Where:
U/F-bits: The U-bit/F-bit for the TLV MUST be set to 1/0 U/F-bits: The U-bit/F-bit for the TLV MUST be set to 1/0
respectively so that a receiver MUST silently ignore this TLV if respectively so that a receiver MUST silently ignore this TLV if
unknown to it, and continue processing the rest of the message. unknown to it, and continue processing the rest of the message.
Length: The length (in octets) of TLV following "Length" field. Length: The length (in octets) of TLV following the "Length"
The value of this field is variable because it depends on field. The value of this field is variable because it depends on
Capability-specific data [RFC5561] that follows in the TLV. Capability-specific data [RFC5561] that follows in the TLV.
There is no padding requirement at the end of this TLV in case There is no padding requirement at the end of this TLV in case
TLV does not end at Word boundary. TLV does not end at Word boundary.
S-bit: The value of S-bit [RFC5561] is set to 1 or 0 to advertise S-bit: The value of S-bit is set to 1 or 0 to advertise or
or withdraw the capability respectively. withdraw the capability respectively as specified in [RFC5561].
OLF Capability Element(s): This is the Capability-specific data OLF Capability Element(s): This is the Capability-specific data
[RFC5561] that is defined for OLF Capability, and consists of [RFC5561] that is defined for OLF Capability, and consists of
one or more "OLF Capability Element" types (defined below). one or more "OLF Capability Element" types (defined below).
An LDP speaker that advertises OLF capability MUST support "OLF
Policy Status" and "OLF Status" Status Code.
The format of an "OLF Capability Element" sub-TLV is specified as The format of an "OLF Capability Element" sub-TLV is specified as
follows: follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Elem Type | Address Family |T|R| Reserved | | FEC Elem Type | Address Family |T|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: OLF Capability Element Figure 6: OLF Capability Element
Where: Where:
FEC Elem Type / Address Family: These fields jointly represent a FEC Elem Type / Address Family: These fields jointly represent a
FEC-Type. For the FEC element types listed in Table 1 which do FEC-Type. For the FEC element types listed in Table 1 which are
not require Address Family qualification, Address-Family field not qualified with an Address Family, Address-Family field MUST
MUST be set to zero on transmit and MUST be ignored on receipt. be set to zero on transmit and MUST be ignored on receipt.
T-bit: Transmit/Send capability; set to 1 when the LDP speaker is T-bit: Transmit/Send capability; set to 1 by an LDP speaker that is
able/willing to send OLF filters to its peer, set to zero able/willing to push/send its OLF policy/filters to its peer;
otherwise. set to zero otherwise.
R-bit: Receive capability; set to 1 when the LDP speaker is R-bit: Receive capability; set to 1 by an LDP speaker that is
able/willing to receive OLF filters from its peer, set to zero able/willing to receive OLF policy/filters from its peer; set to
otherwise. zero otherwise.
Reserved: 6-bits reserved for future use. MUST be set to zero on Reserved: Reserved for future use. MUST be set to zero on transmit
transmit and MUST be ignored on receipt. and MUST be ignored on receipt.
An LDP speaker SHOULD NOT send an "OLF Capability Element" with both An LDP speaker SHOULD NOT send an "OLF Capability Element" with both
T/R bits set to zero. If an LSR receives an OLF Capability Element T/R bits set to zero when advertising the capability. If an LSR
with both T/R bits set to zero, then the receiving LSR SHOULD ignore receives an OLF Capability Element with both T/R bits set to zero in
the corresponding OLF Capability Element and continue processing the an Initialization message or in a Capability message (with S-bit set
rest of the TLV. The semantics and usage of T/R-bits is elaborated to 1), then the receiving LSR SHOULD ignore the corresponding OLF
more in following sections. Capability Element and continue processing the rest of the TLV. The
semantics and usage of T/R-bits is elaborated more in the following
sections.
There MUST be one and only one OLF Capability Element specified for a There MUST be one and only one OLF Capability Element specified for a
given FEC-Type in an OLF Capability TLV. Upon receiving more than one given FEC-Type in an OLF Capability TLV. Upon receiving more than one
OLF Capability Element for a given FEC-Type in the same "OLF OLF Capability Element for a given FEC-Type in the same "OLF
Capability TLV", the receiving LSR MUST send an LDP Notification Capability TLV", the receiving LSR MUST send an LDP Notification
message towards the sender with "Malformed TLV" status code, and message towards the sender with "Malformed TLV" status code, and
abort the processing of entire message. abort the processing of entire message.
An LSR MAY update/withdraw its OLF capability for a given FEC-Type
towards a peer by sending an OLF Capability TLV in a LDP Capability
message if both the LSR and peer support "Dynamic Capability
Announcement" capability. To update its OLF capability, the S-bit of
OLF Capability is set to 1 and OLF Capability Element is encoded
accordingly and sent to the peer. The receipt of a new OLF Capability
Element corresponding to a FEC-Type MUST be treated as overwrite of
any previously advertised capability. To withdraw its OLF capability,
the S-bit of OLF Capability is set to 0 and OLF Capability Element is
encoded with both T/R bits set to 0. The receipt of a withdrawal of a
OLF Capability Element corresponding to a FEC-Type removes any filter
installed by the sender on the receiver LSR.
4.4. OLF Procedures 4.4. OLF Procedures
To describe the OLF procedures in the following subsections, let us To describe the OLF procedures in the following subsections, let us
consider LDP speaker LSR1 that is capable of sending OLF policy consider LDP speaker LSR1 that is capable of sending OLF policy
filters (for one or more FEC types), and LSR2 that is capable of filters (for one or more FEC types), and LSR2 that is capable of
receiving (and processing) them. Let us assume that the supported receiving (and processing) them. Let us assume that the supported
FEC-Types for OLF are IPv4/IPv6 "Address Prefix FEC" OLF types. FEC-Types for OLF are IPv4/IPv6 "Address Prefix" OLF types.
Henceforth, both LSRs are configured respectively to send/receive Henceforth, both LSRs are configured respectively to send/receive
OLF filters for "IPv4/IPv6 Address Prefix" OLF types to/from its OLF filters for "IPv4/IPv6 Address Prefix" OLF types to/from its
peer. Let us also assume that the LSR1 is configured with an OLF peer. Let us also assume that the LSR1 is configured with an OLF
filtering policy for "IPv4/IPv6 Address Prefix" FEC-Types that needs filtering policy for "IPv4/IPv6 Address Prefix" FEC-Types that needs
to be pushed to LSR2. to be pushed to LSR2.
Moreover, assume that both LSR1 and LSR2 support "Dynamic Capability Moreover, assume that both LSR1 and LSR2 support "Dynamic Capability
Announcement" capability TLV [RFC5561] and hence are capable of Announcement" capability TLV [RFC5561] and hence are capable of
handling dynamic capability changes. handling dynamic capability changes.
4.4.1. OLF Capability Negotiation At Session Establishment Time 4.4.1. OLF Capability Negotiation At Session Establishment Time
At the session initialization time, LSR1 constructs an "OLF At the session initialization time, LSR1 constructs an "OLF
Capability TLV" with S-bit set to 1. The TLV also contains two OLF Capability TLV" with S-bit set to 1. The TLV also contains two OLF
Capability Elements corresponding to FEC-Types "IPv4 Address Prefix" Capability Elements corresponding to FEC-Types "IPv4 Address Prefix"
(FEC Elem Type=0x2, Address Family=0x1) and "IPv6 Address Prefix" (FEC Elem Type=2, Address Family=1) and "IPv6 Address Prefix" (FEC
(FEC Elem Type=0x2, Address Family=0x2). The LSR also sets T-bit/R- Elem Type=2, Address Family=2). The LSR also sets T-bit/R-bit of
bit of these OLF Capability Elements to 1/0 respectively. these OLF Capability Elements to 1/0 respectively.
LSR1 then includes this "OLF Capability TLV" in the LDP LSR1 then includes this "OLF Capability" TLV in the LDP
Initialization message to LSR2. Initialization message towards LSR2.
LSR2, on the other hand, constructs/sends the "OLF Capability TLV" LSR2, on the other hand, constructs/sends the "OLF Capability" TLV
in the same manner as done by LSR1; the only difference being that in the same manner as done by LSR1; the only difference being that
LSR2 sets T-bit/R-bit of its OLF Capability Elements to 0/1 LSR2 sets T-bit/R-bit of its OLF Capability Elements to 0/1
respectively. respectively.
Having exchanged/negotiated the "OLF Capability TLVs" successfully, Having exchanged/negotiated the "OLF Capability" TLVs successfully
LSR2 treats this as an implicit DENY for all label bindings for at session establishment time, LSR2 treats this as an implicit DENY
given FEC-Types (IPv4/IPv6 Prefix) and blocks any label binding for all label bindings for given FEC-Types (IPv4/IPv6 Prefix) and
advertisements towards LSR1 corresponding to these FEC-Types. LSR2 blocks any label binding advertisements towards LSR1 corresponding
now waits for subsequent OLF filters/policy (via LDP Notification to these FEC-Types. LSR2 now waits for subsequent OLF filters/policy
messages) from LSR1. LSR1 also understands that LSR2 is capable of (via LDP Notification messages) from LSR1. LSR1 also understands
receiving the OLF filters and hence it constructs OLF filters using that LSR2 is capable of receiving the OLF filters and hence it
its configured OLF policy for LSR2, and sends these filters to LSR2 constructs OLF filters using its configured OLF policy for LSR2, and
via "OLF Policy Status TLV" in an LDP Notification message (Status sends these filters to LSR2 via "OLF Policy Status" TLV in an LDP
code set to OLF Status). Upon the receipt of such an OLF policy, Notification message (Status code set to "OLF Status"). Upon the
LSR2 reacts and applies the received outbound policy in addition to receipt of such an OLF policy, LSR2 reacts and applies the received
any locally configured outbound policy, and advertises towards LSR1 outbound policy in addition to any locally configured outbound
the label bindings corresponding to the matching "permitted" policy, and advertises towards LSR1 only those label bindings that
prefixes. are "permitted" by the installed OLF policy.
Since LSR2 is operating only in Receive mode for given OLF Since LSR2 is operating only in "R" (Receive) mode for given OLF
with LSR1, LSR1 does not block the advertisements and advertises all with LSR1, LSR1 does not block the advertisements and advertises all
its label bindings for given IP Prefix FECs (in accordance with its its label bindings for given IP Prefix FECs (in accordance with its
locally configured outbound policy) towards LSR2. locally configured outbound policy) towards LSR2.
4.4.1.1. Peer Incapable of "Receive" OLF 4.4.1.1. Peer Incapable of "Receive" OLF
Consider a case where LSR2 is not OLF "Receive" capable for given Consider a case where LSR2 is not capable as OLF receiver for given
FEC-Types. This means that LSR2 either does not send any "OLF FEC-Types. This means that LSR2 either does not send any "OLF
Capability" corresponding to given FEC-Type, or "OLF Capability" for Capability" TLV corresponding to given FEC-Type, or "OLF Capability"
given FEC-Type does not have R-bit set. Having negotiated the "OLF TLV for given FEC-Type does not have R-bit set. Having negotiated
Capability" for given FEC-Types, LSR1 realizes that LSR2 is not the "OLF Capability" for given FEC-Types, LSR1 realizes that LSR2 is
capable of receiving OLF filters for given FEC-Type(s), and hence not capable of receiving OLF filters for given FEC-Type(s), and
LSR1 does not send any OLF filters (via LDP Notification message). hence LSR1 does not send any OLF filters (via LDP Notification
In this case, LSR2 sends label bindings corresponding to given FEC- message). In this case, LSR2 sends label bindings corresponding to
Type(s) towards LSR1 in unsolicited manner after session given FEC-Type(s) towards LSR1 in unsolicited manner after session
establishment, at which point, LSR1 may chose to discard them by establishment, at which point, LSR1 may chose to discard them by
applying the filtering policy in inbound direction. applying the filtering policy in inbound direction.
4.4.2. OLF Capability Dynamic Changes 4.4.2. OLF Capability Dynamic Changes
It is possible that OLF capability is enabled on an LSR after It is possible that OLF capability is enabled on an LSR after
session has already been established with the peer. To signal and session has already been established with the peer. To signal and
negotiate OLF Capability dynamically, both peers MUST support negotiate OLF Capability dynamically, both peers MUST support
"Dynamic Capability Announcement" TLV [RFC5561]. "Dynamic Capability Announcement" TLV [RFC5561].
4.4.2.1. "Send" OLF capability changes 4.4.2.1. "Send" OLF capability changes
Let's consider a case when LSR2 is initially configured to be able Let us consider a case when LSR2 is initially configured to be able
to receive OLF filters for IPv4/IPv6 Prefix FEC-Types, but LSR1 is to receive the OLF filters for IPv4/IPv6 Prefix FEC-Types, but LSR1
not configured to be able to "send" the same. Now, a user enables is not configured to be able to "send" the same. Now, a user enables
and configures LSR1 to send OLF filters for given FECs towards LSR2. and configures LSR1 to send OLF filters for given FECs towards LSR2.
This triggers LSR1 to construct an "OLF Capability" TLV in the same This triggers LSR1 to construct an "OLF Capability" TLV in the same
manner as described in section 4.4.1. The constructed "OLF manner as described in section 4.4.1. The constructed "OLF
Capability" is sent in a Capability message (with S-bit set to 1) Capability" is sent in a Capability message (with S-bit set to 1)
towards LSR2. Upon receipt of this Capability message, LSR2 towards LSR2. Upon receipt of this Capability message, LSR2
withdraws all label bindings from LSR1 corresponding to given FEC- withdraws all label bindings from LSR1 corresponding to given FEC-
Type(s). Later on, LSR1 sends its OLF filters via "OLF Policy Type(s). Later on, LSR1 sends its OLF filters via "OLF Policy
Status" and duly applied by LSR2. Status" and duly applied by LSR2.
Assuming both LSR1 and LSR2 are already engaged in OLF filtering in Assuming both LSR1 and LSR2 are already engaged in OLF filtering in
sender and receiver roles respectively for given FEC-Types. Now sender and receiver roles respectively for given FEC-Types. Now
consider that LSR1 configuration is changed to remove "send" consider that LSR1 configuration is changed to remove "send"
capability for one FEC type (say IPv4 Prefix) towards LSR2. This capability for one FEC type (say IPv4 Prefix) towards LSR2. This
triggers LSR1 to construct an "OLF Capability" TLV that includes triggers LSR1 to construct an "OLF Capability" TLV that includes
only one OLF Capability Element corresponding to "IPv4 Prefix" FEC only one OLF Capability Element corresponding to "IPv4 Prefix" FEC
type. The constructed "OLF Capability" is sent in a Capability type. The constructed "OLF Capability" is sent in a Capability
message (with S-bit set to 0) towards LSR2. Upon receipt of this message (with S-bit set to 0) towards LSR2. Upon receipt of this
Capability [withdrawal] message, LSR2 removes any existing OLF Capability [withdrawal] message, LSR2 removes any existing OLF
filter towards LSR1 corresponding to given FEC-Type "IPv4 Prefix", filters towards LSR1 corresponding to given FEC-Type "IPv4 Prefix",
and re-advertises to LSR1 its entire label bindings database for and re-advertises to LSR1 its entire label bindings database for
given FEC-Type. given FEC-Type.
4.4.2.2. "Receive" OLF capability changes 4.4.2.2. "Receive" OLF capability changes
Let's consider a case when LSR1 is initially configured to be able Let us consider a case when LSR1 is initially configured to be able
to send OLF filters for IPv4/IPv6 Prefix FEC-Types, but LSR2 is not to send OLF filters for IPv4/IPv6 Prefix FEC-Types, but LSR2 is not
configured to be able to "receive" the same. Now, a user enables and configured to be able to "receive" the same. Now, a user enables and
configures LSR2 to be able to receive OLF filters for IPv4/IPv6 configures LSR2 to be able to receive OLF filters for IPv4/IPv6
Prefix FECs from LSR1. This triggers LSR2 to construct an "OLF Prefix FECs from LSR1. This triggers LSR2 to construct an "OLF
Capability" TLV in the same manner as described in section 4.4.1. Capability" TLV in the same manner as described in section 4.4.1.
The constructed "OLF Capability" is sent in a Capability message The constructed "OLF Capability" is sent in a Capability message
(with S-bit set to 1) towards LSR1. Upon receipt of this Capability (with S-bit set to 1) towards LSR1. Upon receipt of this Capability
message, LSR1 realizes that LSR2 is now capable to receive OLF message, LSR1 realizes that LSR2 is now capable to receive OLF
filters for IPv4/IPv6 Prefix FEC types. As described in earlier filters for IPv4/IPv6 Prefix FEC types. As described in earlier
section, LSR1 now proceeds by constructing "OLF Policy Status" using section, LSR1 now proceeds by constructing "OLF Policy Status" using
its configured filters for LSR2, and sends them in an LDP its configured filters for LSR2, and sends them in an LDP
Notification message towards LSR2. Upon receipt of this message, Notification message towards LSR2. Upon receipt of this message,
LSR2 applies the received OLF policy and withdraws any label LSR2 applies the received OLF policy and withdraws any label
bindings corresponding to matching FEC (prefixes) that are no more bindings corresponding to matching FEC (prefixes) that are no more
permitted for advertisement. Later on, LSR1 can also update its OLF permitted for advertisement. Later on, LSR1 can also update its OLF
filters by pushing updates to LSR2 as/when any change in LSR1's OLF filters by pushing updates to LSR2 as/when any change in LSR1's OLF
policy occurs. policy occurs.
Assuming both LSR1 and LSR2 are already engaged in OLF filtering in Assuming both LSR1 and LSR2 are already engaged in OLF filtering in
sender and receiver roles respectively for given FEC-Types. Now sender and receiver roles respectively for given FEC-Types. Now
consider that LSR2 configuration is changed to remove "receive" consider that LSR2 configuration is changed to remove the "receive"
capability for one FEC-Type (say IPv4 Prefix) from LSR1. This capability for one FEC-Type (say IPv4 Prefix) from LSR1. This
triggers LSR2 to construct an "OLF Capability" TLV that includes triggers LSR2 to construct an "OLF Capability" TLV that includes
only one OLF Capability Element corresponding to "IPv4 Prefix" FEC only one OLF Capability Element corresponding to "IPv4 Prefix" FEC
type. The constructed "OLF Capability" is sent in a Capability type. The constructed "OLF Capability" is sent in a Capability
message (with S-bit set to 0) towards LSR1. Upon receipt of this message (with S-bit set to 0) towards LSR1. Upon receipt of this
Capability [withdrawal] message, LSR1 marks LSR2 as IPv4 Prefix FEC Capability [withdrawal] message, LSR1 marks LSR2 as IPv4 Prefix FEC
OLF "receive" incapable peer, and makes sure that no more OLF filter OLF "receive" incapable peer and makes sure that no more OLF filter
updates (via LDP Notification messages) are sent to LSR2. LSR2, updates (via LDP Notification messages) are sent to LSR2. LSR2,
after sending the Capability [withdrawal] message, now deletes any after sending the Capability [withdrawal] message, now deletes any
installed OLF filter corresponding to LSR1 for "IPv4 Prefix" FEC, installed OLF filter corresponding to LSR1 for "IPv4 Prefix" FEC,
and re advertises its entire label bindings database for "IPv4 and re advertises its entire label bindings database for "IPv4
Prefix" FEC to LSR1. Upon receipt of unwanted label bindings, LSR1 Prefix" FEC to LSR1. Upon receipt of unwanted label bindings, LSR1
may chose to discard them by applying the filtering policy in may chose to discard them by applying the filtering policy in
inbound direction. inbound direction.
4.4.3. OLF Policy Updates 4.4.3. OLF Policy Updates
skipping to change at page 16, line 24 skipping to change at page 16, line 45
If LSR1's configured OLF policy changes, LSR1 sends further updates If LSR1's configured OLF policy changes, LSR1 sends further updates
using "OLF Policy Status" in a LDP Notification message. Upon using "OLF Policy Status" in a LDP Notification message. Upon
receipt of such an update for given FEC-Type, LSR2 treats this as an receipt of such an update for given FEC-Type, LSR2 treats this as an
overwrite of the previously installed OLF filters corresponding to overwrite of the previously installed OLF filters corresponding to
LSR1, and re-applies the policy. As the result of policy re- LSR1, and re-applies the policy. As the result of policy re-
application, LSR2 advertises any new [matching] prefix being application, LSR2 advertises any new [matching] prefix being
permitted now, and withdraws any previously advertised prefixes permitted now, and withdraws any previously advertised prefixes
which are no longer permitted as per matching rules. which are no longer permitted as per matching rules.
5. Address Prefix FEC OLF Type 5. OLF Specification for "Address Prefix FEC"
Using the earlier OLF framework defined in this document, this Using the earlier OLF framework defined in this document, this
section defines the OLF type for the "Address Prefix" FEC Element section defines the OLF type for the "Address Prefix" FEC Element
type. The OLF types for other FEC Element types are beyond the scope type. The OLF types for other FEC Element types are beyond the scope
of this document. of this document.
The "Address Prefix FEC" OLF type allows one to express OLFs in The "Address Prefix FEC" OLF type allows a user to express OLFs in
terms of address prefixes. That is, it provides filtering based on terms of address prefixes. That is, it provides filtering based on
address prefixes, including prefix length or range based matching. address prefixes, including prefix length or range based matching.
To define an OLF for "Address Prefix FEC" type of given address To define an OLF for "Address Prefix FEC" type of given address
family, the FEC-Elem-Type and Address-Family fields of an OLF family, the FEC-Elem-Type and Address-Family fields of an OLF
Element are defined as follows: Element are defined as follows:
FEC-Elem-Type: 0x2 ("Address Prefix") FEC-Elem-Type: 2 ("Address Prefix")
Address-Family: 1 (IPv4) or 2 (IPv6) Address-Family: 1 (IPv4) or 2 (IPv6)
Conceptually, an "Address Prefix FEC" OLF entry for a given Address Conceptually, an "Address Prefix FEC" OLF entry for a given Address
Family consists of the fields <Action, Prefix Length, Prefix, Family consists of the fields <Action, Prefix Length, Prefix,
Minlen, Maxlen>, and hence the "Address Prefix FEC" OLF entry within Minlen, Maxlen>, and hence the "Address Prefix FEC" OLF entry within
an "Address Prefix FEC" OLF element is encoded as follows: an "Address Prefix FEC" OLF element is encoded as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Action | Rsvd | Minlen | Maxlen | Prefix Len | |Action | Rsvd | Minlen | Maxlen | Prefix Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Prefix ~ ~ Prefix ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-++-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-++-+-+-+-+-+-+-+
Figure 7: Address Prefix FEC OLF Entry Figure 7: Format of OLF Entry for Address Prefix FEC
With reference to Fig 3, the first octet of the above OLF Entry With reference to Fig 3, the first octet of the above OLF Entry
belongs to the "Common part" and the rest of the fields belong to belongs to the "Common part" and the rest of the fields belong to
the "Type-specific part" (as defined for Address Prefix FEC Element the "Type-specific part" (as defined for Address Prefix FEC Element
type). type).
As per OLF Entry rules defined earlier, if the Action component of As per OLF Entry rules defined earlier, if the Action component of
the entry specifies wildcard operation ("PERMIT-ALL"), then Address the entry specifies wildcard operation ("PERMIT-ALL"), then Address
Prefix FEC OLF Entry does not specify any type-specific data (i.e. Prefix FEC OLF Entry does not specify any type-specific data (i.e.
OLF entry size is 1 octet only). OLF entry size is 1 octet only).
The "Minlen" and "Maxlen" fields indicate respectively the minimum The "Minlen" and "Maxlen" fields indicate respectively the minimum
and the maximum prefix length in bits that is used for "matching". and the maximum prefix length in bits that is used for "matching".
Either the Minlen or Maxlen field or both may have the value 0; this Either the Minlen or Maxlen field or both may have the value 0 to
means that the value of the field is "unspecified". The Maxlen indicate that the value of the field is "unspecified". The "Maxlen"
value must not be more than the maximum length (in bits) of a host value must not be more than the maximum length (in bits) of a host
address for the given address family. address for the given address family.
The "Prefix Len" field indicates the length in bits of the address The "Prefix Len" field indicates the length in bits of the address
prefix. This field MUST NOT be specified as zero. prefix. This field MUST NOT be specified as zero.
The "Prefix" field contains an address prefix encoded according to The "Prefix" field contains an address prefix encoded according to
the given address family. the given address family.
This document imposes that values of these fields MUST satisfy the This document imposes that values of these fields MUST satisfy the
skipping to change at page 18, line 15 skipping to change at page 18, line 33
o The IP route is considered as "no match" to the OLF entry if the o The IP route is considered as "no match" to the OLF entry if the
route prefix is neither more specific than, nor equal to, the route prefix is neither more specific than, nor equal to, the
<Prefix, Prefix Len> fields of the OLF entry. <Prefix, Prefix Len> fields of the OLF entry.
o When the IP route is either more specific than, or equal to, the o When the IP route is either more specific than, or equal to, the
<Prefix, Prefix Len> fields of the OLF entry, the route is <Prefix, Prefix Len> fields of the OLF entry, the route is
considered as a match to the OLF entry only if the match conditions considered as a match to the OLF entry only if the match conditions
as listed in Table 2 are satisfied (where un-spec refers to a value as listed in Table 2 are satisfied (where un-spec refers to a value
of zero). of zero).
OLF Entry Route Prefix OLF Entry Route Prefix
Minlen Maxlen Match Condition Minlen Maxlen Match Condition
+------------------------------------------------------------------+ +-----------+------------+------------------------------------+
| un-spec. | un-spec. | Route.Prefix Len == OLF.Prefix Len | | un-spec. | un-spec. | Route.Prefix Len == OLF.Prefix Len |
| specified | un-spec. | Route.Prefix Len >= OLF.Minlen | | specified | un-spec. | Route.Prefix Len >= OLF.Minlen |
| un-spec. | specified | Route.Prefix Len <= OLF.Maxlen | | un-spec. | specified | Route.Prefix Len <= OLF.Maxlen |
| specified | specified | Route.Prefix Len >= OLF.Minlen | | specified | specified | Route.Prefix Len >= OLF.Minlen AND |
| | | AND Route.Prefix Len <= OLF.Maxlen | | | | Route.Prefix Len <= OLF.Maxlen |
+------------------------------------------------------------------+ +-----------+------------+------------------------------------+
Table 2: Address Prefix OLF Entry Matching Rules Table 2: Matching Rules for an Address Prefix OLF Entry
o When more than one Address Prefix OLF entry matches the route, the o When more than one Address Prefix OLF entry matches the route, the
"first-match" rule applies. That is, the OLF entry that is specified "first-match" rule applies. That is, the OLF entry that is specified
(and processed) first in a given OLF update (among all the matching (and processed) first in a given OLF update (among all the matching
OLF entries) is considered as the sole match, and it would determine OLF entries) is considered as the sole match, and it would determine
whether the route should be permitted or denied. whether the route should be permitted or denied.
6. Operational Examples 6. Operational Examples
6.1. Label Filtering at Area Border Router 6.1. Label Filtering at Area Border Router
skipping to change at page 19, line 31 skipping to change at page 19, line 47
b. The control plane signaling convergence for Downstream On Demand b. The control plane signaling convergence for Downstream On Demand
label distribution mode is slower than Downstream Unsolicited. label distribution mode is slower than Downstream Unsolicited.
An alternate approach to meet LSR1 requirement is to use OLF An alternate approach to meet LSR1 requirement is to use OLF
mechanics while using Downstream Unsolicited distribution mode. In mechanics while using Downstream Unsolicited distribution mode. In
this approach, LSR1 and LSR2 will negotiate OLF Capability as this approach, LSR1 and LSR2 will negotiate OLF Capability as
sender/receiver respectively, and LSR1 will install OLF filters to sender/receiver respectively, and LSR1 will install OLF filters to
limit the IPv4 label bindings sent by LSR2 to the only IPv4 prefixes limit the IPv4 label bindings sent by LSR2 to the only IPv4 prefixes
in which LSR1 is interested in. in which LSR1 is interested in.
6.3. Label Filtering an Address Family in an IP Dual-Stack LSR
The OLF mechanism specified in this document can be useful in cases
when an operator wants to filter entire address family to/from peer
in (IP) dual-stack environment. Consider that LSR2 is locally
enabled for label switching for both IPv4 and IPv6 address families,
whereas LSR1 is enabled for label switching for IPv4 address family
only. Without any filtering mechanics, LSR2 may advertise all its
label bindings for both IPv4 and IPv6 address families towards LSR1
although LSR1 is an IPv4-only LDP peer with whom hello adjacencies
and transport connection is formed using IPv4 only. In this case,
the advertisement of IPv6 addresses and labels to the peer is
unnecessary, as well as wasteful from LSR memory/CPU and network
resource consumption point of view.
To avoid this unnecessary label advertisement (for IPv6 address
family, in this example), OLF mechanics could be useful -- i.e. If
LSR1 and LSR2 supported "send" and receive OLF capability for ("IP
Prefix" FEC, IPv6 Address Family), the OLF capability could be
exchanged at the session establishment time, blocking any IPv6 label
bindings to be advertised to LSR1 until any further OLF policy
changes/updates are received and installed at LSR2. In this case,
LSR1 will not send any OLF Policy to LSR2 for IPv6 Prefix FEC type,
leaving the IPv6 label advertisement blocked/filtered (due to
implicit DENY ALL) for entire IPV6 LIB on LSR2 side.
7. Security Considerations 7. Security Considerations
The proposal introduced in this document does not introduce any new The proposal introduced in this document does not introduce any new
security considerations beyond that already apply to the base LDP security considerations beyond that already apply to the base LDP
specification [RFC5036] and [RFC5920]. specification [RFC5036] and [RFC5920].
8. IANA Considerations 8. IANA Considerations
The document introduces following new protocol elements that require The document introduces following new protocol elements that require
code point assignment by IANA: code point assignment by IANA:
o "Outbound Label Filter Capability" TLV (requested code point: o "OLF Capability" TLV (requested code point: 0x50E)
0x50E)
o "Outbound Label Filter Policy Status" TLV (requested code point: o "OLF Policy Status" TLV (requested code point: 0x50F)
0x50F)
o "Outbound Label Filter Status" status code (requested code point: o "OLF Status" status code (requested code point: 0x00000050)
0x00000050)
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC5036] Andersson, L., Menei, I., and Thomas, B., Editors, "LDP [RFC5036] L. Andersson, I. Mine, and B. Thomas, "LDP Specification",
Specification", RFC 5036, September 2007. RFC 5036, September 2007.
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and Le [RFC5561] B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, and JL. Le
Roux, JL., "LDP Capabilities", RFC 5561, July 2009. Roux, "LDP Capabilities", RFC 5561, July 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997. Requirement Levels", BCP 14, RFC2119, March 1997.
9.2. Informative References 9.2. Informative References
[RFC5920] Fang, L. et al., "Security Framework for MPLS and GMPLS [RFC5920] L. Fang, et al., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
[RFC5291] Chen, E., Rekhter, Y., "Outbound Route Filtering [RFC5291] E. Chen, Y. Rekhter, "Outbound Route Filtering Capability
Capability for BGP-4", RFC 5291, August 2008. for BGP-4", RFC 5291, August 2008.
[RFC5292] Chen, E., Sangli, S., "Address-Prefix-Based Outbound Route [RFC5292] E. Chen, S. Sangli, "Address-Prefix-Based Outbound Route
Filter for BGP-4", RFC 5292, August 2008. Filter for BGP-4", RFC 5292, August 2008.
[RFC5918] Asati, R., Minei, I., and Thomas, B. "Label Distribution [RFC5918] R. Asati, I. Minei, and B. Thomas, "Label Distribution
Protocol Typed Wildcard FEC", RFC 5918, August 2010. Protocol Typed Wildcard FEC", RFC 5918, August 2010.
[RFC4447] L. Martini, Editor, E. Rosen, El-Aawar, T. Smith, G. [RFC4447] L. Martini, E. Rosen, El-Aawar, T. Smith, and G. Heron,
Heron, "Pseudowire Setup and Maintenance using the Label "Pseudowire Setup and Maintenance using the Label
Distribution Protocol", RFC 4447, April 2006. Distribution Protocol", RFC 4447, April 2006.
[mLDP] Minei, I., Kompella, K., Wijnands, I., and Thomas, B., [RFC6388] I. Minei, I. Wijnand, K. Kompella, and B. Thomas, "LDP
"LDP Extensions for Point-to-Multipoint and Multipoint-to- Extensions for P2MP and MP2MP LSPs", RFC 6388, November
Multipoint Label Switched Paths", draft-ietf-mpls-ldp-p2mp 2011.
-10.txt, Work in Progress, July 2010.
[P2MP-PW] Martini, L., Boutros, S., Sivabalan, S., Konstantynowicz, [P2MP-PW] L. Martini, et. al, "Signaling Root-Initiated Point-to-
M., Del Vecchio, G., Nadeau, T., Jounay, F., Niger, P., Multipoint Pseudowires using LDP", draft-ietf-pwe3-p2mp-
Kamite, Y., Jin, L., Vigoureux, M., Ciavaglia, L., and pw-04.txt, Work in Progress, March 2012.
Delord, S., "Signaling Root-Initiated Point-to-Multipoint
Pseudowires using LDP", draft-ietf-pwe3-p2mp-pw-02.txt,
Work in Progress, March 2011.
10. Acknowledgments 10. Acknowledgments
The authors would like to thank Eric Rosen for his valuable input The authors would like to thank Eric Rosen for his valuable input
and comments. and comments.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses Authors' Addresses
Kamran Raza Kamran Raza
Cisco Systems, Inc., Cisco Systems, Inc.,
2000 Innovation Drive, 2000 Innovation Drive,
Kanata, ON K2K-3E8, Canada. Ottawa, ON K2K-3E8, Canada.
E-mail: skraza@cisco.com E-mail: skraza@cisco.com
Sami Boutros Sami Boutros
Cisco Systems, Inc. Cisco Systems, Inc.
3750 Cisco Way, 3750 Cisco Way,
San Jose, CA 95134, USA. San Jose, CA 95134, USA.
E-mail: sboutros@cisco.com E-mail: sboutros@cisco.com
Pradosh Mohapatra Pradosh Mohapatra
Cisco Systems, Inc. Cisco Systems, Inc.
3750 Cisco Way, 3750 Cisco Way,
San Jose, CA 95134, USA. San Jose, CA 95134, USA.
 End of changes. 94 change blocks. 
225 lines changed or deleted 265 lines changed or added

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