draft-ietf-p2psip-rpr-08.txt   draft-ietf-p2psip-rpr-09.txt 
P2PSIP N. Zong, Ed. P2PSIP N. Zong, Ed.
Internet-Draft X. Jiang Internet-Draft X. Jiang
Intended status: Standards Track R. Even Intended status: Standards Track R. Even
Expires: January 16, 2014 Huawei Technologies Expires: February 15, 2014 Huawei Technologies
Y. Zhang Y. Zhang
CoolPad CoolPad
July 15, 2013 August 14, 2013
An extension to RELOAD to support Relay Peer Routing An extension to RELOAD to support Relay Peer Routing
draft-ietf-p2psip-rpr-08 draft-ietf-p2psip-rpr-09
Abstract Abstract
This document proposes an optional extension to RELOAD to support This document proposes an optional extension to RELOAD to support
relay peer routing mode. RELOAD recommends symmetric recursive relay peer routing mode. RELOAD recommends symmetric recursive
routing for routing messages. The new optional extension provides a routing for routing messages. The new optional extension provides a
shorter route for responses reducing the overhead on intermediate shorter route for responses reducing the overhead on intermediate
peers and describes the potential use cases where this extension can peers and describes the potential use cases where this extension can
be used. be used.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 16, 2014. This Internet-Draft will expire on February 15, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 13, line 21 skipping to change at page 13, line 21
(RELOAD) Base Protocol", draft-ietf-p2psip-base-26 (work in (RELOAD) Base Protocol", draft-ietf-p2psip-base-26 (work in
progress), February 2013. progress), February 2013.
12.2. Informative References 12.2. Informative References
[RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery
Using STUN", RFC5780, May 2010. Using STUN", RFC5780, May 2010.
[I-D.ietf-p2psip-drr] Zong, N., Jiang, X., Even, R. and Zhang, Y., [I-D.ietf-p2psip-drr] Zong, N., Jiang, X., Even, R. and Zhang, Y.,
"An extension to RELOAD to support Direct Response Routing", draft- "An extension to RELOAD to support Direct Response Routing", draft-
ietf-p2psip-drr-07, June 2013. ietf-p2psip-drr-09, August 2013.
[I-D.ietf-p2psip-concepts] Bryan, D., Matthews, P., Shim, E., Willis, [I-D.ietf-p2psip-concepts] Bryan, D., Matthews, P., Shim, E., Willis,
D., and S. Dawkins, "Concepts and Terminology for Peer to Peer SIP", D., and S. Dawkins, "Concepts and Terminology for Peer to Peer SIP",
draft-ietf-p2psip-concepts-04 (work in progress), October 2011. draft-ietf-p2psip-concepts-04 (work in progress), October 2011.
[RFC3424] Daigle, L., "IAB Considerations for UNilateral Self-Address
Fixing (UNSAF) Across Network Address Translation", RFC3424, November
2002.
13. References 13. References
Appendix A. Optional methods to investigate peer connectivity Appendix A. Optional methods to investigate peer connectivity
This section is for informational purposes only for providing some This section is for informational purposes only for providing some
mechanisms that can be used when the configuration information does mechanisms that can be used when the configuration information does
not specify if RPR can be used. It summarizes some methods which can not specify if RPR can be used. It summarizes some methods which can
be used for a peer to determine its own network location compared be used for a peer to determine its own network location compared
with NAT. These methods may help a peer to decide which routing mode with NAT. These methods may help a peer to decide which routing mode
it may wish to try. Note that there is no foolproof way to determine it may wish to try. Note that there is no foolproof way to determine
if a peer is publically reachable, other than via out-of-band if a peer is publically reachable, other than via out-of-band
mechanisms. As such, peers using these mechanisms may be able to mechanisms. This document addresses the UNSAF [RFC3424] concerns by
optimize traffic, but must be able to fall back to SRR routing if the specifying a fallback plan to SRR [p2psip-base-draft]. SRR is not an
other routing mechanisms fail. UNSAF mechanism. The document does not define any new UNSAF
mechanisms.
For RPR to function correctly, a peer may attempt to determine For RPR to function correctly, a peer may attempt to determine
whether it is publicly reachable. If it is not, RPR may be chosen to whether it is publicly reachable. If it is not, RPR may be chosen to
route the response with the help from relay peers, or the peers route the response with the help from relay peers, or the peers
should fall back to SRR. NATs and firewalls are two major should fall back to SRR. NATs and firewalls are two major
contributors preventing RPR from functioning properly. There are a contributors preventing RPR from functioning properly. There are a
number of techniques by which a peer can get its reflexive address on number of techniques by which a peer can get its reflexive address on
the public side of the NAT. After obtaining the reflexive address, a the public side of the NAT. After obtaining the reflexive address, a
peer can perform further tests to learn whether the reflexive address peer can perform further tests to learn whether the reflexive address
is publicly reachable. If the address appears to be publicly is publicly reachable. If the address appears to be publicly
 End of changes. 7 change blocks. 
8 lines changed or deleted 13 lines changed or added

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