draft-ietf-softwire-mesh-framework-04.txt   draft-ietf-softwire-mesh-framework-05.txt 
Network Working Group J. Wu Network Working Group J. Wu
Internet Draft Y. Cui Internet Draft Y. Cui
Intended Status: Standards Track X. Li Intended Status: Standards Track X. Li
Expires: September 31, 2008 Tsinghua University Expires: March 18, 2009 Tsinghua University
C. Metz C. Metz
E. Rosen (Editor) E. Rosen (Editor)
S. Barber S. Barber
P. Mohapatra P. Mohapatra
Cisco Systems, Inc. Cisco Systems, Inc.
J. Scudder J. Scudder
Juniper Networks, Inc. Juniper Networks, Inc.
March 31, 2008 September 18, 2008
Softwire Mesh Framework Softwire Mesh Framework
draft-ietf-softwire-mesh-framework-04.txt draft-ietf-softwire-mesh-framework-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 14, line 49 skipping to change at page 14, line 49
requirements described in this document. E.g., QoS or security requirements described in this document. E.g., QoS or security
considerations might require the use of point-to-point tunnels. So considerations might require the use of point-to-point tunnels. So
point-to-point tunnels are allowed, but not required, by this point-to-point tunnels are allowed, but not required, by this
framework. framework.
If it is desired to use a particular tunneling technology for the If it is desired to use a particular tunneling technology for the
softwires, and if that technology has its own "native" signaling softwires, and if that technology has its own "native" signaling
methodology, the presumption is that the native signaling will be methodology, the presumption is that the native signaling will be
used. This would certainly apply to MPLS-based softwires, where LDP used. This would certainly apply to MPLS-based softwires, where LDP
or RSVP-TE would be used. A softwire based on IPsec would use or RSVP-TE would be used. A softwire based on IPsec would use
standard IKE (Internet Key Exchange) [RFC4306] and IPsec [RFC4301] standard IKEv2 (Internet Key Exchange) [RFC4306] and IPsec [RFC4301]
signaling, as that is necessary in order to guarantee the softwire's signaling, as that is necessary in order to guarantee the softwire's
security properties. security properties.
A Softwire based on GRE might or might not require signaling, A Softwire based on GRE might or might not require signaling,
depending on whether various optional GRE header fields are to be depending on whether various optional GRE header fields are to be
used. GRE does not have any "native" signaling, so for those cases, used. GRE does not have any "native" signaling, so for those cases,
a signaling procedure needs to be developed to support Softwires. a signaling procedure needs to be developed to support Softwires.
Another possible softwire technology is L2TPv3. While L2TPv3 does Another possible softwire technology is L2TPv3. While L2TPv3 does
have its own native signaling, that signaling sets up point-to-point have its own native signaling, that signaling sets up point-to-point
skipping to change at page 17, line 4 skipping to change at page 17, line 4
which support, say, both GRE and L2TPv3, but others of which support which support, say, both GRE and L2TPv3, but others of which support
only one of those techniques. It is desirable therefore to allow the only one of those techniques. It is desirable therefore to allow the
network administration to create a small set of classes, and to network administration to create a small set of classes, and to
configure each AFBR to be a member of one or more of these classes. configure each AFBR to be a member of one or more of these classes.
Then the routers can advertise their class memberships to each other, Then the routers can advertise their class memberships to each other,
and the encapsulation policies can be expressed as, e.g., "use L2TPv3 and the encapsulation policies can be expressed as, e.g., "use L2TPv3
to talk to routers in class X, use GRE to talk to routers in class to talk to routers in class X, use GRE to talk to routers in class
Y". To support such policies, it is necessary for the AFBRs to be Y". To support such policies, it is necessary for the AFBRs to be
able to advertise their class memberships. [ENCAPS-SAFI] specifies a able to advertise their class memberships. [ENCAPS-SAFI] specifies a
way in which an AFBR may advertise, to other AFBRS, various way in which an AFBR may advertise, to other AFBRS, various
characteristics which may be relevant to the polcy (e.g., "I belong characteristics which may be relevant to the policy (e.g., "I belong
to class Y"). In many cases, these characteristics can be to class Y"). In many cases, these characteristics can be
represented by arbitrarily selected communities or extended represented by arbitrarily selected communities or extended
communities, and the policies at the ingress can be expressed in communities, and the policies at the ingress can be expressed in
terms of these classes (i.e., communities). terms of these classes (i.e., communities).
Policy may also require a certain class of traffic to receive a Policy may also require a certain class of traffic to receive a
certain quality of service, and this may impact the choice of tunnel certain quality of service, and this may impact the choice of tunnel
and/or tunneling technology used for packets in that class. This and/or tunneling technology used for packets in that class. This
framework allows a variety of tunneling technologies to be used for framework allows a variety of tunneling technologies to be used for
instantiating softwires. The choice of tunneling technology is a instantiating softwires. The choice of tunneling technology is a
skipping to change at page 18, line 16 skipping to change at page 18, line 16
If the tunnel technology being used is L2TPv3 or GRE with optional If the tunnel technology being used is L2TPv3 or GRE with optional
header fields, additional information from the remote endpoint is header fields, additional information from the remote endpoint is
needed in order to form the encapsulation header. The procedures for needed in order to form the encapsulation header. The procedures for
sending and receiving this information are described in [ENCAPS- sending and receiving this information are described in [ENCAPS-
SAFI]. SAFI].
If the tunnel technology being used is RSVP-TE-based MPLS or IPsec, If the tunnel technology being used is RSVP-TE-based MPLS or IPsec,
the native signaling procedures of those technologies will need to be the native signaling procedures of those technologies will need to be
used. used.
IPsec procedures will be discussed further in a subsequent revision
of this document.
RSVP-TE procedures will be discussed in companion documents.
If the packet being sent through the softwire matches a route in the If the packet being sent through the softwire matches a route in the
labeled IPv4 or labeled IPv6 address families, it should be sent labeled IPv4 or labeled IPv6 address families, it should be sent
through the softwire as an MPLS packet with the corresponding label. through the softwire as an MPLS packet with the corresponding label.
Note that most of the tunneling technologies mentioned in this Note that most of the tunneling technologies mentioned in this
document are capable of carrying MPLS packets, so this does not document are capable of carrying MPLS packets, so this does not
presuppose support for MPLS in the core routers. presuppose support for MPLS in the core routers.
10. Softwire OAM and MIBs 10. Softwire OAM and MIBs
10.1. Operations and Maintenance (OAM) 10.1. Operations and Maintenance (OAM)
skipping to change at page 28, line 4 skipping to change at page 28, line 4
used to to carry MPLS packets through an IPsec Security Association, used to to carry MPLS packets through an IPsec Security Association,
but first encapsulating the MPLS packets in MPLS-in-IP or MPLS-in-GRE but first encapsulating the MPLS packets in MPLS-in-IP or MPLS-in-GRE
[RFC4023] and then applying IPsec transport mode. [RFC4023] and then applying IPsec transport mode.
When IPsec is used to secure softwires, IPsec MUST provide When IPsec is used to secure softwires, IPsec MUST provide
authentication and integrity. Thus, the implementation MUST support authentication and integrity. Thus, the implementation MUST support
either ESP (IP Encapsulating Security Payload) with null encryption either ESP (IP Encapsulating Security Payload) with null encryption
[RFC4303] or else AH (IP Authentication Header) [RFC4302]. ESP with [RFC4303] or else AH (IP Authentication Header) [RFC4302]. ESP with
encryption MAY be supported. If ESP is used, the tunnel tail MUST encryption MAY be supported. If ESP is used, the tunnel tail MUST
check that the source IP address of any packet received on a given SA check that the source IP address of any packet received on a given SA
(IPsec Security Association) is the one expected. (IPsec Security Association) is the one expected, as specified in
[RFC4301] section 5.2 step 4.
Since the softwires are set up dynamically as a byproduct of passing Since the softwires are set up dynamically as a byproduct of passing
routing information, key distribution MUST be done automatically by routing information, key distribution MUST be done automatically by
means of IKE [RFC4306], operating in main mode with preshared keys. means of IKEv2 [RFC4306], operating in main mode with preshared keys.
If a PKI (Public Key Infrastructure) is not available, the IPsec If a PKI (Public Key Infrastructure) is not available, the IPsec
Tunnel Authenticator sub-TLV described in [ENCAPS-IPSEC] MUST be used Tunnel Authenticator sub-TLV described in [ENCAPS-IPSEC] MUST be used
and validated before setting up an SA. and validated before setting up an SA.
The selectors associated with the SA are the source and destination The selectors associated with the SA are the source and destination
addresses of the encapsulation header, along with the IP protocol addresses of the encapsulation header, along with the IP protocol
number representing the encapsulation protocol being used. number representing the encapsulation protocol being used.
15. Acknowledgments 15. Acknowledgments
David Ward, Chris Cassar, Gargi Nalawade, Ruchi Kapoor, Pranav Mehta, David Ward, Chris Cassar, Gargi Nalawade, Ruchi Kapoor, Pranav Mehta,
Mingwei Xu and Ke Xu provided useful input into this document. Mingwei Xu and Ke Xu provided useful input into this document.
16. Normative References 16. Normative References
[ENCAPS-IPSEC] "BGP IPSec Tunnel Encapsulation Attribute", L. Berger, [ENCAPS-IPSEC] "BGP IPSec Tunnel Encapsulation Attribute", L. Berger,
R. White, E. Rosen, draft-ietf-softwire-encaps-ipsec-00.txt, March R. White, E. Rosen, draft-ietf-softwire-encaps-ipsec-01.txt, April
2008. 2008.
[ENCAPS-SAFI] "BGP Information SAFI and BGP Tunnel Encapsulation [ENCAPS-SAFI] "BGP Information SAFI and BGP Tunnel Encapsulation
Attribute", P. Mohapatra and E. Rosen, draft-ietf-softwire-encaps- Attribute", P. Mohapatra and E. Rosen, draft-ietf-softwire-encaps-
safi-00.txt, January 2008. safi-03.txt, June 2008.
[RFC2003] "IP Encapsulation within IP", C. Perkins, October 1996. [RFC2003] "IP Encapsulation within IP", C. Perkins, October 1996.
[RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels",
S. Bradner, March 1997. S. Bradner, March 1997.
[RFC2784] "Generic Routing Encapsulation (GRE)", D. Farinacci, T. Li, [RFC2784] "Generic Routing Encapsulation (GRE)", D. Farinacci, T. Li,
S. Hanks, D. Meyer, P. Traina, RFC 2784, March 2000. S. Hanks, D. Meyer, P. Traina, RFC 2784, March 2000.
[RFC3031] "Multiprotocol Label Switching Architecture", E. Rosen, A. [RFC3031] "Multiprotocol Label Switching Architecture", E. Rosen, A.
skipping to change at page 29, line 12 skipping to change at page 29, line 13
Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209,
December 2001. December 2001.
[RFC3931] J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling [RFC3931] J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC4023] "Encapsulating MPLS in IP or Generic Routing Encapsulation [RFC4023] "Encapsulating MPLS in IP or Generic Routing Encapsulation
(GRE)", T. Worster, Y. Rekhter, E. Rosen, RFC 4023, March 2005. (GRE)", T. Worster, Y. Rekhter, E. Rosen, RFC 4023, March 2005.
[V4NLRI-V6NH] F. Le Faucheur, E. Rosen, "Advertising an IPv4 NLRI [V4NLRI-V6NH] F. Le Faucheur, E. Rosen, "Advertising an IPv4 NLRI
with an IPv6 Next Hop", draft-ietf-softwire-v4nlri-v6nh-00.txt, with an IPv6 Next Hop", draft-ietf-softwire-v4nlri-v6nh-01.txt, April
January 2008. 2008.
[V6NLRI-V4NH] J. De Clercq, D. Ooms, S. Prevost, F. Le Faucheur, [V6NLRI-V4NH] J. De Clercq, D. Ooms, S. Prevost, F. Le Faucheur,
"Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge "Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge
Routers (6PE)", RFC 4798, February 2007. Routers (6PE)", RFC 4798, February 2007.
17. Informative References 17. Informative References
[BFD] D. Katz and D. Ward, "Bidirectional Forwarding Detection", [BFD] D. Katz and D. Ward, "Bidirectional Forwarding Detection",
draft-ietf-bfd-base-08.txt, March 2008. draft-ietf-bfd-base-08.txt, March 2008.
[L3VPN-MCAST], "Multicast in MPLS/BGP IP VPNs", E. Rosen, R. [L3VPN-MCAST], "Multicast in MPLS/BGP IP VPNs", E. Rosen, R.
Aggarwal, draft-ietf-l3vpn-2547bis-mcast-06.txt, January 2008. Aggarwal, draft-ietf-l3vpn-2547bis-mcast-07.txt, July 2008.
[L3VPN-MCAST-BGP], "BGP Encodings and Procedures for Multicast in [L3VPN-MCAST-BGP], "BGP Encodings and Procedures for Multicast in
MPLS/BGP IP VPNs", R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, C. MPLS/BGP IP VPNs", R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, C.
Kodeboniya, draft-ietf-l3vpn-2547bis-mcast-bgp-04.txt, November 2007. Kodeboniya, draft-ietf-l3vpn-2547bis-mcast-bgp-05.txt, June 2008.
[MLDP] "Label Distribution Protocol Extensions for Point-to- [MLDP] "Label Distribution Protocol Extensions for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched Paths", I. Multipoint and Multipoint-to-Multipoint Label Switched Paths", I.
Minei, K. Kompella, IJ. Wijnands, B. Thomas, draft-ietf-mpls-ldp- Minei, K. Kompella, IJ. Wijnands, B. Thomas, draft-ietf-mpls-ldp-
p2mp-04, February 2008. p2mp-05.txt, June 2008.
[RFC1195] "Use of OSI IS-IS for Routing in TCP/IP and Dual [RFC1195] "Use of OSI IS-IS for Routing in TCP/IP and Dual
Environments", R. Callon, RFC 1195, December 1990. Environments", R. Callon, RFC 1195, December 1990.
[RFC2328] J. Moy, "OSPF Version 2", RFC 2328, April 1998. [RFC2328] J. Moy, "OSPF Version 2", RFC 2328, April 1998.
[RFC2385] "Protection of BGP Sessions via the TCP MD5 Signature [RFC2385] "Protection of BGP Sessions via the TCP MD5 Signature
Option", A. Heffernan, RFC 2385, August 1998. Option", A. Heffernan, RFC 2385, August 1998.
[RFC4176] Y. El Mghazli, T. Nadeau, M. Boucadair, K. Chan, A. [RFC4176] Y. El Mghazli, T. Nadeau, M. Boucadair, K. Chan, A.
 End of changes. 14 change blocks. 
19 lines changed or deleted 15 lines changed or added

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