< draft-lu-fn-transport-02.txt   draft-lu-fn-transport-03.txt >
Network Working Group W. Lu Network Working Group W. Lu
Internet-Draft S. Kini Internet-Draft S. Kini
Intended status: Standards Track A. Csaszar, Ed. Intended status: Standards Track A. Csaszar, Ed.
Expires: January 12, 2012 G. Enyedi Expires: September 13, 2012 G. Enyedi
J. Tantsura J. Tantsura
Ericsson Ericsson
July 11, 2011 March 12, 2012
Transport of Fast Notification Messages Transport of Fast Notification Messages
draft-lu-fn-transport-02 draft-lu-fn-transport-03
Abstract Abstract
This document specifies a fast, light-weight event notification This document specifies mechanisms for fast and light-weight
protocol, called Fast Notification (FN) protocol. The draft dissemination of event notifications. The purpose is to enable
dataplane dissemination of Fast Notifications (FNs). The draft
discusses the design goals, the message container and options for discusses the design goals, the message container and options for
delivering the notifications to all routers within a routing area. delivering the notifications to all routers within a routing area.
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 http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 12, 2012. This Internet-Draft will expire on September 13, 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 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
skipping to change at page 2, line 19 skipping to change at page 2, line 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Transport Logic - Distribution of the Notifications . . . . . 4 3. Transport Logic - Distribution of the Notifications . . . . . 4
3.1. Duplicate Check . . . . . . . . . . . . . . . . . . . . . 5 3.1. Duplicate Check . . . . . . . . . . . . . . . . . . . . . 5
4. Message Encoding . . . . . . . . . . . . . . . . . . . . . . . 6 4. Message Encoding . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Seamless Encapsulation . . . . . . . . . . . . . . . . . . 6 4.1. Seamless Encapsulation . . . . . . . . . . . . . . . . . . 6
4.2. Dedicated FN Message . . . . . . . . . . . . . . . . . . . 6 4.2. Dedicated FN Message . . . . . . . . . . . . . . . . . . . 6
4.2.1. Authentication . . . . . . . . . . . . . . . . . . . . 8 4.2.1. Authentication . . . . . . . . . . . . . . . . . . . . 8
4.2.1.1. Areas-scoped and Link-scoped Authentication . . . 9 4.2.1.1. Area-scoped and Link-scoped Authentication . . . . 9
4.2.1.2. Simple Password Authentication . . . . . . . . . . 9 4.2.1.2. Simple Password Authentication . . . . . . . . . . 9
4.2.1.3. Cryptographic Authentication for FN . . . . . . . 9 4.2.1.3. Cryptographic Authentication for FN . . . . . . . 10
4.2.1.4. MD5 . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1.5. SHA256 . . . . . . . . . . . . . . . . . . . . . . 11
4.2.1.6. Digital Signatures . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. FN Packet Processing Summary . . . . . . . . . . . . . . . . . 12 6. FN Packet Processing Summary . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Further Options for Transport Logic . . . . . . . . . 14 Appendix A. Further Options for Transport Logic . . . . . . . . . 14
A.1. Multicast Tree-based Transport . . . . . . . . . . . . . . 14 A.1. Multicast Tree-based Transport . . . . . . . . . . . . . . 15
A.1.1. Fault Tolerance of a Single Distribution Tree . . . . 15 A.1.1. Fault Tolerance of a Single Distribution Tree . . . . 15
A.1.2. Pair of Redundant Trees . . . . . . . . . . . . . . . 15 A.1.2. Pair of Redundant Trees . . . . . . . . . . . . . . . 15
A.2. Unicast . . . . . . . . . . . . . . . . . . . . . . . . . 17 A.2. Unicast . . . . . . . . . . . . . . . . . . . . . . . . . 17
A.2.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 17 A.2.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 17
A.2.2. Sample Operation . . . . . . . . . . . . . . . . . . . 18 A.2.2. Sample Operation . . . . . . . . . . . . . . . . . . . 18
A.3. Gated Multicast through RPF Check . . . . . . . . . . . . 18 A.3. Gated Multicast through RPF Check . . . . . . . . . . . . 19
A.3.1. Loop Prevention - RPF Check . . . . . . . . . . . . . 19 A.3.1. Loop Prevention - RPF Check . . . . . . . . . . . . . 19
A.3.2. Operation . . . . . . . . . . . . . . . . . . . . . . 19 A.3.2. Operation . . . . . . . . . . . . . . . . . . . . . . 20
A.4. Further Multicast Tree based Transport Options . . . . . . 20 A.4. Further Multicast Tree based Transport Options . . . . . . 21
A.4.1. Source Specific Trees . . . . . . . . . . . . . . . . 20 A.4.1. Source Specific Trees . . . . . . . . . . . . . . . . 21
A.4.2. A Single Bidirectional Shared Tree . . . . . . . . . . 21 A.4.2. A Single Bidirectional Shared Tree . . . . . . . . . . 21
A.5. Layer 2 Networks . . . . . . . . . . . . . . . . . . . . . 21 A.5. Layer 2 Networks . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Draft [I-D.lu-fast-notification-framework] describes the Enabling fast dissemination of a network event to routers in a
architectural framework to enable fast dissemination of a network limited area could benefit multiple applications. Existing use cases
event to routers in a limited area. Existing use cases involve new are centered around new approaches for IP Fast ReRoute such as
approaches for IP Fast ReRoute such as [I-D.csaszar-ipfrr-fn], and [I-D.csaszar-ipfrr-fn]. In the future, however, multiple innovative
faster dissemination of link state information for routing protocols applications may take advantage of a Fast Notification service.
[I-D.kini-ospf-fast-notification] in order to speed up convergence.
A hop by hop control plane based flooding mechanism is used widely A hop by hop control plane based flooding mechanism is used widely
today in link state routing protocols such as OSPF and ISIS to today in link state routing protocols such as OSPF and ISIS to
propagate routing information throughout an area. In this mechanism, propagate routing information throughout an area. In this mechanism,
the information is processed in the control plane at each hop before the information is processed in the control plane at each hop before
being forwarded to the next. The extra processing, scheduling, and being forwarded to the next. The extra processing, scheduling, and
communications overhead causes unnecessary delays in the communications overhead causes unnecessary delays in the
dissemination of the information. dissemination of the information.
This draft proposes a generic fast notification (FN) protocol as a This draft proposes a generic fast notification (FN) protocol as a
separate transport layer, which focuses on delivering notifications separate transport layer, which focuses on delivering notifications
quickly in a secure manner. It can be used by many existing quickly in a secure manner. It can be used by many existing
applications to enhance the performance of those applications, as applications to enhance the performance of those applications, as
well as to enable new services in the network. well as to enable new services in the network. This draft does not
specify the payload of the notification. Each application is
required to create an own spec and define its payload as well as the
preferred transport options separately.
1.1. Requirements Language 1.1. Requirements Language
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].
1.2. Acronyms 1.2. Acronyms
FN - Fast Notification FN - Fast Notification
skipping to change at page 4, line 26 skipping to change at page 4, line 28
2. The signaling mechanism should offer a high degree of reliability 2. The signaling mechanism should offer a high degree of reliability
under network failure conditions. under network failure conditions.
3. The mechanism should be secure; that is, it should provide means 3. The mechanism should be secure; that is, it should provide means
to verify the authenticity of the notifications. to verify the authenticity of the notifications.
4. The new protocol should not be dependent upon routing protocol 4. The new protocol should not be dependent upon routing protocol
flooding procedures. flooding procedures.
5. The mechanism should have low processing overhead 5. The mechanism should have low processing overhead.
These design goals present a trade-off. Proper balance needs to be These design goals present a trade-off. Proper balance needs to be
found that offers good authentication and reliability while keeping found that offers good authentication and reliability while keeping
processing complexity sufficiently low to enable implementation in processing complexity sufficiently low to enable implementation in
dataplane. This draft proposes solutions that take the above goals dataplane. This draft proposes solutions that take the above goals
and trade-offs into considerations. and trade-offs into considerations.
3. Transport Logic - Distribution of the Notifications 3. Transport Logic - Distribution of the Notifications
The distribution of a notification to multiple receivers can be The distribution of a notification to multiple receivers can be
skipping to change at page 5, line 9 skipping to change at page 5, line 11
bidir multicast, all interfaces added to the multicast group can be bidir multicast, all interfaces added to the multicast group can be
incoming and outgoing interfaces as well. The principle is that a incoming and outgoing interfaces as well. The principle is that a
router replicates the incoming packet to *all* assigned interfaces router replicates the incoming packet to *all* assigned interfaces
except the incoming interface. If the local router is the source of except the incoming interface. If the local router is the source of
the packet to be forwarded, then the packet is replicated to all the packet to be forwarded, then the packet is replicated to all
interfaces. That is, the decision about which interfaces should interfaces. That is, the decision about which interfaces should
actually be used as outgoing is determined on demand. actually be used as outgoing is determined on demand.
First, the FN service is assigned a multicast group address, let us First, the FN service is assigned a multicast group address, let us
call this MC-FN address. Then, the IGP assigns all interfaces to call this MC-FN address. Then, the IGP assigns all interfaces to
MC-FN which lead to neighbouring routers. MC-FN which lead to neighbouring routers selected by the IGP.
When the FN service is instructed to disseminate a message, it When the FN service is instructed to disseminate a message, it
creates an IP packet (as described below in Section 4) and sets its creates an IP packet (as described below in Section 4) and sets its
IP destination address to the MC-FN multicast address. This IP IP destination address to the MC-FN multicast address. This IP
packet is then multicasted to all IGP neighbours in the area. packet is then multicasted to all IGP neighbours in the area.
Recipients of FN multicast-forward the packet according to the rules Recipients of FN multicast-forward the packet according to the rules
of bidirectional multicast, i.e. to all interfaces which the local of bidirectional multicast, i.e. to all interfaces which the local
IGP pre-configured except the incoming interface. As this may cause IGP pre-configured except the incoming interface. As this may cause
loops without pre-caution (consider three routers in a triangle). loops without pre-caution (consider three routers in a triangle),
Before forwarding, therefore, the forwarding engine has to perform before forwarding, therefore, the forwarding engine has to perform
duplicate check. duplicate check.
3.1. Duplicate Check 3.1. Duplicate Check
Duplicate check can be performed in numeruous ways. Duplicate check can be performed in numeruous ways.
Duplicate check can be performed by maintaining a short queue of Duplicate check can be performed by maintaining a short queue of
previously forwarded FN messages. Before forwarding, if the FN previously forwarded FN messages. Before forwarding, if the FN
message is found in the queue, then it was forwarded beforehand, so message is found in the queue, then it was forwarded beforehand, so
it may be dropped. Otherwise it should be forwarded and it should be it may be dropped. Otherwise it should be forwarded and it should be
skipping to change at page 5, line 50 skipping to change at page 6, line 4
can be set to a value that corresponds to the maximal number of legal can be set to a value that corresponds to the maximal number of legal
FN messages generated by a single event. For instance, if FN is used FN messages generated by a single event. For instance, if FN is used
to broadcast failure identifiers in case of failures, then it is to broadcast failure identifiers in case of failures, then it is
likely that the failure of the node with the most neighbours will likely that the failure of the node with the most neighbours will
trigger the most FN messages (1 from each neighbour). trigger the most FN messages (1 from each neighbour).
It is also possible to use application-dependent duplicate check: the It is also possible to use application-dependent duplicate check: the
state machine of the FN-application can be left responsible to decide state machine of the FN-application can be left responsible to decide
whether the information carried in the packet contains new whether the information carried in the packet contains new
information or it is a duplicate. This is only useful in the case if information or it is a duplicate. This is only useful in the case if
the application can perform the duplicate check faster then the above the application can perform the duplicate check more efficiently than
generic mechanisms. the above generic mechanisms. Presently, [I-D.csaszar-ipfrr-fn]
specifies an application-specific duplicate check procedure.
4. Message Encoding 4. Message Encoding
4.1. Seamless Encapsulation 4.1. Seamless Encapsulation
An application may define its own message for FN to distribute An application may define its own message for FN to distribute
quickly. In this case, only the special destination address (e.g. quickly. In this case, only the special destination address (e.g.
MC-FN) shows that the message was sent using the FN service. MC-FN) shows that the message was sent using the FN service.
In this case, the entire payload of the IP packet is determined by In this case, the entire payload of the IP packet is determined by
skipping to change at page 8, line 28 skipping to change at page 8, line 28
AuType AuType
Identifies the authentication procedure to be used for the packet. Identifies the authentication procedure to be used for the packet.
Authentication options are discussed in Section 4.2.1 of the Authentication options are discussed in Section 4.2.1 of the
specification. specification.
4.2.1. Authentication 4.2.1. Authentication
Fast Notification intends to provide a trustable service option, so Fast Notification intends to provide a trustable service option, so
that receivers of FN packets are able to verify that the packet is that receivers of FN packets are able to verify that the packet is
sent by an authentic source. Simple password authentication and hash sent by an authentic source. Simple password authentication and hash
based authentication methods (with Md5 or SHA256) are described in based authentication methods (with MD5 or SHA256) are described in
the following subsections. the following subsections.
If AuType is set to 0x0, then the FN packet is not carrying an If AuType is set to 0x0, then the FN packet is not carrying an
Authentication field at the end of the packet. If AuType is zero, Authentication field at the end of the packet. Note that even in
AuLength must also be zero. Note that even in this case the FN this case the FN application in the payload may still use its own
application in the payload may still use its own authentication authentication mechanism.
mechanism.
If AuType is non null, an Authentication field must be appended after If AuType is non null, an Authentication field must be appended after
the FN message. The encoding of this field is as described below. the FN message. The encoding of this field is as described below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AuLength | ... Authentication Data ... | | AuLength | ... Authentication Data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
Figure 3: Authentication field in FN packets Figure 3: Authentication field in FN packets
AuLength AuLength
Describes the length of the entire Authentication field in bytes. Describes the length of the entire Authentication field in bytes.
4.2.1.1. Areas-scoped and Link-scoped Authentication The authentication type may be manually pre-configured or may be
selected automatically. For automatic selection, the nodes have to
know what type of authentication is applicable for the rest of the
nodes. This may achieved by extending the IGP to advertise the FN
authentication capabilities. The most straightforward way to achieve
this is to extend the Router Capability TLVs available both in OSPF
[RFC4970] and in IS-IS [RFC4971].
4.2.1.1. Area-scoped and Link-scoped Authentication
Since FN is a solution to disseminate an event notification from one Since FN is a solution to disseminate an event notification from one
source to a whole area of nodes, the simplest approach would be to source to a whole area of nodes, the simplest approach would be to
use per-area authentication, for example. a common password, a common use per-area authentication, e.g., a common password, a common pre-
pre- shared key among all nodes in the area as described in the shared key among all nodes in the area as described in the following
following sub-sections, or digital signatures. sub-sections, or digital signatures.
Carriers may, however, prefer per-link authentication. In order not Carriers may, however, prefer per-link authentication. In order not
to lose the speed (simple per-hop processing, fast forwarding to lose the speed (simple per-hop processing, fast forwarding
property) of FN, link-scoped authentication is suggested only if the property) of FN, link-scoped authentication is suggested only if the
forwarding plane supports it, i.e. if there is hardware support to forwarding plane supports it, i.e. if there is hardware support to
verify and re-generate authentication hop-by-hop. In such cases, the verify and re-generate authentication hop-by-hop. In such cases, the
operator may need to configure a common pre-shared key only on operator may need to configure a common pre-shared key only on
routers connected by the same link. It is even possible that there routers connected by the same link. It is even possible that there
is no authentication on some links considered safe. is no authentication on some links considered safe.
skipping to change at page 10, line 5 skipping to change at page 10, line 13
anyone with physical access to the network can read the password. anyone with physical access to the network can read the password.
4.2.1.3. Cryptographic Authentication for FN 4.2.1.3. Cryptographic Authentication for FN
Using this authentication type, a secret key is used to generate/ Using this authentication type, a secret key is used to generate/
verify a "message digest" that is appended to the end of the FN verify a "message digest" that is appended to the end of the FN
packet. The message digest is a one-way function of the FN packet packet. The message digest is a one-way function of the FN packet
and the secret key. This authentication mechanism resembles the and the secret key. This authentication mechanism resembles the
cryptographic authentication mechanism of [RFC2328]. cryptographic authentication mechanism of [RFC2328].
4.2.1.4. MD5 4.2.1.3.1. MD5
The packet signature is created by an MD5 hash performed on an object The packet signature is created by an MD5 hash performed on an object
which is the concatenation of the FN message, including the FN which is the concatenation of the FN message, including the FN
header, and the pre-shared secret key. The resulting 16 byte MD5 header, and the pre-shared secret key. The resulting 16 byte MD5
message digest is appended to the FN message into the Authentication message digest is appended to the FN message into the Authentication
field as shown below. field as shown below.
The AuType in the FN header is set to indicate cryptographic The AuType in the FN header is set to indicate cryptographic
authentication, the specific value is to be assigned by IANA both for authentication, the specific value is to be assigned by IANA both for
area-scoped and for link-scoped versions. area-scoped and for link-scoped versions.
skipping to change at page 11, line 10 skipping to change at page 11, line 21
authentication, then the last 20 bytes of the FN message are set authentication, then the last 20 bytes of the FN message are set
aside. The recipient forwarding plane element calculates a new MD5 aside. The recipient forwarding plane element calculates a new MD5
digest of the remainder of the FN message to which it appends its own digest of the remainder of the FN message to which it appends its own
known secret key identified by Key ID. The calculated and received known secret key identified by Key ID. The calculated and received
digests are compared. In case of mismatch, the FN message is digests are compared. In case of mismatch, the FN message is
discarded. discarded.
In per-link authentication mode, the Authentication field must be In per-link authentication mode, the Authentication field must be
regenerated hop-by-hop using the key of the outgoing link. regenerated hop-by-hop using the key of the outgoing link.
4.2.1.5. SHA256 4.2.1.3.2. SHA256
Similarly to how MD5 authentication works, it is possible to use Similarly to how MD5 authentication works, it is possible to use
Secure Hash 256 hash. Currently this is a more secure hash function Secure Hash 256 hash. Currently this is a more secure hash function
than MD5. The Authentication field would look like this: than MD5. The Authentication field would look like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AuLength | Key ID | Unused | | AuLength | Key ID | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 12 skipping to change at page 12, line 26
authentication, then the last 68 bytes of the FN message are set authentication, then the last 68 bytes of the FN message are set
aside. The recipient forwarding plane element calculates a new aside. The recipient forwarding plane element calculates a new
SHA256 digest of the remainder of the FN message to which it appends SHA256 digest of the remainder of the FN message to which it appends
its own known secret key identified by Key ID. The calculated and its own known secret key identified by Key ID. The calculated and
received digests are compared. In case of mismatch, the FN message received digests are compared. In case of mismatch, the FN message
is discarded. is discarded.
In per-link authentication mode, the Authentication field must be In per-link authentication mode, the Authentication field must be
regenerated hop-by-hop using the key of the outgoing link. regenerated hop-by-hop using the key of the outgoing link.
4.2.1.6. Digital Signatures 4.2.1.3.3. Digital Signatures
A router may choose to use public key cryptography to digitally sign A router may choose to use public key cryptography to digitally sign
the notification to provide certification of authenticity. This the notification to provide certification of authenticity. This
mechanism can avoid shared secret that is required for other mechanism can avoid shared secret that is required for other
authentication mechanisms described in this document. This authentication mechanisms described in this document. This
authentication mechanism resembles the authentication mechanism of authentication mechanism resembles the authentication mechanism of
OSPF with digital signatures as defined in [RFC2154]. OSPF with digital signatures as defined in [RFC2154].
5. Security Considerations 5. Security Considerations
skipping to change at page 14, line 5 skipping to change at page 14, line 18
for their review and comments. Also thanks to Alia Atlas for for their review and comments. Also thanks to Alia Atlas for
constructive feedback. constructive feedback.
9. References 9. References
9.1. Normative References 9.1. Normative References
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S.
Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 4970, July 2007.
[RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate
System to Intermediate System (IS-IS) Extensions for
Advertising Router Information", RFC 4971, July 2007.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR- "Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, October 2007. PIM)", RFC 5015, October 2007.
9.2. Informative References 9.2. Informative References
[Eny2009] Enyedi, G., Retvari, G., and A. Csaszar, "On Finding [Eny2009] Enyedi, G., Retvari, G., and A. Csaszar, "On Finding
Maximally Redundant Trees in Strictly Linear Time, IEEE Maximally Redundant Trees in Strictly Linear Time, IEEE
Symposium on Computers and Communications (ISCC)", 2009. Symposium on Computers and Communications (ISCC)", 2009.
[I-D.csaszar-ipfrr-fn] [I-D.csaszar-ipfrr-fn]
Kini, S., Csaszar, A., and G. Envedi, "IP Fast Re-Route Csaszar, A., Tantsura, J., Kini, S., Sucec, J., and S.
with Fast Notification", draft-csaszar-ipfrr-fn-00 (work Das, "IP Fast Re-Route with Fast Notification",
in progress), March 2011. draft-csaszar-ipfrr-fn-02 (work in progress),
October 2011.
[I-D.kini-ospf-fast-notification]
Kini, S., Lu, W., and A. Tian, "OSPF Fast Notification",
draft-kini-ospf-fast-notification-01 (work in progress),
March 2011.
[I-D.lu-fast-notification-framework]
Lu, W., Tian, A., and S. Kini, "Fast Notification
Framework", draft-lu-fast-notification-framework-00 (work
in progress), October 2010.
[RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with
Digital Signatures", RFC 2154, June 1997. Digital Signatures", RFC 2154, June 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
Appendix A. Further Options for Transport Logic Appendix A. Further Options for Transport Logic
The options described in this appendix represent alternative The options described in this appendix represent alternative
solutions to the flooding based approach described in Section solutions to the flooding based approach described in Section
Section 3. Section 3.
It is left for WG discussion and further evaluation to decide whether It is left for WG discussion and further evaluation to decide whether
any of these options should potentially be preferred instead of any of these options should potentially be preferred instead of
redundant trees. redundant trees.
 End of changes. 30 change blocks. 
62 lines changed or deleted 69 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/