Stockholm IETF Code Sprint
Stockholm IETF Code Sprint When: July 15, 2009, begining at 9:30 AM Where: IETF Hotel in Stockholm What: A bunch of hackers get together to work on code for the IETF web site. Some people may be porting of existing functionality to the new framework; some people may be adding exciting new functionality. All code will become part of the open source IETF tools. Who: Hopefully you can help Chris Newman will be helping with advance planning. Henrik Levkowetz will be coordinating the event in Stockholm. You will hear more from them shortly. Many of the results of the last code sprint are being used every day. Please support the tools development effort, Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
[no subject]
Dear Sir or Madam, Is there a working group on converging legacy protocol stacks and mapping legacy stacks addressing mechanisms into IPv6 addressing? For example, RFC 4291 4038 specifies that :::x.y.z.w represents IPv4 node x.y.z.w - is there a similar draft concept for specifying a Message Transfer Part point code for an SS7 stack or other telephony protocol network layer mechanisms into IPv6 addresses? Thanks much, -Jim Hanley \^^^/ (0 0) ***ooO*(_)*Ooo Jim HanleyREDCOM Laboratories, Inc. Software Engineer 1 Redcom Cntr __ T +1.585.924.7550 Victor, NY / __ /\/ ___/\ F +1.585.924.654714564 ___/ /\/ /_/ /\__\/ jim_han...@redcom.com USA /_/ /___/ / http://www.redcom.com/\_\/\___\/ *Oooo. .oooO ( ) ( ) ) / \ ( (_/ \_) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: SS7
Jim, Telco has a goal of maintaining 5 9's where SCTP was developed to carry their SS7 protocol. The FreeBSD stack for SCTP supports IPv4, IPv6 and multi-homing. This protocol immediately recovers from network path failures as it heartbeats against alternative paths. The protocol can sustain a large number of connections over extended periods, takes less time for connection setup than TCP, and overall latency can be less than UDP while still supporting partial reliability. SCTP has improved error detection suitable for jumbo frames. In addition, the error checking algorithm is now an instruction in i7 core Intel processors and is found in many NICs. The SCTP connection setup returns a cookie to minimize resource exhaustion concerns, to guard against source address spoofing, connection hijacking, and DDoS attacks. http://www.iec.org/online/tutorials/ss7_over/index.asp -Doug On May 20, 2009, at 6:04 AM, jhan...@redcom.com wrote: Dear Sir or Madam, Is there a working group on converging legacy protocol stacks and mapping legacy stacks addressing mechanisms into IPv6 addressing? For example, RFC 4291 4038 specifies that :::x.y.z.w represents IPv4 node x.y.z.w - is there a similar draft concept for specifying a Message Transfer Part point code for an SS7 stack or other telephony protocol network layer mechanisms into IPv6 addresses? Thanks much, -Jim Hanley \^^^/ (0 0) ***ooO*(_)*Ooo Jim HanleyREDCOM Laboratories, Inc. Software Engineer 1 Redcom Cntr __ T +1.585.924.7550 Victor, NY / __ /\/ ___/\ F +1.585.924.654714564 ___/ /\/ /_/ /\__\/ jim_han...@redcom.com USA /_/ /___/ / http://www.redcom.com/\_\/\___\/ *Oooo. .oooO ( ) ( ) ) / \ ( (_/ \_) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Stockholm IETF Code Sprint
Stockholm IETF Code Sprint When: July 15, 2009, begining at 9:30 AM Where: IETF Hotel in Stockholm What: A bunch of hackers get together to work on code for the IETF web site. Some people may be porting of existing functionality to the new framework; some people may be adding exciting new functionality. All code will become part of the open source IETF tools. Who: Hopefully you can help Chris Newman will be helping with advance planning. Henrik Levkowetz will be coordinating the event in Stockholm. You will hear more from them shortly. Many of the results of the last code sprint are being used every day. Please support the tools development effort, Russ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Network-Based Mobility Extensions (netext)
A new IETF working group has been formed in the Internet Area. For additional information, please contact the Area Directors or the WG Chairs. Network-Based Mobility Extensions (netext) - Last Modified: 2009-05-19 Current Status: Active Working Group Chair(s): Basavaraj Patil basavaraj.pa...@nokia.com Rajeev Koodli rkoo...@starentnetworks.com Internet Area Director(s): Ralph Droms rdr...@cisco.com Jari Arkko jari.ar...@piuha.net Internet Area Advisor: Jari Arkko jari.ar...@piuha.net Mailing Lists: General Discussion: net...@mail.mobileip.jp To Subscribe: http://www.mobileip.jp/mailman/listinfo/netext Archive: http://www.mobileip.jp/pipermail/netext/ Description of Working Group: Proxy Mobile IPv6, specified in RFC 5213, is a network-based mobility protocol. It uses a Mobile Access Gateway (MAG) and a Local Mobility Anchor (LMA) to allow hosts to move around within a domain while keeping their address or address prefix stable. Proxy Mobile IPv6 has been incorporated into a number of products and deployments are starting. Certain deployment considerations, including localized routing and bulk refresh of lifetime are already emerging. The working group will focus on the following topics relevant for network-based mobility: Localized Routing: a specification for routing traffic between the MAG(s) without involving the LMA. That is, allow the MAGs to route traffic between hosts from one MAG to another, without being tunneled all the way to the LMA. This reduces latency and backhaul load. Applications such as voice can benefit from the reduced latency. Bulk Refresh: a specification of improving the signaling load for binding lifetime refresh. The current specifications call for the handling of each mobility session independent of each other. When a large number of hosts are served by a single MAG, a periodic refresh of the binding lifetimes can lead to a signaling storm. The purpose of the Bulk Refresh feature is to construct a protocol feature that allows such refreshes to occur on a per-MAG basis. LMA Redirection: a specification for allowing an LMA to redirect a MAG to another LMA. This is primarily needed as a way to perform load balancing. This functionality is complementary to implementation techniques that allow distributed MAG implementations to move tasks around without a visible impact at the protocol level, and the initial LMA discovery work in the NETLMM WG. An applicability statement describing the situations where the new functionality is or is not applicable has to be included in the specification. The work in this charter is entirely internal to the network and does not affect hosts in any way (except perhaps through impacting packet forwarding capacity visible to the hosts). The proposed activity will be complementary to the existing IETF Working Groups, notably the NETLMM and MEXT WGs. The NETEXT working group will also act as the primary forum where new extensions on top of the Proxy Mobile IPv6 protocol can be developed. The addition of such new extensions to the working group involves addition of the extension to this charter through the normal rechartering process. This initial charter excludes a number of possible work items that were discussed in the March 2009 BOF. The working group should continue the discussion about a possible update of its charter and principles under which the new work items must operate under. The completion of the work items in the initial charter is not a requirement for the rechartering to become possible. Milestones May 2009 WG chartered July 2009 Initial WG draft on Bulk Refresh July 2009 Decision on the inclusion of possible additional work items September 2009 Initial WG draft on LMA Redirection November 2009 Initial WG draft on Route Optimization December 2009 Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC January 2010 Submit LMA Redirection to IESG for publication as a Proposed Standard RFC April 2010 Submit Route Optimization to IESG for publication as a Proposed Standard RFC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
