From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Thu Jun 7 02:39:19 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27940 for ; Thu, 7 Jun 2001 02:39:18 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f575f7U01807 for ; Wed, 6 Jun 2001 22:41:07 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f575f4k10461 for ; Wed, 6 Jun 2001 22:41:04 -0700 (PDT) Received: from www.rskorea.co.kr ([211.112.29.130]) by proxy2.cisco.com (8.11.2/8.11.2) with SMTP id f575e7c03234 for ; Wed, 6 Jun 2001 22:40:07 -0700 (PDT) Received: from u77G5d645 (unverified [209.210.147.58]) by www.rskorea.co.kr (EMWAC SMTPRS 0.83) with SMTP id ; Thu, 07 Jun 2001 14:40:52 +0900 DATE: 06 Jun 01 10:57:37 PM FROM: weh7AA4Zk@excite.com Message-ID: <3W60MHz1V6lkwt92vGn6zd> SUBJECT: Subject line for sale. Whatever your product, service or business, email will bring customers to you. Send email for yourself, with a protected website and live tech support. Introduction special 300,000 emails sent for you, only $300.00 Call 702-252-4626 9-5pm. p.s.t. see below for remove. To be removed from this email list, please type "REMOVE" in the subject line.Thank you. abx00@excite.com From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Sat Jun 9 09:38:47 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14625 for ; Sat, 9 Jun 2001 09:38:45 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f58Nj2U16715 for ; Fri, 8 Jun 2001 16:45:03 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f58Niu905522 for ; Fri, 8 Jun 2001 16:44:56 -0700 (PDT) Received: from cs.uoregon.edu (root@vitalstatistix.cs.uoregon.edu [128.223.4.19]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f58NimA11228 for ; Fri, 8 Jun 2001 16:44:48 -0700 (PDT) Received: from heron.cs.uoregon.edu (fabbri@heron.cs.uoregon.edu [128.223.4.155]) by cs.uoregon.edu (8.11.0/8.11.0) with SMTP id f58NhWo00690; Fri, 8 Jun 2001 16:43:32 -0700 (PDT) Message-Id: <200106082343.f58NhWo00690@cs.uoregon.edu> Date: Fri, 8 Jun 2001 16:43:51 -0700 (PDT) From: Aaron J Fabbri Reply-To: Aaron J Fabbri Subject: SSM Proxy protocol (SSMP) draft To: ssm-interest@external.cisco.com Cc: zappala@vital-4.cs.uoregon.edu MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=String_of_Ponies_632_000 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc --String_of_Ponies_632_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: g/D8iNgoynEct4Vs0TyKGw== Hi Attached is an Internet-Draft describing the SSM Proxy protocol (SSMP). SSMP is an application-layer protocol which extends the Source-Specific Multicast architecture to provide efficient support for large and dynamic sets of senders. For more background information please see: http://www.nrg.cs.uoregon.edu/ssmproxies/index.html And my implementation-oriented page is at: http://www.cs.uoregon.edu/~fabbri/SSMP/index.html We look forward to hearing your comments! -Aaron -------------------==============================------------------ Aaron Fabbri http://www.cs.uoregon.edu/~fabbri fabbri@cs.uoregon.edu -------------------==============================------------------ --String_of_Ponies_632_000 Content-Type: TEXT/plain; name="draft-uonrg-ssmp-v1-00.txt"; charset=us-ascii; x-unix-mode=0644 Content-Description: draft-uonrg-ssmp-v1-00.txt Content-MD5: 0yHLUp/9S3OHQmoDIw56WA== UONRG Aaron Fabbri INTERNET DRAFT Daniel Zappala Expire in six months University of Oregon, Network Research Group May 30, 2001 SSM-Proxy Protocol (SSMP) Status of this Memo This document is a Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This draft specifies the initial SSM-Proxy protocol (SSMP). SSMP is an application-layer protocol which uses Single-Source Multicast (SSM) as a network-layer primitive to efficiently support multiple- sender multicast groups and the Any-Source Multicast (ASM) service model. Contents 1. Introduction 1.1 Purpose ......................................... 2 1.2 Overall Operation ............................... 3 1.3 Advantages ...................................... 4 1.4 Implementation .................................. 6 2. Notational Conventions and Generic Grammar ............ 7 Fabbri, Zappala [Page 1] INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001 3. Protocol Parameters 3.1 SSMP Version .................................... 7 4. SSMP Messages 4.1 General Packet Format ........................... 7 4.2 Message Types ................................... 8 4.3 Request ......................................... 8 4.4 Response ........................................ 9 4.5 Control Channel Message ......................... 11 4.6 IP Addresses and Port Numbers ................... 11 4.7 UNICAST/1.0 Messages ............................ 12 4.8 MULTICAST/1.0 Messages .......................... 12 5. Protocol Operation .................................... 13 5.1 Simplifying Assumptions ......................... 14 5.2 Protocol States ................................. 14 5.3 Pseudocode Definitions .......................... 14 5.4 Joining and Leaving ............................. 15 5.5 Message Handling ................................ 16 5.6 Proxy List Maintenance .......................... 18 5.7 UNICAST/1.0 Operation ........................... 18 5.8 MULTICAST/1.0 Operation ......................... 19 6. Protocol Examples ..................................... 20 7. Security Considerations ............................... 21 8. Terminology ........................................... 22 9. Future Enhancements ................................... 23 10. References ............................................ 23 1. Introduction 1.1 Purpose For many years the networking community has been debating how to support multicast communication on the Internet. One of the largest questions is how much functionality should be implemented at the network (IP) layer. Initial efforts have focused on developing network-layer protocols such as PIM[1], MSDP[2], and MBGP[3] which implement the Any-Source Multicast (ASM) group model in a fairly robust and efficient manner. Unfortunately, these protocols are somewhat complex and have seen slow deployment. Others have proposed that multicast functionality be implemented solely at the edges of the network [4], greatly simplifying deployment at the cost of some performance. Another promising new approach adopts a more simple Fabbri, Zappala [Page 2] INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001 multicast service model called Source-Specific Multicast (SSM), which is implemented at the network layer. By making each multicast group source-specific, SSM defines away the address allocation [5] problem and removes source location complexity [2] from the network layer. In this way, SSM alleviates some of the main problems associated with the Any-Source Multicast (ASM) model. We see two scenarios for SSM deployment: In the first scenario, SSM is rapidly deployed and ASM is phased out. In this case, we wish to augment SSM with an application-layer protocol which supports ASM multicast groups. In the second scenario, SSM is deployed alongside ASM. In this case, we want extend SSM to provide ASM with additional application-layer services such as access control, fault tolerance, lower setup delay, and permanent multicast addresses. Regardless of the scenario, our main goal is to efficiently support potentially large and dynamic sets of senders on top of an SSM infrastructure. Toward this goal, this draft presents the Source-Specific Multicast Proxy protocol (SSMP). SSMP is an application-layer protocol which uses SSM as a network-layer primitive and generalizes the concept of a session relay, first proposed by Holbrook and Cheriton[7]. 1.2 Overall Operation There are two simple ways of supporting multiple-sender groups with SSM, proposed by Holbrook and Cheriton[7]. The first approach is to use a separate (S,G) channel for each sender. This scheme results in low end-to-end delay, high routing state, and places the burden of source discovery on the receivers. The second approach, called session relay, uses a single (S,G) channel. Senders unicast data to S, and S multicasts this data down its tree. This approach results in higher delay and low routing state. It does not require receivers to perform source discovery but has poor fault tolerance. Our protocol (SSMP) compromises between these two approaches by generalizing the session relay (SR) approach to allow multiple active SRs (proxies) for each group. In SSMP choosing exactly one proxy for a group is equivalent to the session relay approach. The SSMP protocol coordinates multiple multicast channels to efficiently support Any-Source Multicast (ASM) style communication. Each SSMP session (group) advertises a primary channel which we denote (S0,G0). Each SSMP session also maintains a set of proxies {P0,P1,...,Pk}, with P0=S0 being the primary proxy (S0,G0). Backwards compatibility with SSM-only hosts is achieved by allowing them to join the (S0,G0) channel to receive content. Likewise, standard SSM senders may use this primary channel as a session relay. Fabbri, Zappala [Page 3] INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001 [S1] R | ^ V / (P2)<========>(P0)------->R / ^ \ /\ // \---->R R<---/ \ // V / V V R V R (P1)<-_ R | \__ R<----| --[S2] V R Figure 1 -- Basic SSM Proxy protocol Figure 1 illustrates the basic operation of the protocol. Each SSMP session maintains a set of proxies {P0,...,Pn}, and advertises the primary proxy P0 and the primary channel (P0,G0). A host Pi wishing to become a proxy contacts P0 and requests to join the set of proxies. P0 then adds Pi to its list of proxies, and distributes this list among all of the proxies. A sender (S1) sends to the group by choosing a proxy (P2) and unicasting its data to it. This proxy (P2) forwards this data to the other proxies, and then each proxy multicasts it on its direct channel. Receivers subscribe to the direct channel (Pi,Gi) of a nearby proxy to receive content. For better performance (lower cost and delay) senders and receivers should attach to the nearest proxy to reduce delay and routing state (i.e. the proxy-rooted trees will not overlap). Middleware at the client (sender or receiver) should automate selection of a nearest proxy. 1.3 Advantages Figure 2 summarizes the benefits of the SSM Proxy protocol. A key goal of SSMP is to implement multiple-sender groups *efficiently*. We have shown using simulation[8,9] that using a few proxies can reduce the average delay significantly versus the session relay (single proxy) approach, with little or no increase in bandwidth cost. To achieve this level of efficiency, senders and receivers should join to their nearest proxy. For this reason, the SSMP implementation should include a routine for choosing the nearest (by either hops or RTT delay) of a set of hosts. Fabbri, Zappala [Page 4] INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001 Feature Protocol Properties _________________________________________________________________ | | | | | Source | SSM | Receiver burden | | discovery with | Session Relay | Rendezvous through session | | large, dynamic | | relay | | set of senders | SSMP | Rendezvous through proxies | |----------------|---------------|--------------------------------| | Router state | SSM | O(|senders|) | | | Session Relay | O(1) | | | SSMP | O(1) with nearest attachment | |----------------|---------------|--------------------------------| | Sender set-up | SSM | Time for receivers to discover | | delay | | and join new (S,G) | | | Session Relay | None | | | SSMP | None, unless waiting for | | | | dynamic nearest attachment | |----------------|---------------|--------------------------------| | Fault tolerance| SSM | Good: per-sender channels are | | | | independent | | | Session Relay | Poor: whole group depends on | | | | single session relay | | | SSMP | Good: receivers experiencing | | | | bad service may join another | | | | proxy | |----------------|---------------|--------------------------------| | Sender-to- | SSM | Best: shortest path source | | receiver delay | | trees | | | Session Relay | Poor: session relay may be far | | | | from shortest path from | | | | sender to receiver | | | SSMP | Good: approaches that of | | | | separate channels (SSM) as | | | | more proxies are used | |----------------|---------------|--------------------------------| | Backward | SSM | By definition | | compatibility | Session Relay | " " | | w/ SSM-only | SSMP | Yes: receivers can join primary| | hosts | | channel, senders can use | | | | relay immediately | |________________|_______________|________________________________| Figure 2 -- Comparison of SSM and SSM Proxy protocols One of the goals of the SSM Proxy protocol is to provide multicast application developers with a useful (higher) level of abstraction for creating multiple-sender groups. For instance, SSMP handles Fabbri, Zappala [Page 5] INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001 source discovery so the application developer need not implement it. Since only the proxies need to be aware of changes in the set of senders, and since proxies are few and well-known, source discovery is handled more efficiently than were it implemented at the receivers. Another advantage of SSMP is that it is backwards- compatible with SSM-only hosts; session relay is supported for senders, and receivers can simply join the advertised primary channel (S0,G0). 1.4 Implementation As shown in figure 3, the SSMP proxy protocol is divided into modules or "sub-protocols". The proxy-distribution module handles all control messages specific to the data distribution algorithm being used by the proxies. The authentication module handles access control and encryption services. In SSMP version 1.0, the authentication protocol is trivial; anyone is allowed to send to the group. Additionally, the only proxy-distribution protocol a SSMP/1.0 proxy *must* support is UNICAST/1.0, which is designed to be as simple as possible. The lower box in figure 3 represents the part of the protocol used by multicast clients (senders and/or receivers). A client may use the SSMP client protocol to automate attaching to the nearest proxy, and to provide feedback to the proxies. [TODO: receiver feedback is important to avoid dangling proxies]. __________________________________________ | ____________________ ________________ | || | | | | || Proxy-Distribution | | Authentication | | ||____________________| |________________| | | | | SSMP - proxy protocol | |__________________________________________| __________________________________________ | | | SSMP - client protocol | |__________________________________________| Figure 3 - SSM Proxy protocol components The remainder of this document is arranged as follows: Sections 2 through 4 specify the syntax of SSMP control messages. Section 5 specifies protocol semantics and behavior, and section 6 provides some examples. Section 7 discusses security issues, and section 8 defines commonly used terms. Fabbri, Zappala [Page 6] INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001 2. Notational Conventions and Generic Grammar This document uses the Augmented Backus-Naur Form (ABNF) format as described in RFC 2234 to specify protocol syntax. For this reason, multiple syntax options are separated by '/' instead of the common or character '|'. All SSMP messages are encoded in the 7-bit US-ASCII character set. 3. Protocol Parameters 3.1 SSMP Version SSMP uses a "." numbering scheme to indicate versions of the protocol. The protocol versions are intended to allow proxies to indicate the format of a message and its capacity for understanding further SSMP communication, rather than the features obtained via that communication. This versioning policy mimics that of the HTTP/1.0 specification, and more details can be found in [RFC 1945]. The version of an SSMP message is indicated by an SSMP-Version field in the first line of the message. SSMP-Version = "SSMP" "/" 1*DIGIT "." 1*DIGIT This document defines SSMP/1.0. In addition to the message format defined below, SSMP/1.0 proxies must support the following sub- protocol message formats: Proxy-Distribution = "UNICAST/1.0" Auth-Type = "NONE/0.0" 4. SSMP Messages 4.1 General Packet Format Proxies handle two types of packets. Data packets are received via UDP from senders and from other proxies, and are forwarded without modification. Data packets contain no header; they simply contain network byte order data. SSMP-Message packets are received via TCP from other proxies (and possibly clients) and are defined in sections 4.2 through 4.4. Each SSMP message begins with the SSMP-Version string followed by a space. SSMP-Packet = Data-Packet / SSMP-Version SP SSMP-Message Fabbri, Zappala [Page 7] INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001 Data-Packet = ; Defined by application 4.2 Message Types SSMP messages fall into three general categories; requests, responses, and control channel messages. Requests and responses generally indicate one-to-one communication, whereas control channel messages are multicast on the primary proxy's control channel (S0,Gc). SSMP-Message = Request / Response / Control-Channel-Message 4.3 Request There are two types of request messages, those which originate from a proxy and those which are from a client. Request = Proxy-Request / Client-Request There are four types of Proxy-Request messages. The first type, Proxy-Join-Request, is sent from a secondary to a primary proxy to join the SSMP group. The Proxy-Join-Detail message specifies inter- proxy communication and authentication parameters during proxy joining. A proxy may leave a SSMP session by sending a Proxy-Leave- Request. Finally, a proxy may send a Proxy-Ping-Request to another proxy to determine if it is still alive. Proxy-Request = Proxy-Join-Request / Proxy-Join-Detail / Proxy-Leave-Request / Proxy-Ping-Request A secondary proxy wishing to join a SSMP session sends a Proxy-Join- Request message, indicating its direct channel group address G which the new proxy will use to multicast data to its local receivers. The secondary proxy's host address S is inferred from the source address listed in the IP header. Proxy-Join-Request = "Proxy-Join-Req" CRLF "G=" SSM-Group-Addr CRLF During the joining process, a secondary proxy must also provide parameters needed for the proxy distribution and authentication algorithms being used via the Proxy-Join-Detail message. The Proxy- Join-Detail is composed of two sections, a Proxy-Distribution section Fabbri, Zappala [Page 8] INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001 and an optional Proxy-Join-Authen section. Proxy-Join-Detail = "Proxy-Join-Detail" CRLF Proxy-Distribution [Proxy-Join-Authen] The Proxy-Distribution section contains the Proxy-Dist field which identifies the particular proxy distribution type being used. Any additional parameters needed by the distribution type must also be specified. Specifics are presented in sections 4.7 and 4.8. Proxy-Distribution = "Proxy-Distribution" CRLF "Proxy-Dist=" Distribution-ID CRLF *( Distribution-Parameter "=" Value CRLF) Distribution-ID = "UNICAST" "/" Version / "MULTICAST" "/" Version Version = 1*DIGIT "." 1*DIGIT The Proxy-Join-Authen section is reserved for specifying any proxy authentication information needed during the join process. Proxy authentication is not required for this specification of SSMP/1.0. Proxy-Join-Authen = "" ; Not required for SSMP/1.0 When a secondary proxy wishes to leave an SSMP group, it sends a Proxy-Leave-Request message to the primary proxy and specifies its direct channel group address. Proxy-Leave-Request = "Proxy-Leave-Req" CRLF "G=" SSM-Group-Addr CRLF The SSMP protocol uses periodic ping messages to verify that proxies are still active. Proxy-Ping-Request = "Ping" CRLF 4.4 Response There are three general types of response messages; those coming from a proxy and those from a client. Response = Proxy-Response / Client-Response There are three types of Proxy-Response messages. Fabbri, Zappala [Page 9] INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001 Proxy-Response = Proxy-Join-Reply / Proxy-Join-Status / Proxy-OK A primary proxy sends a Proxy-Join-Reply in response to an initial Proxy-Join-Request. The Proxy-Join-Reply message tells the joining (secondary) proxy which types of Proxy-Distribution and Authentication sub-protocols it must support. Proxy-Join-Reply = "Proxy-Join-Reply" CRLF [ "Auth-Type=" Auth-Type CRLF *(Auth-Parameter "=" Auth-Value CRLF) ] [ "Proxy-Dist=" Proxy-Dist-ID CRLF ] In SSMP/1.0, the following authentication and distribution sub- protocols *must* be supported: Auth-Type = "NONE/0.0" Proxy-Dist = "UNICAST/1.0" Proxies *may* also support multicast based proxy distribution: Proxy-Dist = "MULTICAST/1.0" The primary proxy replies to a Proxy-Join-Detail message with a Proxy-Join-Status message. The Proxy-Join-Status message can optionally contain a Proxy-List-Update message to reduce proxy setup delay under low-load conditions. Proxy-Join-Status = "Proxy-Join-Status" CRLF Status-Code [Proxy-List-Update] The Proxy-Join-Status message includes a status code which tells the secondary proxy what information (if any) is required to complete the joining process. Status-Code = Join-Status-ID [SP Join-Status-Text] CRLF The Join-Status-ID field is a three-digit integer string. The Status-Code message may optionally include a textual description of the status code. Suggested Join-Status-Text contents are included as comments (preceded by ";"). Join-Status-ID = "100" ;Join Complete / "200" ;Join Refused / "211" ;Auth. type not supported / "212" ;Auth. failed, access denied Fabbri, Zappala [Page 10] INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001 / "221" ;Dist. type not supported / "222" ;Invalid topo. parameters The last type of proxy reply message is the generic Proxy-OK message. The Proxy-OK message is used as a response to periodic inter-proxy ping messages, and also as a generic affirmative response code. Proxy-OK = "OK" CRLF 4.5 Control Channel Messages Control channel messages are protocol messages which are multicast from the primary proxy on the control channel (S0,Gc). The primary use of the control channel is to distribute the current list of proxies in a scalable manner. The control channel is also used to notify all proxies at once that the SSMP group/session is ending. Control-Channel-Mesg = Proxy-List-Update / End-SSMP-Group The Proxy-List-Update message is used to periodically announce the current list of proxies which belong to a SSMP group. All IP addresses and port numbers are formatted in human-readable text. Proxy-List-Update = "Proxy-List-Update" CRLF 1*( IP-Addr "," SSM-Group-Addr "," UDP-Port "," TCP-Port CRLF) "End-Proxy-List" CRLF The primary proxy may end a SSMP group by multicasting an End-SSMP- Group message to all proxies. End-SSMP-Group = "End-SSMP-Group" CRLF 4.6 IP Addresses and Port Numbers IP addresses are sent in human-readable text for clarity. This document assumes IPv4, and formats addresses in the standard dotted quad notation. The following definitions do NOT use the ABNF grammar for clarity. IP-Addr (informally) = "1.0.0.0" through "255.255.255.255" SSM group addresses are a special case of IP address in the 232/8 range. Fabbri, Zappala [Page 11] INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001 SSM-Group-Addr (informally) = "232.0.0.0" through "232.255.255.255" TCP and UDP port numbers are also sent in readable text. UDP and TCP port numbers are syntactically equivalent. TCP-Port = UDP-Port = "1024" through "65535" 4.7 UNICAST/1.0 Messages When a secondary proxy joins a SSMP session it specifies any information needed for inter-proxy communication in the Proxy- Distribution section of the Proxy-Join-Detail message. The only proxy distribution algorithm which *must* be supported by a SSMP/1.0 proxy is UNICAST/1.0. The UNICAST/1.0 algorithm requires knowledge of two port numbers for each proxy; the control port and the relay port. This information must be provided in the Proxy-Join-Detail request as follows: Proxy-Join-Detail = "SSMP/1.0" SP "Proxy-Join-Detail" CRLF "Proxy-Distribution" CRLF "Proxy-Dist=UNICAST/1.0" CRLF "Control-Port=" TCP-Port CRLF "Relay-Port=" UDP-Port CRLF [Proxy-Join-Authen] The parameters (Control-Port, etc.) may be listed in any order. The operation of the UNICAST/1.0 algorithm is presented in section 5.7. 4.8 MULTICAST/1.0 Messages Another proxy distribution algorithm which *may* be supported by SSMP/1.0 proxies is MULTICAST/1.0. MULTICAST/1.0 employs an extra multicast channel from each proxy called the relay channel. MULTICAST/1.0 requires the same information for each proxy as UNICAST/1.0 does, with the addition of an additional group address Relay-Group. In this case, the Proxy-Distribution section of the Proxy-Join-Detail message has the following format: Proxy-Distribution = "SSMP/1.0" SP "Proxy-Join-Detail" CRLF "Proxy-Distribution" CRLF "Proxy-Dist=MULTICAST/1.0" CRLF "Control-Port=" TCP-Port CRLF "Relay-Port=" UDP-Port CRLF Fabbri, Zappala [Page 12] INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001 "Relay-Group=" SSM-Group-Addr CRLF [Proxy-Join-Authen] Note that the parameters (Control-Port, etc.) may be listed in any order. Since the additional Relay-Group state must be kept for each proxy, the format of the Proxy-List-Update message must be modified to contain this data: Proxy-List-Update = "Proxy-List-Update" CRLF 1*( IP-Addr "," Direct-Group "," UDP-Port "," TCP-Port CRLF "," Relay-Group ) "End-Proxy-List" CRLF The Direct-Group field contains the SSM group address of the proxy's direct channel, and the Relay-Group contains the group address of the proxy's relay channel. Direct-Group = SSM-Group-Addr Relay-Group = SSM-Group-Addr To be modular, we should not allow the proxy distribution algorithm to modify other parts of the protocol. This definition of MULTICAST/1.0 violates this ideal by requiring a modification to the Proxy-List-Update message. To increase modularity, we could introduce another message type which only contains the extra group addresses required by MULTICAST/1.0. Then, ideally, we could use a separate channel, say (S0,Gd), to distribute this information, since it is only useful to proxies and not the larger audience (senders, receivers) which subscribe to the control channel (S0,Gc). In the case of MULTICAST/1.0, the change is so small that we choose the simple approach outlined above. In the future, if more complex proxy distribution algorithms are introduced, separate messages and/or control channels should be added if their cost does not outweigh the improvements in modularity. The operation of the MULTICAST/1.0 algorithm is presented in section 5.8. 5 Protocol Operation This section specifies the semantics and ordering of SSMP messages. 5.1 Simplifying Assumptions Fabbri, Zappala [Page 13] INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001 o All SSMP messages (except control channel multicasts) are sent via TCP. The host which sends the first request in a chain of messages is responsible for closing the TCP connection as soon as the operation is completed. o No host may act as more than one proxy in a single SSMP group. In other words, any host address S_i occurs at most once in any proxy list. The protocol syntax is designed to handle multiple proxies with the same host IP address correctly, but this assumption simplifies the implementation. o Proxy lists are ordered in increasing order of join time from head to tail. The first (head) proxy in a proxy list is the primary proxy. Proxies are added to the tail of the list as they join and are deleted in place when they leave. o We assume the proxy distribution type UNICAST/1.0 is used, and define changes required for MULTICAST/1.0 in sections 4.8 and 5.8. 5.2 Proxy States A SSMP proxy can be in one of the following top-level states at any time: INACTIVE SEC_JOINED PRI_ACTIVE SEC_ACTIVE PRI_DONE SEC_DONE PRI_EXIT SEC_EXIT Initially a proxy is INACTIVE. Other states are preceded with PRI_ or SEC_ to indicate that the proxy is a primary or secondary proxy, respectively. 5.3 Pseudocode Definitions The next two sections use pseudocode to describe proxy behavior. Thorough error checking and special cases are omitted for clarity, and comments are preceded with a semicolon ';'. Our pseudocode uses the following global definitions at each proxy: Variable Description ---------- ---------- STATE Current top-level state pendingProxyList A list of proxies in the process of joining proxyList List of all proxies joined to the session Fabbri, Zappala [Page 14] INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001 S The local host IP address G The SSM multicast address to be used for the local direct channel S0 The IP address of the primary proxy Gc SSM multicast address of the control channel control_port The TCP port on which the proxy will receive SSMP messages relay_port The UDP port on which the proxy will receive data to be relayed to the SSMP group error() A function which indicates an error condition and exits In our pseudocode we create SSMP messages using the simple syntax: Message-Name ( *[parameter-name = parameter-value] ) 5.4 Joining and Leaving A secondary proxy must complete the joining process before it responds to messages on its TCP control port. First, the secondary proxy uses an out of band session advertisement service to determine the primary proxy's host address S0 and TCP control port S0_control_port. The secondary proxy then joins a session managed by a primary proxy as follows: ------------------------------------------------------------ JOIN_GROUP( S0, S0_control_port ) processing if STATE == INACTIVE open TCP connection to S0, S0_control_port send Proxy-Join-Request(G=G) receive msg if msg.ID != Proxy-Join-Reply error() if msg.parameter(Proxy-Dist-ID) != UNICAST/1.0 error() send Proxy-Join-Detail( Proxy-Dist = UNICAST/1.0 Control-Port = control_port Relay-Port = relay_port ) receive msg if msg.ID != Proxy-Join-Status error() if msg.parameter( Join-Status-ID ) == 100 ; Join Complete STATE = SEC_JOINED ; Begin listening on control_port and control channel ; Begin listening on relay_port Fabbri, Zappala [Page 15] INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001 ; Finish any other initialization STATE = SEC_ACTIVE ------------------------------------------------------------ A secondary proxy may need to exit an active SSMP group. Before exiting, a proxy must (if possible) notify the primary proxy and any senders attached to it that it intends to leave. The leaving proxy should wait [TODO: define] long enough to allow other proxies and attached senders to adapt to operation without it. ------------------------------------------------------------ LEAVE_GROUP() processing if STATE == SEC_ACTIVE open TCP connection to S0, S0_control_port STATE = SEC_DONE ; no longer a proxy but waiting to leave send Proxy-Leave-Request(G=G) receive msg if msg.ID != Proxy-OK error() ; Notify senders, currently unspecified [TODO: specify] sleep until we receive a proxy list update which does not contain this proxy STATE = SEC_EXIT ------------------------------------------------------------ When a SSMP session is finished, the primary proxy may end the group by multicasting End-SSMP-Group messages on the control channel. Since we assume unreliable multicast service, we send out multiple copies to reduce the chance of not notifying any proxies. ------------------------------------------------------------ END_GROUP() processing if STATE == PRI_ACTIVE STATE = PRI_DONE send End-SSMP-Group on multicast channel (S0,Gc) sleep one second send End-SSMP-Group on multicast channel (S0,Gc) sleep one second send End-SSMP-Group on multicast channel (S0,Gc) sleep one second STATE == PRI_EXIT ------------------------------------------------------------ 5.5 Message Handling This section describes the behavior of a proxy when it receives a Fabbri, Zappala [Page 16] INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001 message on its (TCP) control port. Whereas the previous section outlines how proxies join and leave SSMP sessions, this section describes steady-state behavior. First we describe how a primary proxy handles incoming control port messages: ------------------------------------------------------------ PRIMARY_CONTROL_PORT( msg ) processing if( STATE == PRI_ACTIVE ) switch( msg.ID ) case Proxy-Join-Request: InetAddress S_i = msg.sourceAddr InetAddress G_i = msg.parameter( G ) pendingProxyList.add( S_i:G ) reply = Proxy-Join-Reply( Proxy-Dist = "UNICAST/1.0" ) send reply case Proxy-Join-Detail: if msg.parameter(Proxy-Dist) != UNICAST/1.0 error() control_port = msg.parameter(Control-Port) relay_port = msg.parameter(Relay-Port) S_i = msg.sourceAddr (S_i:G_i) = pendingProxyList.lookup( S_i ) pendingProxyList.remove( S_i:G_i ) proxyList.add( S_i:G_i:control_port:relay_port) reply = Proxy-Join-Status( Join-Status-ID = 100 ; Join Complete ) send reply case Proxy-Leave-Request: proxyList.remove( msg.sourceAddr ) send Proxy-OK case Proxy-Ping-Request: send Proxy-OK ------------------------------------------------------------ Next we describe how a secondary proxy handles control port messages. Once a secondary proxy has joined a SSMP session, it handles incoming control port messages as follows: ------------------------------------------------------------ Fabbri, Zappala [Page 17] INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001 SECONDARY_CONTROL_PORT( msg ) processing if STATE == SEC_ACTIVE switch( msg.ID ) case P_PING: send Proxy-OK ------------------------------------------------------------ 5.6 Proxy List Maintenance The proxy list is maintained by the primary proxy and distributed to all proxies. This list is soft-state; if a proxy on the list cannot be contacted within some amount of time [TODO: specify?] it must be deleted from the list. It is the responsibility of the primary proxy to maintain timers and attempt to ping proxies which it has not heard from within a certain amount of time. The proxy list may need to be distributed to a very large number of hosts; multicast receivers and senders need the proxy list to determine the closest proxy to attach to and to be able to switch to another proxy as desired. Since the proxy list may have a large and dynamic audience, we use multicast to periodically distribute the latest copy in a scalable manner. The period between updates may be increased or decreased; a larger interval uses less bandwidth but increases join latency since a host or proxy may have to wait longer to hear the first proxy list announcement. 5.7 UNICAST/1.0 Operation Recall that SSMP defines a module called "proxy distribution" which handles distribution of data (not SSMP-Messages) between proxies. The only proxy distribution SSMP/1.0 proxies *must* support is UNICAST/1.0. To source data in an SSMP session, a source sends data to the relay port of the proxy P_i it has chosen. This proxy becomes the *source proxy* for that data. In UNICAST/1.0, the source proxy will unicast (UDP) this data to the relay port of each other proxy in its proxy list, and then multicast this data on its direct channel (P_i,G_i). A proxy P_j which receives data from another proxy can be called a *receive proxy*, and simply multicasts the data on its direct channel (P_j,G_j). The following pseudocode summarizes this behavior: ------------------------------------------------------------ RECEIVE_RELAY_PORT( packet ) processing if STATE == PRI_ACTIVE or STATE == SEC_ACTIVE if proxyList.contains( packet.sourceAddr ) Fabbri, Zappala [Page 18] INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001 AND packet.sourceAddr != S ; this proxy may be a source ; we are a receive proxy multicast packet on (S,G) ; our direct channel else ; we are the source proxy foreach proxy in proxyList if proxy != S ; don't send to yourself udp-send packet to proxy.S, proxy.relay_port multicast packet on (S,G) ------------------------------------------------------------ UNICAST/1.0 is desirable because it keeps multicast routing state to a minimum; each proxy uses one or two multicast channels. The trade-off is that the unicast replication to each proxy increases the bandwidth cost. 5.8 MULTICAST/1.0 Operation To reduce the bandwidth cost associated with UNICAST/1.0, we can replace unicast proxy distribution with multicast. This requires each proxy to source an additional channel called a *relay channel* which is used to multicast data to the other proxies. Each proxy joins the relay channel for each of the other proxies. When a source proxy receives data from a sender, it multicasts it on its relay channel and then multicasts it on its direct channel. Operation of a proxy with MULTICAST/1.0 is identical to that of a UNICAST/1.0 proxy except for the following changes: o MULTICAST/1.0 requires one item of additional state to be kept for each proxy; the relay channel group address Relay-Group. o Proxies must also distribute this additional state. Changes to the message formats required to accomplish this are defined in section 4.8. o Assuming, for simplicity, that a proxy receives all incoming data (unicast from senders AND multicast from a source proxy) on its relay port, the RECEIVE_RELAY_PORT processing (defined in 5.7) must be modified as follows: ------------------------------------------------------------ RECEIVE_RELAY_PORT( packet ) processing if STATE == PRI_ACTIVE or STATE == SEC_ACTIVE if proxyList.contains( packet.sourceAddr ) and packet.sourceAddr != S Fabbri, Zappala [Page 19] INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001 ; we are a receive proxy multicast packet on (S,G) ; our direct channel else ; we are the source proxy multicast packet on (S,Relay-Group) ; this is the change multicast packet on (S,G) ------------------------------------------------------------ o When a primary proxy allows a secondary proxy to join the SSMP group, it must subscribe to the relay channel of the new proxy. If a proxy leaves, it must unsubscribe. o When a secondary proxy receives a Proxy-List-Update which differs from its current proxy list, it must subscribe to the relay channels of any new proxies and unsubscribe from the relay channels of any proxies which have left. 6 Protocol Examples Below are some examples of SSMP message exchanges. Entries marked with a "->" represent a secondary proxy sending to the primary proxy, and "<-" is a reply. Example Proxy Join: -> SSMP/1.0 Proxy-Join-Req ; A new proxy wishes to join. G=232.11.11.11 ; its direct channel group <- SSMP/1.0 Proxy-Join-Reply ; Primary proxy responds, Auth-Type=NONE/0.0 ; optionally w/ authentication Proxy-Dist=UNICAST/1.0 ; and proxy distribution info. -> SSMP/1.0 Proxy-Join-Detail Proxy-Distribution Proxy-Dist=UNICAST/1.0 ; Default proxy data distribution Control-Port=4123 ; TCP port Relay-Port=4122 ; UDP port <- SSMP/1.0 Proxy-Join-Status 101 Join Complete ; Later the new proxy will receive a Proxy-List-Update message on the ; multicast control channel: <- SSMP/1.0 Proxy-List-Update Begin-Proxy-List ; S,G,RelayPort,ControlPort 128.223.6.11,232.22.22.22,4123,4124 Fabbri, Zappala [Page 20] INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001 128.23.2.1,232.22.22.44,4123,4124 128.24.3.4,232.22.22.66,4123,4124 128.25.2.11,232.22.22.88,4123,4124 End-Proxy-List Example Proxy Leave: -> SSMP/1.0 Proxy-Leave G=232.11.11.11 ; S is determined via TCP/IP <- SSMP/1.0 OK [TODO: add to protocol] Example Receiver Request: ; SSMP proxies may or may not implement this. We generally use the ; control multicast channel to periodically distribute the proxy list ; in a scalable way, but a proxy may want to support 1-to-1 proxy list ; distribution under low-load conditions to reduce proxy setup delay. -> SSMP/1.0 Proxy-List-Request <- SSMP/1.0 Proxy-List-Update Begin-Proxy-List ; S,G,RelayPort,ControlPort 128.223.6.11,232.22.22.22,4123,4124 128.23.2.1,232.22.22.44,4123,4124 128.24.3.4,232.22.22.66,4123,4124 End-Proxy-List 7 Security Considerations Denial of Service A proxy join request creates state and eventually results in additional consumption of bandwidth. In UNICAST/1.0, the amount of bandwidth used for proxy distribution grows with the number of proxies joined to the session. With MULTICAST/1.0, each proxy join also creates (S,G) state at routers as proxies join the direct channel of each new proxy. For these reasons, host(s) can attempt a denial of service attack by completing a large number of proxy join requests. Although the requirement that each proxy's host must have a unique IP address may help, a primary proxy *may* implement controls to limit damage from such an attack: o Limit the total number of proxies which may join a SSMP Fabbri, Zappala [Page 21] INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001 group. o Limit the rate at which new proxies are allowed to join the SSMP group. Address Spoofing This specification assumes that incoming packets contain the correct source address in their IP header. A host may interrupt operation of a SSMP group by sending a message with a falsified source address. Source Control SSMP/1.0 implements the Any-Source Multicast (ASM) model, allowing any host to send to a group. Since many applications need to control who may send to a group, future versions of SSMP will include source authentication which will be enforced by the proxies. Proxy Authentication SSMP is designed to accommodate proxy authentication, which will be specified in a future version. 8 Terminology ASM - Any-Source Multicast service model. Another name for ISM (see ISM below) which was recently adopted by the IETF to avoid the connotation that "Internet Standard" multicast was the only standardized model. channel - A source-specific multicast group (see SSM). cost - aggregate bandwidth usage delay - the length of the path between senders and receivers, usually expressed in number of hops or milliseconds direct channel - Each proxy sources a direct channel which local receivers subscribe to to receive data. group - the members (senders and receivers) of an Any-Source Multicast (see ASM) session ISM - Internet Standard Multicast service model [6]. In the ISM model, a multicast group is identified by a single group IP address, G. In an ISM group, senders need not be members and can send Fabbri, Zappala [Page 22] INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001 multicast packets addressed to G at any time. An ISM group can contain multiple senders. PIM - Protocol Independent Multicast [1] is a very popular protocol which implements Any-Source Multicast (see ASM) at the network layer. PIM-SM - Protocol Independent Multicast--Sparse Mode is a specific implementation of PIM (see PIM) which efficiently supports sparse multicast groups. primary proxy - The primary proxy of an SSMP group can be thought of as the coordinator of the group. The primary proxy is the source of the control multicast channel and serves as an application-layer rendezvous point (RP) for the group. Each SSMP group has exactly one primary proxy. proxy - a generalization of the session relay concept[7] receive proxy - A receive proxy is a proxy which receives data from another proxy. relay channel - In multicast proxy distribution (MULTICAST/1.0), each proxy sources a relay channel which other proxies in that group join to receive data from a source proxy. RTT - round trip time secondary proxy - A secondary proxy is any SSMP proxy which is not a primary proxy. Each SSMP group has zero or more secondary proxies. session relay - Session relay, described in [7], is one way of supporting a multicast group with multiple senders using SSM. source proxy - A source proxy is the proxy which a sender relays its data to. A source proxy is responsible for distributing this data to each of the other proxies in the SSMP group. SSM - Source-Specific Multicast service model. In the SSM service model, each sender creates its own group which is identified by two IP address, (S,G), where S is the unicast address of the source, and G is an IP address in the 232/8 (232.0.0.0 to 232.255.255.255) range. SSMP - SSM Proxy protocol is the protocol defined in this document. SSMP extends SSM (see SSM) with an application-layer protocol which allows it to efficiently support ASM (see ASM). SSMP session - An SSM Proxy protocol session is essentially an ASM- style (see ASM) multicast group implemented by the SSMP and SSM Fabbri, Zappala [Page 23] INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001 protocols. 9 Future Enhancements o Source and/or proxy authentication. o Investigate using an application-layer multicast protocol such as Narada for proxy distribution? o The distributed nature of the protocol (e.g. multiple proxies and channels) should lend its self well to implementing reliability... 10 References [1] S. E. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. Liu, and L. Wei. The PIM Architecture for Wide-Area Multicast Routing. IEEE/ACM Transactions on Networking, 4(2):153--162, Apr. 1996. [2] David Meyer and Bill Fenner, "Multicast Source Discovery Protocol (MSDP)", Work in progress, draft-ietf-msdp-spec-09.txt, May 2001. [3] Bates, R. Chandra, D. Katz, and Y. Rekhter, "Multiprotocol extensions for BGP-4," RFC 2283, Internet Engineering Task Force, Feb. 1998. [4] Yang-Hua Chu, Sanjay Rao, and Hui Zhang. "A case for end system multicast." In Proceedings of ACM Sigmetrics, Santa Clara, CA, 2000. [5] Satish Kumar, Pavlin Radoslavov, David Thaler, Cengiz Alaettinoglu, Deborah Estrin, and Mark Handley, "The MASC/BGMP architecture for inter-domain multicast routing," in Proceedings of SIGCOMM '98, Vancouver, Canada, Sept. 1998. [6] D. Cheriton and Steve Deering. Multicast Routing in Datagram Internetworks and Extended LANs. ACM Transactions on Computer Systems, pages 85-111, May 1990. [7] Hugh W. Holbrook and David R. Cheriton, "IP Multicast Channels: EXPRESS Support for Large-scale Single-source Applications, " in Proceedings of the ACM SIGCOMM'99, Cambridge, Massachusetts, USA, 1999. Fabbri, Zappala [Page 24] INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001 [8] Daniel Zappala and Aaron Fabbri, "An Evaluation of Shared Multicast Trees with Multiple Active Cores," in International Conference on Networking, ICN'01, July 2001. [9] Daniel Zappala and Aaron Fabbri, "Using SSM Proxies to Provide Efficient Multiple-Source Multicast Delivery". Submitted, 2001. Fabbri, Zappala [Page 25] --String_of_Ponies_632_000-- From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Tue Jun 12 22:46:35 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00460 for ; Tue, 12 Jun 2001 22:46:34 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5D0Cak24977; Tue, 12 Jun 2001 17:55:10 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f5D0CVP15669; Tue, 12 Jun 2001 17:12:31 -0700 (PDT) Received: from mx2.rosnet.ru (mx2.rosnet.ru [195.90.128.114]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f5D0CJk00552; Tue, 12 Jun 2001 17:12:20 -0700 (PDT) Received: from smtp.kapta.ru (dialup-134.ppp.kapta.ru [195.90.160.134]) by mx2.rosnet.ru (8.11.0/8.11.0-M) with SMTP id f5CNn6Q27872; Wed, 13 Jun 2001 03:49:07 +0400 Message-Id: <200106130308.SEX5055@smtp.kapta.ru> Date: Ñð, 13 èþí 2001 3:08:28 +0300 Content-Type: text/html; Charset=iso-8859-1 Organization: TaxConsulting UK X-Mailer: Dynamic Opt-In Emailer (Win95/98/NT) Subject: From: "Seminar" Программа семинара

Уважаемые господа!

Консалтинговая компания г. Москва 

приглашает Вас принять участие в следующих семинарах:
 

  • ИСПОЛЬЗОВАНИЕ МЕЖДУНАРОДНЫХ ОФФШОРНЫХ КОМПАНИЙ  В ПРАВОВОМ ПОЛЕ РОССИЙСКОЙ ФЕДЕРАЦИИ

 

  • РОССИЙСКИЕ ЛЬГОТНЫЕ НАЛОГОВЫЕ РЕГИОНЫ.  РЕГИСТРАЦИЯ И ПРИНЦИПЫ  ИСПОЛЬЗОВАНИЯ КОМПАНИЙ. ОФФШОРНЫЕ СХЕМЫ. 

 г. Москва, 20 июня

г. Москва, 25 июня 

Цель курса  

  •  Представление практических схем минимизации  налогообложения с использованием оффшорных компаний в правовом поле России;

  •  Изменение политики государства в оффшорном бизнесе;

  •  Концепции использования оффшорных предприятий;

Преподаватели семинара

 Высококвалифицированные специалисты в данной области, с многолетним  опытом работы. 
   

Участники семинара обеспечиваются нормативными документами по тематике практикума.  В перерывах - кофе, чай, напитки. Обед.
 

Для участников, пожелавших зарегистрировать компанию во время семинара, предоставляется скидка в размере 10% от стоимости заказа.

Также проводятся семинары по темам "Изменение таможенного законодательства" и "Новые аспекты ВЭД на 2001 год" 

Для участия в семинаре необходимо зарегистрироваться по телефонам :  (095) 234-24-22, 234-24-23   


From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Thu Jun 14 01:28:26 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09650 for ; Thu, 14 Jun 2001 01:28:26 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5E4hWU26623 for ; Wed, 13 Jun 2001 21:43:32 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f5E4hQw02318 for ; Wed, 13 Jun 2001 21:43:26 -0700 (PDT) Received: from email.jjsh.com.cn ([202.101.226.226]) by proxy3.cisco.com (8.11.2/8.11.2) with SMTP id f5E4eAI14109 for ; Wed, 13 Jun 2001 21:40:11 -0700 (PDT) Received: from html by email.jjsh.com.cn (SMI-8.6/SMI-SVR4) id MAA11258; Thu, 14 Jun 2001 12:05:28 +0800 Message-Id: <200106140405.MAA11258@email.jjsh.com.cn> From: barako@earthlink.net To: ssm22@aol.com Subject: You are a winner! 5 Date: Thu, 14 Jun 2001 00:16:51 Mime-Version: 1.0 Content-Type: text/html; charset="DEFAULT_CHARSET" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700

Congratulations! You've been selected
for a chance to win one of the exclusive
Vacation Packages and/or a Pentium PC
below courtesy of...

National Vacation Promotions!

This is the real thing!
Simply fill out the form below
and register to win - 5 drawings weekly.

Register Below and Win Today!











You were sent this message because your address is in our subscriber database.
If you wish to be removed, please and we will remove you from our subscriber list.

From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Thu Jun 14 14:14:15 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06258 for ; Thu, 14 Jun 2001 14:14:15 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5EHKIk29976 for ; Thu, 14 Jun 2001 10:20:18 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f5EHK9i05264 for ; Thu, 14 Jun 2001 10:20:10 -0700 (PDT) Received: from web.bense.de ([195.143.56.2]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f5EHKk108352 for ; Thu, 14 Jun 2001 10:20:47 -0700 (PDT) Received: from [195.40.205.118] (helo=adnet.co.kr) by web.bense.de with smtp (Exim 3.22 #4) id 15AacV-0004Th-00; Thu, 14 Jun 2001 19:09:27 +0200 Message-ID: <00003046437c$00007b9e$00003243@actrix.gen.nz> To: From: newspick@mailrouter3.umist.ac.uk Subject: MAJOR STOCK PLAY at $0.14 !!!!!! Date: Thu, 14 Jun 2001 05:56:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Content-Transfer-Encoding: 7bit MAJOR STOCK PLAY AMER GROUP INC (OTC BB:AMCG) Current Price: $0.14 52 week high: $10.00 This coming Tuesday AMCG will be profiled by a major newsletter. Huge volume and a strong increase in price is expected for several days. We feel that AMCG is currently oversold and with a 52 week high of $10.00 per share there is tremendous upside potential!!! for details go to http://quote.yahoo.com/q?s=amcg.ob&d=t DISCLAIMER: hotstocks cautions that stocks are high-risk investments and that some or all investment dollars can be lost. We suggest you consult a professional investment advisor before purchasing any stock. All opinions expressed in this newsletter are the opinions of hotstocks. We own shares in the mentioned company and may sell at any time. We recommend you use the information found here as an initial starting point for conducting your own research and conduct your own due diligence on the featured company in order to determine your own personal opinion of the company before investing. for removal from this newsletter email winstocks_@excite.com From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Mon Jun 18 22:24:29 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27716 for ; Mon, 18 Jun 2001 22:24:29 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5J1aDN27746 for ; Mon, 18 Jun 2001 18:36:13 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f5J1a9Z26048 for ; Mon, 18 Jun 2001 18:36:09 -0700 (PDT) Received: from HsEx2000.Hsh.stn.sh.cn ([203.95.7.171]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f5J1ZqC12263 for ; Mon, 18 Jun 2001 18:35:53 -0700 (PDT) Received: from cvx-la-33.iolwest.com_[209.209.83.33] ([209.209.83.33]) by HsEx2000.Hsh.stn.sh.cn with Microsoft SMTPSVC(5.0.2195.1600); Tue, 19 Jun 2001 08:42:54 +0800 Received: from adelard.co.uk by cvx-la-33.iolwest.com with ESMTP; Mon, 18 Jun 2001 17:34:36 -0700 Message-ID: <00002ea21f54$000052ec$00000a9f@adelard.co.uk> To: From: fukuju@mars.dtinet.or.jp Subject: GUARANTEED way to QUICKLY have EXCELLENT CREDIT!! 2719 Date: Mon, 18 Jun 2001 17:34:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Reply-To: ueno@ff.iij4u.or.jp X-OriginalArrivalTime: 19 Jun 2001 00:43:00.0813 (UTC) FILETIME=[CAB64FD0:01C0F858] Content-Transfer-Encoding: 7bit $$ GUARANTEED WAY TO QUICKLY HAVE EXCELLENT CREDIT!! $$ Dear Friend, Give yourself the ADVANTAGE of enjoying life more with EXCELLENT CREDIT!! Over the past 8 years I have perfected a system called the Proven Credit Advantage Program. It's a guaranteed way for legally getting an excellent credit rating almost instantly. Here's how: If you have bad credit you will simply go through my easy 5 step program to quickly get a new, legal, unblemished credit file and establish Excellent Credit. If you don't have bad credit, but want to make your existing credit EXCELLENT, we will go straight to STEP 5. Step 1 - Because no two people in the United States have the same Social Security Number, Banks and Creditors access your credit file almost entirely by your SS#. You will not want to change your Social Security Number because it is extremely difficult to do so and you need it for your Employment, Taxes and Social Security Benefits. The FEDERAL PRIVACY ACT OF 1974 clearly states that only the Government and your employer can force you to use your SS#. Because of this law you are allowed to legally use another 9 digit number to use in place of your Social Security # on credit applications. The first day you become our client, you will receive your own number through the Employer Identification Number Program. You will need us for this because 95% of all Employer Identification Numbers, although 9 digits, do not look anything like Social Security Numbers and cannot be used on credit applications. We will legally get you an Employer Identification Number that fits in the same range of Social Numbers in use today. Because the Federal Laws do not require you to give your SS# to anyone besides your Employer and the Government, you can now legally use this number in place of your SS# on credit applications. Remember, your new number will only be used for new credit. Step 2 - No two people with the same name have the same mailing address, so you will need to obtain a new mailing address for use on your new credit file. A friend, relative or mailbox address in your area will be perfect. Step 3 - No two people with the same name have the same telephone numbers, so you will also need a new telephone number for use on your new credit file. A friend, relative, voice mail or pager will again work perfectly. Step 4 - With your new Social Security number, new address and new telephone number we will open your new credit file. It will now be totally impossible for any creditor to know anything about your past credit history. Step 5- To guarantee that you will quickly have EXCELLENT CREDIT, we will assist you in instantly adding UNLIMITED positive information to your credit file. This is an unknown way of adding real accounts to your new credit file to give you an Excellent Credit Rating in less than 15 days. As you know, the more positive information on your credit file, the more money banks will lend you. Countless clients of ours have credit lines over $100,000 because of our Proven Credit Advantage Program! When we are finished you will receive a copy of your credit file proving that you now have excellent credit! This will take less than 15 days. You will now be able to easily qualify for ANY credit you apply for! To be on the road to EXCELLENT CREDIT simply send us your name, complete mailing address including zip code and telephone number (optional), along with a check or money order payable to American Financial Services Inc. for $29.95. Send to: American Financial Services Inc. Attn.: Mike Robbins 311 N. Robertson Blvd. Suite 625 Beverly Hills, CA 90210 All necessary paperwork along with a telephone number to contact us for assistance will be sent to you priority mailed to you within 3 business days. $$$$ RISK FREE DOUBLE YOUR MONEY BACK GUARANTEE!! $$$$ My Proven Credit Advantage Program unconditionally guarantees you will qualify for personal loans, business loans, credit cards, auto loans, home loans and any other credit you apply for! If you are not able to qualify for credit after using my program, simply return your Proven Credit Advantage Program along with your denial letter and your $29.95 investment will be refunded DOUBLE! That's a $59.90 refund if this doesn't work like I said! I make this guarantee to you because the Proven Credit Advantage Program has already helped over 15,000 people just like you. I KNOW it works - all you need to do is sign up TODAY! I truly look forward to making you another SATISFIED CLIENT!! ................................................................ Yes! I deserve excellent credit. Please enroll me in the Proven Credit Advantage Program. Enclosed is my check/money order for $29.95. The following information is for our records only and does not need to be your new credit file information. First Name______________________________ Last Name________________________________ Address__________________________________ City_____________________________________ State_______________Zip__________________ Telephone(optional)______________________ e-mail___________________________________ If you would prefer to download your Proven Credit Advantage Program, simply check below and we will e-mail you a download upon receipt of your order. Otherwise we will Priority Mail your program to the above address. ___ Please e-mail me my PROVEN CREDIT ADVANTAGE PROGRAM to the above e-mail address. ___ Please send me my PROVEN CREDIT ADVANTAGE PROGRAM via United States Priority Mail to the above address. Send $29.95 to: American Financial Services Inc. Attn: Mike Robbins 311 N. Robertson Blvd. Suite 625 Beverly Hills, CA 90210 This e-mail is never sent unsolicited! You have been sent this email because we received your e-mail address in an opt-in database for individuals interested in information to improve their financial situation. If this e-mail has reached you in error please respond to: optmeoutnow44@hotmail.com with remove in the subject line. From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Mon Jun 25 10:36:27 2001 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16697 for ; Mon, 25 Jun 2001 10:36:27 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f5PDcxH19653 for ; Mon, 25 Jun 2001 06:38:59 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f5PDefH21259 for ; Mon, 25 Jun 2001 06:40:41 -0700 (PDT) Received: from mail.zrz.tu-berlin.de (mail.zrz.TU-Berlin.DE [130.149.4.15]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f5PDfBD03652 for ; Mon, 25 Jun 2001 06:41:12 -0700 (PDT) Received: from ftsu07.ee.tu-berlin.de ([130.149.49.87] helo=ftmail.ee.tu-berlin.de) by mail.zrz.tu-berlin.de with esmtp (exim-3.30) for id 15EWMq-0006YN-00; Mon, 25 Jun 2001 15:25:28 +0200 Received: from ee.tu-berlin.de (festag@ananke.ee.TU-Berlin.DE [130.149.49.124]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id f5PDPRh15794 for ; Mon, 25 Jun 2001 15:25:27 +0200 Sender: festag@ftmail.ee.tu-berlin.de Message-ID: <3B373BC7.53A77964@ee.tu-berlin.de> Date: Mon, 25 Jun 2001 15:25:27 +0200 From: Andreas Festag Organization: TKN, TU-Berlin X-Mailer: Mozilla 4.75 [de] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: ssm-interest@external.cisco.com Subject: info ssm-interest Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit info ssm-interest From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Mon Jun 25 11:12:23 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17701 for ; Mon, 25 Jun 2001 11:12:23 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5PE61N01052 for ; Mon, 25 Jun 2001 07:06:01 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f5PE5rx04259 for ; Mon, 25 Jun 2001 07:05:53 -0700 (PDT) Received: from mail.zrz.tu-berlin.de (mail.zrz.TU-Berlin.DE [130.149.4.15]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f5PE4WN04020 for ; Mon, 25 Jun 2001 07:04:32 -0700 (PDT) Received: from ftsu07.ee.tu-berlin.de ([130.149.49.87] helo=ftmail.ee.tu-berlin.de) by mail.zrz.tu-berlin.de with esmtp (exim-3.30) id 15EWlJ-0000AF-00; Mon, 25 Jun 2001 15:50:45 +0200 Received: from ee.tu-berlin.de (festag@ananke.ee.TU-Berlin.DE [130.149.49.124]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id f5PDojh16528; Mon, 25 Jun 2001 15:50:45 +0200 Sender: festag@ftmail.ee.tu-berlin.de Message-ID: <3B3741B5.8BEC2F92@ee.tu-berlin.de> Date: Mon, 25 Jun 2001 15:50:45 +0200 From: Andreas Festag Organization: TKN, TU-Berlin X-Mailer: Mozilla 4.75 [de] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: ssm-interest@external.cisco.com Subject: PIM-SSM Implementation for Linux Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, I havn't found a PIM-SSM implemenation for Linux. Is there a PIM-SSM implementation available (for Linux or other OS)? Is someone working on a Linux implementation? Thanks Andreas From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Mon Jun 25 18:36:11 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28713 for ; Mon, 25 Jun 2001 18:36:11 -0400 (EDT) Received: from cactus.cisco.com (cactus.cisco.com [161.44.19.100]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5PLaFx15714 for ; Mon, 25 Jun 2001 14:36:15 -0700 (PDT) Received: from glock (dhcp-161-44-19-65.cisco.com [161.44.19.65]) by cactus.cisco.com (8.8.8+Sun/8.8.8) with SMTP id OAA26487; Mon, 25 Jun 2001 14:36:04 -0700 (PDT) Message-ID: <028501c0fdbe$d6133350$41132ca1@glock> From: "Stephen Sprunk" To: "Andreas Festag" , References: <3B3741B5.8BEC2F92@ee.tu-berlin.de> Subject: Re: PIM-SSM Implementation for Linux Date: Mon, 25 Jun 2001 16:16:41 -0500 Organization: Cisco Systems, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Do you mean you're looking for a PIM-SSM routing daemon, or that you're looking for IGMPv3 support? S | | Stephen Sprunk, K5SSS, CCIE #3723 :|: :|: Network Design Consultant, ANS :|||: :|||: RCDN2 in Richardson, TX .:|||||||:..:|||||||:. Email: ssprunk@cisco.com ----- Original Message ----- From: "Andreas Festag" To: Sent: Monday, June 25, 2001 08:50 Subject: PIM-SSM Implementation for Linux > Hello, > > I havn't found a PIM-SSM implemenation for Linux. Is there a PIM-SSM > implementation available (for Linux or other OS)? Is someone working on > a Linux implementation? > > Thanks > > Andreas From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Mon Jun 25 21:16:10 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01426 for ; Mon, 25 Jun 2001 21:16:09 -0400 (EDT) Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5Q0NXh12142 for ; Mon, 25 Jun 2001 17:23:33 -0700 (PDT) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id RAA12890; Mon, 25 Jun 2001 17:23:30 -0700 (PDT) Date: Mon, 25 Jun 2001 17:23:30 -0700 From: Toerless Eckert To: Andreas Festag Cc: ssm-interest@external.cisco.com Subject: Re: PIM-SSM Implementation for Linux Message-ID: <20010625172330.W17802@cypher.cisco.com> References: <3B3741B5.8BEC2F92@ee.tu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B3741B5.8BEC2F92@ee.tu-berlin.de>; from festag@ee.tu-berlin.de on Mon, Jun 25, 2001 at 03:50:45PM +0200 On Mon, Jun 25, 2001 at 03:50:45PM +0200, Andreas Festag wrote: > Hello, > > I havn't found a PIM-SSM implemenation for Linux. Is there a PIM-SSM > implementation available (for Linux or other OS)? Is someone working on > a Linux implementation? If you want to have a last-hop-router, then you primarily need IGMPv3, which is most of the issue. Then yes, you need to add some code to PIM to have it pick up (S,G) state from IGMPv3. If you just want to have an intermediate router, then you can even use an existigin PIM-SM implementation without changes. That's more or less what happens today with the 232/8 range being run over the existing PIM-SM infrastructure. Cheers Toerless From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Tue Jun 26 10:41:08 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14278 for ; Tue, 26 Jun 2001 10:41:08 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5QCLKN00346 for ; Tue, 26 Jun 2001 05:21:20 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f5QCLCp05976 for ; Tue, 26 Jun 2001 05:21:12 -0700 (PDT) Received: from BAY01.Local23.com (ufcw23.com [205.171.53.178]) by proxy3.cisco.com (8.11.2/8.11.2) with SMTP id f5QCLld10157 for ; Tue, 26 Jun 2001 05:21:47 -0700 (PDT) Message-Id: <200106261221.f5QCLld10157@proxy3.cisco.com> Received: from 10.0.0.150 by BAY01.Local23.com (InterScan E-Mail VirusWall NT); Tue, 26 Jun 2001 02:10:06 -0400 (Eastern Daylight Time) Received: from BAY01.Local23.com [10.0.0.150] (jhadfj@excite.com); Tue, 26 Jun 2001 02:07:03 -0400 X-WM-Posted-At: ufcw23.com; Tue, 26 Jun 01 02:07:03 -0400 Received: from 10.0.0.1 by BAY01.Local23.com (InterScan E-Mail VirusWall NT); Tue, 26 Jun 2001 02:06:13 -0400 (Eastern Daylight Time) From: jhadfj@excite.com To: meisners3@yahoo.com Subject: RECEIVE $2,000 in one WEEK !! GUARANTEED!! ----------- ulyxxx2 Date: Mon, 25 Jun 01 20:30:01 Hawaiian Standard Time Errors-To: djmcmasters@hotmail.com Reply-To: ulyssaxx2@yahoo.com X-Mailer: [102.87.149.207] [196.34.144.100] (helo=67.97.0.7) X-Priority: 3 X-MSMailPriority: Normal Importance: Normal R E C E I V E $1,000 COMMISSION every $0 down SALE !! DID YOU MAKE $8,000 LAST MONTH? IF NOT, YOU NEED TO JOIN US TODAY! $0 DOWN ! 100% FINANCING - 100% CASH MACHINE EVERYBODY IS A PROSPECT - 99% APPROVED EARN $1,000 ON EVERY A THROUGH F CREDIT SALE! EARN $1,000 ON EACH AND EVERY SALE TO INFINITY! REQUEST MORE INFO NOW! send an e-mail to: ulyssaxxx2@yahoo.com with SEND INFO in the subject line or JUST CLICK on "Reply" NOW!! Available for USA residents only. ~~~~~~~~~~~ MARKET the hottest consumer savings package in America today and earn $1,000 each and every time someone joins for $0 DOWN! NO hard selling, NO cold calls - 100% AUTOPILOT Imagine being plugged into a proven system that puts your entire business on auto-pilot and have you earning MINIMUM $2,000 every week! GUARANTEED!! IT'S TRUE! You can be in business for $0 DOWN! And you can easily make $2,000 your very FIRST week .. . and we'll show you how! Your business will literally explode overnight when you join our team and plug into the BEST marketing system available on the web! Most OUTSTANDING: Receive FULL SUPPORT 24 hrs!! ~~~~~~~~~~~ REQUEST MORE INFO NOW! send an e-mail to: ulyssaxxx2@yahoo.com with SEND INFO in the subject line or JUST CLICK on "Reply" NOW!! Available for USA residents only. To remove please click: ulyssaxxx2@yahoo.com