KR20060093704A - 클라이언트 요청 외부 어드레스 매핑 - Google Patents

클라이언트 요청 외부 어드레스 매핑 Download PDF

Info

Publication number
KR20060093704A
KR20060093704A KR1020067006250A KR20067006250A KR20060093704A KR 20060093704 A KR20060093704 A KR 20060093704A KR 1020067006250 A KR1020067006250 A KR 1020067006250A KR 20067006250 A KR20067006250 A KR 20067006250A KR 20060093704 A KR20060093704 A KR 20060093704A
Authority
KR
South Korea
Prior art keywords
address
public
local
cream
access
Prior art date
Application number
KR1020067006250A
Other languages
English (en)
Inventor
유르옌 헨리 아이싱크
Original Assignee
코닌클리케 필립스 일렉트로닉스 엔.브이.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 코닌클리케 필립스 일렉트로닉스 엔.브이. filed Critical 코닌클리케 필립스 일렉트로닉스 엔.브이.
Publication of KR20060093704A publication Critical patent/KR20060093704A/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/2514—Translation of Internet protocol [IP] addresses between local and global IP addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/2521—Translation architectures other than single NAT servers
    • H04L61/2525—Translation at a client
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H04L61/2564—NAT traversal for a higher-layer protocol, e.g. for session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H04L61/2585—NAT traversal through application level gateway [ALG]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/167—Adaptation for transition between two IP versions, e.g. between IPv4 and IPv6
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

액세스는 공중 네트워크로 로컬 호스트에 의해 요청된다. 공중 네트워크로의 그 액세스에 사용되는 공개 어드레스가 결정된다. 로컬 호스트에 대응하는 로컬 어드레스는 공개 어드레스에 매핑된다. 공개 어드레스는 로컬 호스트에 리턴된다. 대역외 액세스가 로컬 네트워크 또는 공중 네트워크로인 지를 결정하도록 결정이 해해진다. 대역외 액세스가 공중 네트워크 경우, 액세스는 공중 네트워크에 요청된다. 요청에 응답하여 공개 정보가 수신된다. 공개 정보는 대역외 액세스 동안에 생성된 하나 이상의 패킷들의 페이로드 부분에 배치된다. 공개 정보는 통상적으로 적어도 하나의 공개 포트를 포함하지만, 공개 어드레스를 포함하지는 않는다. 요청은, 공개 정보의 공개 포트가 로컬 포트에 통상적으로 접합하도록 로컬 포트를 공급한다.
로컬 호스트, 공개 포트, 로컬 포트, 인터넷 프로토콜

Description

클라이언트 요청 외부 어드레스 매핑{Client requested external address mapping}
본 발명은 통상적으로 통신 시스템들에 관한 것으로, 보다 구체적으로는 통신 시스템들의 메세지들과 관련되어 어드레싱하는 방법에 관한 것이다.
네트워크들에 접속된 디바이스들은 종종 인터넷 프로토콜(IP) 버젼에 의해 정의되는 어드레스들과 같은 할당된 어드레스들이다. 어드레스들은 네트워크들의 정보로 하여금 정확한 목적지 디바이스로 라우팅되도록 허용한다. 통상적으로, "로컬(local)" 어드레스들 및 "공개(public)" 어드레스들이 있다. 이러한 어드레스들은 예를 들면, 개인 및 공중 영역 각각으로 네트워크들을 분리하는데 사용된다. 개인 영역에 있는 디바이스들은 그 영역의 다른 디바이스들과 상호 동작하는 것이 비교적 자유롭다. 개인 영역의 디바이스가 공개 영역의 디바이스에 접속하고자 할 경우, 또는 그 반대의 경우에, 다수의 제한들이 그 접속에 부과되는 것이 통상적이다. 예를 들면, 보안 제한들은 어딴 타입들의 송신 또는 수신이 개인 및 공개 영역 사이에서 발생하는 것을 허용하지 않는다.
제한들을 제공하고 개인 및 공개 영역의 분리를 허용하기 위하여, 게이트웨이가 통상적으로 사용된다. 게이트웨이에 의해 수행되는 하나의 분리 기능은 어드 레스 변환이다. 다수의 로컬 어드레스들은 개인 영역을 위해 남겨둔다. 통상적으로 게이트웨이는 이러한 로컬 어드레스들을 하나 또는 몇 개의 공중 어드레스들로 변환하며, 이것은 공개 영역(예를 들면, 인터넷)에서 유효하다. 공개 영역의 목적지들은 게이트웨이에 의해 공급되는 공중 어드레스를 사용할 것이며, 게이트웨이는 그 목적지들로부터 개인 영역의 적정 디바이스들로 수신되는 메세지들을 매핑한다. 통상 네트워크 어드레스 변환(NAT)으로 칭해지는 상기 어드레스 변환의 한 가지 이유는 이용 가능한 어드레스들의 수가 한정되어 있기 때문이다.
IP의 형태에서, 인터넷 어드레스는 특정 포맷을 가진다. 이 포맷은 이론적으로 대다수의 디바이스들을 어드레싱하는데 사용될 수 있다. 그러나 어드레스들의 많은 블럭들은 다양한 이유들로 억제된다. 예를 들면, 할당된 어드레스 중 비교적 적은 수의 어드레스를 사용하여도, 회사는 자신에게 할당되는 어드레스들의 블럭을 가질 수 있다. 또한, 개인용, 예를 들면 가정내 사용에 대하여 억제되는 어드레스들의 블럭들도 있다. 따라서, 인터넷상의 어드레스들에 있어서 어드레스 결핍이 있다. NAT가 이러한 문제점을 개선하였지만, NAT는 또한 임의 애플리케이션들을 다룰 경우 문제가 발생한다.
따라서, 네트워크들에 의한 통신을 위해 적절한 어드레스 매핑을 제공하는 기술들을 종래에는 요청하였다.
클라이언트 요청 외부 어드레스 매핑에 있어서 기술들이 보여지고 있다.
본 발명의 제1 양상에서, 공중 네트워크에의 액세스 요청은 로컬 호스트로부터 수신된다. 공중 네트워크에의 액세스에 사용되는 공개 어드레스가 판정된다. 로컬 호스트에 대응하는 로컬 어드레스는 공개 어드레스에 매핑된다. 공개 어드레스는 로컬 호스트로 리턴된다.
또한, 공중 네트워크에서 로컬 호스트로 또는 로컬 호스트에서 공중 네트워크로의 액세스가 있을 수 있다. 하나 이상의 헤더 및 하나 이상의 영역들을 가지는 패킷이 생성될 수 있다. 공개 어드레스는 하나 이상의 페이로드 영역들 중 소정의 영역에 배치될 수 있다. 또한, 로컬 호스트는 액세스용 클로벌 포트를 요청하고, 그 글로벌 포트는 액세스를 위해 로컬 호스트에 매핑될 수 있다.
본 발명의 제2 양상에서, 어느 대역외 액세스가 로컬 네트워크 또는 공중 네트워크에 일어나는 지에 관하여 결정이 행해진다. 대역외 액세스가 공중 네트워크에서 발생하는 경우, 액세스는 공중 네트워크에 요청된다. 그 요청에 응답하여 공개 정보가 수신된다. 공개 정보는 대역외 액세스동안에 생성되는 하나 이상의 패킷들의 페이로드 부분들에 위치된다. 공개 정보는 통상적으로 적어도 공개 포트를 포함하지만, 공개 어드레스를 포함하기도 한다. 요청은 공개 정보의 공개 포트가 로컬 포트에 통상적으로 적합하도록 로컬 포트를 공급한다.
본 발명의 보다 완벽한 이해와, 본 발명의 다른 특징들 및 이점들은 이하의 상세한 설명 및 도면을 참조하여 얻어지게 된다.
도 1은 본 발명의 바람직한 실시예에 따라 통신하는 개인 및 공개 영역을 도시한 도면.
도 2는, 본 발명의 바람직한 실시예에 따라서, 개인 영역의 가정내 호스트와 인터넷상의 호스트 간의 통신 동안에 헤더 어드레스 정보가 어떻게 변화되는 지를 기술하는데 사용되는 테이블.
도 3은 본 발명의 바람직한 실시예에 따라 클라이언트 외부 어드레스 매핑(CREAM) 로컬 호스트의 등록에 관한 오브젝트 상호 작용을 도시한 도면.
도 4는 본 발명의 바람직한 실시예에 따라 CREAM 소켓의 생성에 관한 예시적인 오브젝트 상호 작용을 도시한 도면.
도 5는 본 발명의 바람직한 실시예에 따라 CREAM 소켓을 바인딩하기 위한 예시적인 오브젝트 상호 작용을 도시한 도면.
도 6은 본 발명의 바람직한 실시예에 따라 CREAM 소켓을 접속하기 위한 예시적인 오브젝트 상호 작용을 도시한 도면.
도 7은 본 발명의 바람직한 실시예에 따라 데이터를 수신하기 위한 예시적인 오브젝트 상호 작용을 도시한 도면.
도 8은 본 발명의 바람직한 실시예에 따라 전송 방법을 사용하여 데이터를 전송하기 위한 예시적인 오브젝트 상호 작용을 도시한 도면.
도 9는 본 발명의 바람직한 실시예에 따라 전송 방법을 사용하여 데이터를 전송하기 위한 예시적인 오브젝트 상호 작용을 도시한 도면.
도 10은 본 발명의 바람직한 실시예에 따라 클라이언트 애플리케이션의 경우를 사용하기 위한 예시적인 오브젝트 상호 작용을 도시한 도면.
도 11은 본 발명의 바람직한 실시예에 따라 서버 애플리케이션의 경우를 사 용하기 위한 예시적인 오브젝트 상호 작용을 도시한 도면.
상세한 설명
용이하게 참조하도록, 상세한 설명은 서문; 예시적인 장치 및 방법들; 예시적인 방법 정의들이라고 제목이 붙여진 3개 부분들로 나누어진다; .
서문
전술된 바와 같이, 인터넷상에서 어드레스 결핍이 있다. 특히, 인터넷 프로토콜의 버전 4(IPv4)는 그것의 정의된 IP 어드레스들로 인해 결핍이 생성하는데 도움이 된다. 어드레스 결핍에 응답하여, 다수의 솔루션들은 이러한 결핍을 극복하기 위해 생성되어 왔다. 이러한 솔루션에 대하여, 네트워크 어드레스 변환(NAT) 또는 네트워크 어드레스 포트 변환(NAPT) 기술이 통상적으로 대부분 사용된다.
NAT 및 NAPT는, 공개 인터넷 내에서 사용되는 것처럼 공개 영역 내에서 하나 이상의 어드레스들에 가정내 "개인" 네트워크 내에서 사용되는 것처럼 개인 영역 내에서 어드레스들의 매핑을 허용한다. 통상적으로 사용되고 있지만, NAT 및 NAPT는 적어도 이하와 같은 다수의 단점들이 있다: (1) 대역내 액세스는 구성 시간에서 판정되는 세팅들에 기초해서만 가능하고; (2) 개인 네트워크 및 공개 인터넷의 경계를 지나야 하는 프로토콜들은, 이들 프로토콜들이 어드레싱 정보를 포함하는 경우, 애플리케이션 레이어 게이트웨이(ALG)를 필요로 한다.
NAT 및 NAPT에 적절한 대행은 IPv4 어드레스 결핍을 해결하기 위한 포텐셜을 가지는 특정 영역 인터넷 프로토콜(RSIP:realm-specific Internet protocol)이다. RSIP의 이점들은 그것이 다이나믹하게 대역내 액세스 및 애플리케이션들에 관한 변경없이 ALGs의 부재를 지원한다는 것이다. RSIP의 주요 단점은 현재 설치된 애플리케이션 베이스와 호환 가능하지 않으며 주요 네트워킹 관련 공급자들에 의한 지원이 부족하다는 것이다.
또한, 어드레스 변환 디바이스를 검출 또는 제어하는 것을 허용하여 ALGs 요청을 극복하거나 또는 대역내 액세스 또는 양자를 허용하는 임의 프로토콜들이 존재한다. 이러한 프로토콜의 일례는 유니버설 플러그 및 플레이(UPnP) 게이트웨이 상세이며, 이것은 애플리케이션으로 하여금 어드레스 매핑을 질의하는 것을 허용한다. 이러한 프로토콜의 단점은 애플리케이션이 어드레스 변환이 실행되는 것을 인식해야만 한다는 것이다. 따라서, 기존의 애플리케이션에 대해서가 아니라 새로운 애플리케이션들에 적절하다.
본 발명은 이러한 문제점들에 솔루션들을 제공한다. 구체적으로, 본 발명은 ALGs 요청 없이 사용될 수 있다. 본 발명은 예시적인 실시예에서 공개 어드레스 및 공개 포트와 함께 공개 네트워크에 액세스를 요청하는 로컬 호스트를 제공한다. 로컬 호스트에서 공개 네트워크로의 액세스, 공개 네트워크에서 로컬 호스트로의 액세스, 또는 양쪽 모두의 액세스일 수 있다. 로컬 호스트는 패킷의 페이로드를 충전할 때 공개 어드레스 및 공개 포트를 사용한다. 페이로드를 충전하는데 사용되는 정보는 로컬 호스트에서 애플리케이션으로부터 전해진다. ALGs를 사용하는 종래의 시스템들에서, 로컬 호스트는 로컬 어드레스들 및 로컬 포트들로 패킷의 페이로드를 충전하게 된다. ALG는 페이로드에서 로컬 어드레스들 및 로컬 포트들을 공개 어드레스 및 공개 포트들로 바꾸는데 사용되게 된다. 본 발명의 예시적인 양상에서, 로컬 호스트가 이미 유효한 공개 어드레스들 및 공개 포트들을 가지고 있기 때문에, 본 발명을 사용하여 생성되는 패킷의 페이로드 부분은 이미 공개 어드레스들 및 공개 포트들을 포함하고 있으며, 어떠한 ALG도 요청되지 않는다.
본 발명은 적어도 다음의 이점들을 제공한다:(1) 대역내 액세스는 ALG를 사용하지 않고도 허용된다; (2) 적정 어드레스 변환 디바이스가 생성되며, 이것은 많은 유저들이 운영하는 소비자 전자(CE; consumer electronic) 운영 시스템에 의해 제어 또는 유지될 수 있다; (3) 어떠한 구성도 필요하지 않다. (4) ALG들에 대한 요청이 제거된다; (5) 기존의 애플리케이션들 또는 프로토콜들은 수정없이 가능하게 된다; (6) 현재 설치된 베이스가 사용될 수 있다; (7) UPnP와의 상호 동작이 가능하다; (8) 보안이 증가될 수 있다; (9) CE 디바이스들에 관한 예시적인 실행들이 중요하게 된다.
도 1로 돌아가면, 개인 영역 및 공개 영역는 본 발명의 예시적인 실시예에 따라 통신한다. 개인 영역은 로컬 네트워크(165)를 통해 통신하는 2개의 로컬 호스트(105-1, 105-2)(CREAM 클라이언트라고도 칭해짐) 및 게이트웨이 시스템(135)(CREAM 서버로도 칭해짐)을 포함한다. 개인 영역에 있는 각각의 디바이스는 로컬 어드레스(170-1, 170-2 또는 170-3)(로컬 어드레스, 즉 어드레스들(170)로 칭해지기도 함)를 가진다. 공개 영역은 리모트 호스트(150) 및 게이트웨이 시스템(135)을 포함하며, 이것은 공중 네트워크(160)를 통해 통신한다. 공개 영역에 있는 각각의 디바이스는 공개 어드레스(180-1 또는 180-2)(공개 어드레스, 즉 어드레 스들(180)로 칭해지기도 함)를 가진다. 이러한 일례에서, 게이트웨이 시스템(135)은 로컬 어드레스(170-3) 및 공개 어드레스(180-1) 양자를 가진다. 게이트웨이 시스템(135)이 그것에 할당되는 다수의 개인 어드레스(170) 및 공개 어드레스들(180)을 가질 수 있다.
로컬 호스트들(105-1, 105-2)은 유사할 것으로 기대되지만, 단순하게 하기 위해서 로컬 호스트(105-1)만이 상세하게 도시된다. 로컬 호스트(105-1)는 프로세서(106) 및 메모리(107)를 포함한다. 메모리(107)는 애플리케이션(108), 운영 시스템(109), 전송 제어 프로토콜-인터넷 프로토콜(TCP/IP) 스택(110), CREAM 소켓(111), 로컬 서브넷 리스트(112), 포트(113)를 포함한다. 통상적으로, TCP/IP 스택(110) 및 CREAM 소켓(111)은 운영 시스템(109)의 일부이지만, 그들은 설명을 용이하게 하기 위하여 개별적으로 도시된다. CREAM 소켓(111)은 종래의 소켓들과 식별하기 위하여 그것 자체로 불린다. 예시적인 실시예에서, 본 발명의 기능은 레이어들 내에서 3개 및 4개(도시되지 않음) TCP/IP 스택(110)을 동작시킨다. 게이트웨이 시스템(135)은 메모리(137)에 결합된 프로세서(136)를 포함한다. 메모리(137)는 CREAM 게이트웨이(138), 서브넷 리스트(139), 어드레스 매핑 정보(140), 어드레스, 포트들 및 식별을 가지는 쇼우잉 원 엔트리(showing one entry)(145), 어드레스 변환기(146)를 포함한다. CREAM 게이트웨이(138)는 종래의 게이트웨이와 식별하기 위하여 그것 자체로 칭해진다. 리모트 호스트(150)는 포트(155)를 포함한다.
도 1의 일례에서, 로컬 호스트(105-1)(예로)와 게이트웨이 시스템(135) 사이에서 통신되는 패킷(120-1)이 있다. 패킷(120-1)은 헤더들(121-1) 및 페이로드 (122-1)를 포함한다. 헤더들(122-1)은 헤더 어드레스 정보(123-1)를 포함하며, 이것은 소스 어드레스(125-1), 소스 포트(126-1), 목적지 어드레스(127-1), 목적지 포트(128-1)를 포함한다. 페이로드(122-1)는 페이로드 어드레스 정보(어드레스(129-1) 및 포트(130-1)를 포함), 및 데이터(131-1)를 포함한다. 패킷(120-2)은 게이트웨이 시스템(135)을 통과한 후에 도시된다.
본 명세에서 2개의 어드레스 정보 세트를 기술하고 있다. 한 세트는 헤더 어드레스 정보(123)이고, 또다른 한 세트는 페이로드 어드레스 정보(124)이다. 본 발명의 예시적인 양상은, 예를 들면 ALG들을 사용하지 않고도 기존의 애플리케이션들이 사용될 수 있게 하기 위하여 이러한 어드레스 세트를 취급한다. 그러나 원하는 경우에는 본 발명은 ALG들과 결합하여 사용될 수도 있다는 것이 주목된다.
본 발명의 예시적인 동작은 일례를 통해서 가장 잘 기술되고 있다. 헤더 어드레스 정보(123)를 다루는 예시적인 기술들에 관한 광범위한 설명이 기술되게 된다. 유사하게는, 페이로드 어드레스 정보(124)를 다루는 예시적인 기술들에 관한 광범위한 설명이 기술될 것이다. 바로 그것들에 관한 상세한 설명이 기술될 것이다.
헤더 어드레스 정보(123)에 관하여, 로컬 호스트(105-1)는 목적지와 통신해야 하며, 그것은 개인 또는 공개 영역들에서 있을 수 있다. 예를 들면, 로컬 호스트는 애플리케이션(108)에 의해 생성된 메세지를 목적지에 통신할 수 있다. 이 메세지는 로컬 호스트(105-1)에 의해 패킷(120-1)으로 만들어질 수 있다.
사용되는 헤더(121)의 타입들은 사용되는 프로토콜에 의해 결정된다. 예를 들면, TCP를 사용하는 경우에, 패킷(120)은 헤더(121)에 IP 헤더 및 TCP 헤더를 포함하게 된다. 또다른 일례로서, 유저 데이터그램 프로토콜(UDP)을 사용하는 경우, 패킷(120)은 헤더(12)에 IP 헤더 및 UDP 헤더를 포함하게 된다. IP 헤더는 통상적으로 소스 IP 어드레스(125) 및 목적지 IP 어드레스(127)를 포함한다. 또다른 일례로서, IP 보안 확장(IPsec) 캡술화 보안 프로토콜(ESP)의 경우에, IP 헤더는 IPsec 헤더가 수반된다. 따라서, 헤더(121)의 정확한 구성은 사용되는 프로토콜에 따라 변할 수 있다. 단순하게 하기 위하여, 본 발명의 기술들이 많은 상이한 헤더 타입들 및 그에 대응하는 프로토콜들에 적절하지만, 본 명세서에서는 헤더 어드레스 정보(123)가 도 1에 도시되는 바와 같이 가정된다. 예를 들면, 로컬 호스트(105)와 공중 네트워크(165)간의 액세스는 이하의 프로토콜들 중 임의 것을 사용할 수 있다: 파일 전송 프로토콜(TFT) 코멘트 요청(RFC:request for comment) 959; H.323 국제 원거리 통신 유니온(ITU) 스탠더드; 세션 초기화 프로토콜(SIP) RFC 2543; 리소스 예약 프로토콜(RSIP) RFC 2205; 인터넷 프로토콜 캡술화 보안 프로토콜(IPsec-ESP)RFC 2402; 커버로스 4; 커버로스 5; 텔넷 RFC 854; 알로긴 RFC 1282.
사용되는 프로토콜과 상관없이, TCP/IP 스택(110)은 통상적으로 패킷(120) 및 그것의 헤더들(121)을 생성하는 프로세스이고 페이로드(122)를 위한 스페이스이다. 통상적으로, 애플리케이션(108)은 정보로 페이로드(122-1)를 충전하거나 또는 페이로드(122-1)를 충전하는데 사용되는 정보를 제공하는 엔터티이다. 이하의 설명에서, TCP/IP 스택(110)이 헤더 어드레스 정보(123)를 생성하는 것으로 가정되고 있다는 것을 이해하게 된다. 예를 들면, 이하에서 도시되는 오브젝트 상호 작용도 들에서, 헤더(121)를 생성하는 TCP/IP 스택(110)에 관한 콜들은 명확하게 하기 위하여 도시되지 않고 있지만 발생할 것으로 가정된다.
애플리케이션(108)이 메시지(도시되지 않음)를 리모트 호스트(150)에 전송하고 따라서 공중 네트워크(160)에 액세스를 요청하게 된다고 가정하자. 애플리케이션(108)은 운영 시스템(109), TCP/IP 스택(110), CREAM 소켓(111)과 함께 동작하고, 패킷(120-1)이 생성된다. 애플리케이션(108)은 페이로드(125-1)를 충전하는데 사용되는 정보를 제공한다. 페이로드(122-1)는 이후에 기술되게 된다. 패킷(120-1)은 게이트웨이 시스템(135)에 전송된다. 게이트웨이 시스템(135)은 패킷(120-1)을 받아들이고 CREAM 게이트웨이(138)에 그 패킷(120-1)을 준다. CREAM 게이트웨이(138)는 통상적으로 도 2를 참조하여 이하에서 보다 상세하고 그리고 간단한 방법으로 소스 어드레스(125-1) 및 소스 포트(126-1)를 변경시킨다. 본 발명의 실시예에서, 소스 어드레스(125-1)는 로컬 어드레스(170-1)일 것이고, 소스 포트는 포트(113)에 대응하는 개수이며, 여기서 그 개수는 CREAM 게이트웨이(138)를 이용하여 협상에 의해 결정되어 왔다. 패킷(120-1)의 목적지 어드레스(127-1)는 공개 어드레스(180-2)이며, 통상적으로 목적지 포트는 포트(155)에 대응하는 개수이다.
CREAM 게이트웨이(138)는 패킷(120-2)의 소스 어드레스(125-2)로 소스 어드레스(125-1)를 교체한다. 소스 어드레스(125-2)는 일반적으로 공개 어드레스(180-1)이다. 소스 포트(126-1)는 통상적으로 변경되지 않으며, 소스 포트(126-2)로서 출력된다. 동일하게, 참조 번호(126, 127, 128, 129, 130, 131)는 통상적으로 패킷(102-1)과 패킷(120-2) 사이에서 여전히 변경되지 않는다. CREAM 게이트웨이 (138)는 따라서 "로컬" 소스 어드레스(125-1)(예를 들면 로컬 어드레스(170-1))를 "공개" 소스 어드레스(125-2)(예를 들면, 공개 어드레스(180-1)로 변경함으로써, 로컬 어드레스(170)를 공개 어드레스(180)로 교체한다.
CREAM 게이트웨이(138)는 로컬 소스 어드레스(125-1)를 공개 소스 어드레스(125-2)로 매핑하는데 사용되는 어드레스 매핑(140)을 유지한다. 매핑은 참조 번호 145에 도시되고 이하에서 상세하게 기술되는 바와 같이, 어드레스들, 포트들, 식별을 포함한다. 통상적으로, 로컬 소스 포트(126-1) 및 공개 소스 포트(126-2)는 본 발명의 예시적인 양상하에서 동일하게 된다.
어드레스 변환기(146)는 로컬 어드레스(170)를 공개 어드레스(180)로 변환하기 위하여 CREAM 게이트웨이(138)에 의해 사용된다. 서브넷 리스트(139)는 임의 헤더 어드레스 정보(123)가 변경되어야 하는 지의 여부를 결정하고, 어드레스들이 로컬 어드레스들이고 그것이 공개 어드레스들임을 규정하는데 사용된다. 예를 들면, 로컬 호스트(105-1)가 패킷(120-1)을 로컬 호스트(105-2)로 전송하는 경우, 게이트웨이 시스템(135)은, 헤더 어드레스 정보(123)가 로컬 어드레스들(170)을 포함할 때 어드레스 매핑을 수행할 필요가 없다. 통상적으로, 게이트웨이 시스템(135)은 로컬 호스트들(105-1, 105-2)간에 포함되지 않지만, 게이트웨이 시스템(135)은 로컬 호스트(105-1) 및 로컬 호스트(105-2)가 상이한 서브넷들상에 있는 경우 라우터(도시되지 않음)를 구비한다. 라우터는 서브넷들간에 통신한다. 로컬 호스트(105)가 이하에서 상세하게 기술되는 바와 같이, 다양한 방법을 통해 어드레스 매핑을 요청한다는 것에 주목하여야 한다. 서브넷 리스트(112)는 어드레스 변환이 필요한지의 여부를 결정하기 위하여 로컬 호스트(105-1)에 의해 사용될 수 있다. 본원 명세에서, 어드레스 변환에는 어드레스 매핑(140)과 같은 어드레스 매핑에 따라서 어드레스들을 변경시키는 프로세스가 고려된다.
페이로드 어드레스 정보(124)에 관하여, 종래의 시스템에서, 어드레스(129) 및 포트(130)는 로컬 어드레스들(170) 및 로컬 포트들일 수 있다. 이런 경우인 경우, ALG는 통상적으로 어드레스 매핑들을 생성하기 위하여 게이트웨이 시스템(135)의 일부로서 사용되며 결정된 어드레스 및 포트로 어드레스(129) 및 포트(130)를 교체한다. ALG가 동작하는 방법은 다음과 같다: (1) 어드레스(129-1)가 로컬 어드레스이거나 또는 포트(130-1)가 로컬 포트인 경우, ALG는 공개 여역에 있는 어드레스 또는 포트를 이용하여 어드레스(129-1) 또는 포트(130-1)를 교체하도록 매핑을 생성한다. 어드레스(129-1)가 공개 어드레스이거나 또는 포트(130-1)가 공개 영역에서 유효한 포트인 경우, ALG는 어떠한 것도 하지 않는다. ALG는 통상적으로 그 매핑을 형성하기 위하여 NAT 규칙을 생성한다. 이것은 종래의 게이트웨이 시스템(135)의 일부로서 ALG(도 1에 도시되지 않음)가 사용되는 각각의 프로토콜에 필요함을 의미한다. 전술된 바와 같이, 이것은 불충분하며, 새로운 프로토콜이 개발되거나 또는 오래된 프로토콜이 변경될 때마다 생성되어야 함을 의미한다.
반대로, 본 발명의 예시적인 양상에서, CREAM 게이트웨이(138)는 공개 영역의 적정 공개 어드레스(180) 및 적정 공개 포트(예를 들면, 포트(155))를 결정한다. CREAM 게이트웨이(138)는 요청될 때 애플리케이션에 의해 적정 공개 어드레스(108) 및 적정 포트를 결정하며, 이것들을 그 애플리케이션(108)에 제공한다. 애 플리케이션은 따라서 수정되지 않아도 되는 어드레스(129-1) 및 포트(130-1)와 함께 페이로드 어드레스 정보(124)를 파퓰레이팅하는데 사용되는 정보를 생성한다. CREAM 게이트웨이(138)는 어드레스 매핑에서 적정 공개 어드레스(180) 및 적정 공개 포트의 매핑을 유지한다. 애플리케이션(108)의 현재 설치된 베이스는 본 발명에 사용하는데 적절하고, 그 애플리케이션(108)은 변경될 필요가 없다.
게이트웨이 시스템(135) 및 로컬 호스트(105-1)는 단일 컴퓨터 시스템에 결합될 수 있다는 것에 주목해야 한다. 사실상, 로컬 호스트(105-1), 게이트웨이 시스템(135) 및 리모트 호스트(150)는 단일 컴퓨터 시스템에 모두 결합될 수 있다. 로컬 호스트(105-1) 및 리모트 호스트(150)는 클라이언트 애플리케이션들, 서버 애플리케이션 및 포인트 투 포인트(p2p) 애플리케이션들을 호스팅한다. 애플리케이션의 종류와 상관없이, 로컬 호스트 및 리모트 호스트 모두가 그들 간의 통신을 초기화하는 것이 중요하다.
또한, 함께 접속되는 다수의 네트워크일 수 있고 네스팅될(nested) 수도 있다는 것에 주목해야 한다. 예를 들면, CREAM 게이트웨이(2)를 통해 개인 네트워크(1)에서 분리된 개인 네트워크(2)일 수 있다. CREAM 게이트웨이(1)는 인터넷과 같은 공개 네트워크에서 개인 네트워크(1)를 분리한다. 이러한 특정 네트워크 레이아웃을 사용하여, 개인 네트워크(2)의 호스트가 인터넷의 호스트와 통신하기를 원하는 경우, 대역외 액세스 요청은 개인 네트워크(2) 내에서 CREAM 게이트웨이(2)에 행해진다. 목적지 어드레스를 조사함으로써, CREAM 게이트웨이(2)는 추가 어드레스 변환이 행해져야 함을 알고 있으며, 따라서 또한 개인 네트워크(1)의 CREAM 게 이트웨이(1)에서 대역외 액세스 요청을 실행한다. 이러한 방법에서, 네스팅된 '개인' 네트워크들에 관한 지원이 이용 가능하다. CREAM 동작 가능 개인 네트워크가 CREAM 동작 불가능한 개인 네트워크 내에 네스팅되는 경우에, CREAM 동작 불가능한 개인 네트워크와 공중 네트워크간의 경계를 지나는 프로토콜들에 대하여 CREAM 동작 불가능한 개인 네트워크는 어드레스 변환 기능, 예를 들면 ALG 사용을 여전히 할 수 있다.
애플리케이션(108)은 어드레스들(129-1) 또는 포트(130-1) 또는 양자를 가지는 데이터를 생성하는 임의 애플리케이션일 수 있으며, 그것은 페이로드(122-1)에 배치된다. 예를 들면, 애플리케이션(108)은 다음 중에서 하나 이상일 수 있다: 피어 투 피어 애플리케이션; 어드레스 매핑의 보존을 요청하는 애플리케이션; 리모트 셀(RSH) 애플리케이션; X 윈도 시스템 애플리케이션; X-기간 애플리케이션.
여기서 기술되는 본 발명은, 예를 들면 실행될 경우 본 발명의 실시예들을 구현하는 하나 이상의 프로그램들을 포함하는 메모리(107 또는 137)의 일부로서 머신 판독 가능 매체를 포함하는 제조물로서 구현될 수 있다. 예를 들면, 머신 판독 가능 매체는 CREAM 소켓(111), CREAM 게이트웨이(138) 또는 양자의 단계들을 실행하도록 구성된 프로그램을 포함한다. 머신 판독 가능 매체는, 예를 들면 하드 디스크, 광학 또는 자기 디스크, 전자 메모리, 또는 다른 저장 디바이스와 같은 판독 가능 매체일 수 있다.
도 2로 돌아가서, 테이블은 헤더 어드레스 정보(123)가 개인 영역의 가정내 호스트와 인터넷상의 호스트간의 통신동안 변경되는 방법을 기술하는데 사용되게 된다. 도 2의 일례에서, 로컬 호스트(105-1)는 가정내 호스트이고, 리모트 호스트(150)는 인터넷상의 호스트이다. 제2 행는 가정내 호스트에서 생성하여 인터넷상의 호스트에서 끝나는 통신을 나타내고 있다. 이러한 통신에서, 가정내 호스트의 로컬 IP 어드레스가 (예를 들면, 도 1의 CREAM 게이트웨이(138)에 의하여) 게이트웨이의 공개 IP 어드레스로 변경된다. 소스 포트는 협상동안에 한 번 유익하게 결정된 경우에 변경되지 않은 상태가 된다. 원하는 경우에, 소스 포트는 변경될 수 있다. 제3 행는 인터넷상의 호스트에서 생성하여 가정내 호스트에서 끝나는 통신을 나타내고 있다. 이러한 통신에서, 목적지 IP 어드레스는 가정내 호스트의 로컬 어드레스로 변경된다(예를 들면, 도 1의 CREAM 게이트웨이(138)에 의하여). 목적지 포트는 변경되지 않은 상태가 된다.
도 3 내지 11의 오브젝트 상호 작용도는 적정 페이로드 어드레스 정보(124)를 제공하고 헤더 어드레스 정보(123)를 제공 및 변경(필요할 경우)하는 예시적인 기술을 기술하고 있다. 도 3 내지 11의오브젝트 상호 작용에서 많은 방법 호출은 이미 종래 시스템에서 정의되어 있으며, 본원 기재는 본 발명의 예시적인 양상들을 실행하는데 사용되는 호출들로 특정 변경들을 지적하고 있다. 애플리케이션(108)을 고려하여, 애플리케이션(108)은 현재 실행하는 방법 호출을 단순하게 실행하고, 본 발명의 예시적인 양상들은 애플리케이션(108)이 이미 공개 어드레스들 및 공개 포트들을 가지고 있고 어떠한 ALG들도 요청되지 않도록 적정 공개 어드레스들 및 공개 포트들을 자동적으로 결정한다.
어드레스 변환 사용을 시작하기 전에, CREAM 클라이언트가 CREAM 게이트웨이 (138)에 등록하는 것이 바람직하다. 예시적인 실시예에서, CREAM 클라이언트(105)는 한 번의 등록을 해야 한다; 그러나, 등록은 일정 시간에 한정된다. 이러한 등록 시간은 CREAM 게이트웨이(138)에 의해 모니터링되고, CREAM 클라이언트(105)에서의 성공적인 폴(poll)이후에 게이트웨이(138)에 의해 연장된다. 최대 등록 시간의 값은 게이트웨이에서 구성된다.
도 3은, 운영 시스템(OS)(109)을 동작시킬 수 있는 CREAM을 통한 CREAM 클라이언트(105)의 등록에 관한 오브젝트 상호 작용을 도시한다. CREAM 클라이언트(105)의 개시 동안에, OS(109)는 CREAM 게이트웨이(138)(시퀀스 1)에서 CREAM 클라이언트(105) 그 자체로서 등록한다. CREAM 게이트웨이(138) (시퀀스 2)는 등록을 확인한다. 확인동안에, CREAM 게이트웨이(138)는 로컬 서브넷 리스트(112)를 포함한다. 이러한 정보는 어드레스 변환이 요청되는지의 여부를 결정하기 위하여 CREAM 클라이언트(105)에 의해 사용될 수 있다. 성공적인 등록 이후에, CREAM 클라이언트(105)는 게이트웨이(138)로부터 어드레스 및 포트들 매핑들을 리싱(leasing)할 수 있다.
규칙적인 시간 간격들에서, 게이트웨이(138)는 등록 연장 (시퀀스 3)을 위해 CREAM 클라이언트(105)를 OS(109)를 통해서 폴링한다. 이러한 연장 등록동안에, 게이트웨이(105)는 그것의 OS(109)를 통해서 로컬 서브넷들에서 행해지는 변경들에서 새로운 로컬 서브넷 리스트(112)를 포함할 수 있다. 이러한 경우에, CREAM 클라이언트(105)는 등록에 반응하지 않고, 그 CREAM 클라이언트(105)에 대한 전용 어드레스 및 포트 매핑들은 무효로 된다. 그 경우에 CREAM 클라이언트(105)는 OS(109)를 통해 요청되는 시간 (시퀀스 4) 내에 등록에 반응하고, 전용 어드레스들 및 포트들 매핑은 연장된다.
CREAM 클라이언트(105)의 OS(109)가 셧다운된 경우, CREAM 클라이언트(105)는 OS(109)를 사용하여 게이트웨이에서 등록 해제한다(시퀀스 5). 게이트웨이(138)는 등록 해제 요청 (시퀀스 6)를 확인한다.
도 4는 CREAM 소켓(111)의 생성을 위한 예시적인 오브젝트 상호 작용을 도시하고 있다. 등록된 CREAM 클라이언트(105)에서 동작하는 애플리케이션(108)은 OS(109)를 사용하여 CREAM 소켓(111)(시퀀스 1)을 생성한다. OS(109)는 CREAM 소켓(111) (시퀀스 2)의 새로운 일례를 생성하고 애플리케이션(109)에 핸들(예를 들면, CREAM 소켓(111)을 지적하는)을 리턴한다. 어떠한 통신도 아직 실행되지 않았음에 주의해야 한다.
도 5는 CREAM 소켓(111)을 바인딩하는 예시적인 오브젝트 상호 작용을 도시하고 있다. CREAM 소켓(111)을 임의 수신기 포트에 관련시키기 위하여, 애플리케이션(108)은 등록된 CREAM 클라이너트(105)의 CREAM 소켓(111)(시퀀스 1)에서의 바인딩을 실행한다. 바인딩 호출 동안, CREAM 소켓(111)은 CREAM 게이트웨이(138)에서의 INBOUND_ACCESS_REQUEST 요청을 실행한다(시퀀스 2). INBOUND_ACCESS_CONFIRM(시퀀스 3)에 따르면, 바인딩 호출은 실패하거나 또는 성공하게 된다.
INBOUND_ACCESS_CONFIRM은 애플리케이션(108)에 의해 사용되는 포트와 공개 영역에 사용되는 공개 어드레스를 리턴한다. 애플리케이션(108)은 따라서 적정 공 개 어드레스 및 포트를 가지며 그것의 메세지를 퍼퓰레이팅하게 되며, 이것은 유효한 공개 어드레스 및 포트들과 함께 페이로드(122) 정보로 변환된다. 따라서, 공개 어드레싱 정보로 로컬 어드레싱 정보를 교체하기 위하여 ALG들이 페이로드(122)를 분석할 필요가 없다.
CREAM 소켓(111) 사용 이후에, CREAM 소켓(111)의 수명은 선택 셧다운 호출(시퀀스 4) 및 통상적으로 강제 폐쇄 호출(시퀀스 5)을 사용하여 종료된다. 폐쇄 호출 동안에 소켓은 FREE_LEASE_REQUEST(시퀀스 6)를 사용하여 CREAM 게이트웨이(138)에서 사용되는 모든 리소스를 자유롭게 한다. CREAM 게이트웨이(138)는 FREE_LEASE_CONFIRM(시퀀스 7)을 사용하여 반응하게 된다.
도 6은 CREAM 소켓(111)에 접속하는 예시적인 오브젝트 상호 작용을 도시한다. CREAM 소켓(111)에 관한 결론을 정의하기 위하여, 등록되는 CREAM 클라이언트(105)에서 동작하는 애플리케이션(108)은 CREAM 소켓(111)(시퀀스 1)에서 접속 함수를 호출한다. 이러한 접속 호출 동안에, CREAM 소켓(111)은 CREAM 게이트웨이(138)로부터 이전에 수신된 로컬 서브넷 리스트(112)를 사용하여 목적지 어드레스가 게이트웨이 내에 있는지 또는 게이트웨이 밖에 있는 지를 점검한다. 목적지 어드레스가 게이트웨이(즉, 공개 어드레스) 밖에 있는 경우, OUTBOUND_ACCESS_REQUEST가 실행된다(시퀀스 2). 이러한 요청의 결과는 CREAM 게이트웨이(138)(시퀀스 3)로부터 수신된다. 모든 요청들이 성공하는 경우에, 접속 호출은 성공적으로 리턴하게 된다. 목적지 언드레스가 게이트웨이 내에 있거나(즉, 목적지 어드레스가 로컬 어드레스이거나) 또는 CREAM 소켓(111)이 이미 결합된 경우에, 어떠한 OUTBOUND_ACCESS_REQUEST는 CREAM 게이트웨이(138)에 관하여 행해짐에 주목해야 한다. CREAM 소켓(111)이 이미 결합되고 목적지 어드레스가 로컬인 경우에 요청되는 어드레스 및 포트 매핑은 자유롭게 될 수 있다.
CREAM 소켓(111)(시퀀스 5) 폐쇄 동안에, CREAM 게이트웨이(138)는 리싱된 어드레스 및 포트 매핑(시퀀스 6)을 자유롭게 하도록 요청된다; 이것은 CREAM 게이트웨이(138)(시퀀스 7)에 의해 확인되게 된다.
데이터를 수신하는 경우에, 애플리케이션이 이미 정의된 것을 행할 수 있는 다수의 호출이 있다. 예를 들면, 애플리케이션은 listen0, accept0, recv0, recvfrom0 호출들을 행할 수 있다. 현재는 listen0의 실행에 대해서 어떠한 변경도 보여지지 않는다. accept0의 실행에 대해서 어떠한 변경도 보여지지 않는다. recv0가 접속 소켓에서 사용되기는 하지만, recv0 및 recvfrom0은 통상적으로 소켓이 접속, 결합 또는 양자인 경우에만 동작한다. 따라서, CREAM 리스는 통상적으로 항상 이용 가능하다.
도 7은 데이터를 수신하는 예시적인 오브젝트 상호 작용을 도시하고 있다. 공개 인터넷 내에서 송신기(이 일례에서 리모트 호스트(150))는 CREAM 게이트웨이(138)(시퀀스 1)의 리싱된 어드레스 및 포트에 데이터를 전송한다. 데이터는 패킷(120-2)으로서 전송된다. CREAM 게이트웨이(138)는 리스에 따라 어드레스 매핑 또는 포트 매핑 또는 양자를 수행하며, 이것은 어드레스 및 포트 매핑(시퀀스 2)을 포함한다. 도 1 및 도 2를 참조하여 전술된 바와 같이 어드레스 및 포트 매핑은 공개 어드레스 및 공개 포트들을 헤더 어드레스 정보(124)에서 로컬 어드레스 및 포트들로 변환한다. 이러한 매핑된 패킷(120-1)은 개인 네트워크(165)(시퀀스 3)에 의하여 전송된다. CREAM 소켓(111)은 패킷(120-1)을 수신하고 그 수신된 패킷(120-1)을 그것의 버퍼(시퀀스 4)에 부가한다. 애플리케이션(108)은 버퍼(시퀀스 5)로부터 일정 시간에 임의 포인트에서 상기 패킷(120-1)을 판독하게 된다. 판독후에, 패킷(120-1)은 버퍼(시퀀스 6)로부터 삭제된다.
통상적으로, send0 방법은 접속된 CREAM 소켓(111)에서만 사용될 수 있다. 데이터를 공개 IP 어드레스 및 공개 포트에 전송하는 경우, 필요로 되는 CREAM 리스는 이미 수행되었다. CREAM 리스는 애플리케이션(108)과 리모트 호스트(150)간의 매핑을 포함한다. 이러한 매핑은 도 1의 어드레스 매핑에 통상적으로 저장된다. 따라서, CREAM 클라이언트(105)의 OS(109)는 CREAM 게이트웨이(138)에 패킷(120-1)을 정확히 전송하여야 한다. CREAM 게이트웨이(138)는 로컬 어드레스 또는 로컬 포트 도는 양자를 리싱된 어드레스 및 포트(즉, 공개 어드레스 및 공개 포트)로 대체하고, 수정된 헤더 어드레스 정보(123)를 포함하는 패킷(120-2)을 의도된 수신기에 전송한다.
도 8은 send0 방법을 사용하여 데이터를 전송하는 예시적인 오브젝트 상호 작용을 도시하고 있다. 애플리케이션(108)은 공개 인터넷(시퀀스 1)내에 배치된 수신기(예를 들면, 리모트 호스트(150))에 데이터를 전송한다. 데이터의 TCP/UDP 헤더는 송신기의 로컬 어드레스(예컨대, 소스 어드레스(125-1) 내에서) 및 수신기의 공개 어드레스(예컨대, 목적지 어드레스(127-1) 내에서)를 포함한다. 패킷(125-1)은 디폴트 루트를 이용하여 로컬 네트워크(165)(시퀀스 2)를 통해서 전송된 다. CREAM 게이트웨이(138)가 패킷(125-1)을 수신한 경우에, 로컬 어드레싱 정보는 리싱된 어드레스 또는 포트 매핑(시퀀스 3)으로 대체되고, 나머지 패킷(125-2)은 인터넷(시퀀스 4)을 통해 전송된다. 리싱된 어드레스 또는 포트 매핑은 통상적으로 소스 어드레스(125-1)를 게이트웨이(135)의 인터넷 어드레스(예컨대, 공개 어드레스(180-1)로 변환시키고, 통상적으로 상기의 도 2를 참조하여 전술된 바와 동일하게 포트는 그대로 남아 있는다.
Sendto0는 무접속 프로토콜이 사용되는 경우(예컨대, UDP)에만 사용될 수 있다. 데이터가 로컬 IP 어드레스로 전송되는 경우에, 통상적으로 어떠한 어드레스 매핑도 사용되지 않는다. 데이터가 공개 IP 어드레스로 전송되는 경우, 이미 이용 가능 하지 않은 경우 CREAM 리스가 얻어진다. 이것은 sendto0를 사용하는 경우 점검은 IP 어드레스의 위치에 대하여 실행되어야 하고, 그 점검에 따라서 어드레스 매핑이 사용되거나 또는 사용되지 않음을 의미한다는 것에 주목한다.
도 9는 sento0 방법을 사용하여 데이터를 전송하는 예시적인 오브젝트 상호 작용을 도시하고 있다. 애플리케이션(108)은 특정 포트 및 IP 어드레스(시퀀스1)에 데이터를 전송한다. 우선, 로컬 서브넷 리스트(112)에 따라서 목적지 어드레스(127-1)가 로컬인지 또는 공개인지에 관한 점검이 행해진다. 목적지 어드레스(127-1)가 공개이고 어떠한 리스도 아직 행해지지 않은 경우에(예컨대, OUTBOUND_ACCESS_REQUEST 또는 INBOUND_ACCESS_REQUEST)), 리스는 CREAM 게이트웨이(138)(시퀀스 2 및 반응 시퀀스 3)로부터 얻어진다. 패킷은 로컬 어드레스 정보를 가지고 생성되어, CREAM 게이트웨이(138)(시퀀스 4)에 전송된다. CREAM 게이트 웨이(138)는 로컬 어드레스 정보 또는 포트 정보 또는 양자를 리싱된 어드레스 및 포트 결합(시퀀스 5)으로 교체하고, 공개 네트워크(시퀀스6)에 의하여 패킷(120-2)을 전송한다.
소켓(시퀀스 7) 폐쇄 이후에, 얻어진 CREAM 리스는 자유롭게 된다(시퀀스 8 및 확인 시퀀스 9).
본 발명의 한 이점은 패킷들의 페이로드 내에서 어드레싱 정보를 포함하는 것이 가능하다는 것이다. 그러나, 고려해야 할 것이 약간 있다. 정확한 어드레싱 정보를 얻기 위하여, 애플리케이션(108)은 일정 시간의 정확한 지점에서 정확한 기능들을 호출해야 한다. 또한, 이러한 기능들의 정확한 동작이 OS(109)에 의해 실행되어야 한다.
어드레싱 정보를 리턴하는 모든 기능들, 예를 들면 getsocket0, getostname0, getaddrinfo0은 로컬 CREAM 클라이언트(105)의 IP 어드레스 및 포트에 대한 이하의 값들을 리턴한다:
(1) CREAM 소켓(111)이 공개 IP 어드레스로 피어에 접속되는 경우에, CREAM의 IP 어드레스는 리싱된 IP 어드레스이다. 포트 수는 리싱된 포트 수이다.
(2) CREAM 소켓(111)이 개인 IP 어드레스로 피어에 접속되는 경우에, CREAM 클라이언트(105)의 IP 어드레스는 그 자신의 로컬 IP 어드레스이다. 포트 수는 로컬 포트 수이다.
(3) 비접속된 소켓의 경우에, 어떠한 유효 IP 어드레스도 리턴되지 않는다. (유효 IP 어드레스는 개인 또는 리싱 IP 어드레스이지만, 피어에 따라 상이하다.) 이 경우에, 그 값 널은 리턴한다.
IP 어드레스가 통상적으로 피어의 IP 어드레스에 따라서만 결정된다는 점때문에, 애플리케이션들은 IP 어드레스들이 페이로드 내에 포함되는 경우 CREAM 클라이언트(105)의 IP 어드레스는 페이로드를 포함한 패킷의 수신기에 접속된 CREAM 소켓(111)으로부터 결정되어야 함을 인식해야 한다.
본 발명에 따라 어드레스 매핑 유저들은 애플리케이션들(108)이다. 애플리케이션(108)은, 예를 들면 서버 애플리케이션 또는 CREAM 클라이언트 애플리케이션일 수 있다. 가정내 통신의 특성으로 인해, 주요 유저는 CREAM 클라이언트 애플리케이션이며, 그것에 대하여 서버 애플리케이션은 인터넷 내에 있다. CREAM 클라이언트 애플리케이션들외에, 본 발명은 또한 CREAM 클라이언트 애플리케이션들이 인터넷 내에 있는 서버 애플리케이션들에 사용될 수도 있다. 그러나, 이러한 마지막 카테고리의 유저들은 임의 제한에 한정될 수 있다.
도 10은 CREAM 클라이언트 애플리케이션의 사용의 경우에 대한 예시적인 오브젝트 상호 작용을 도시하고 있다. 이 도면에서, 일례는 CREAM 클라이너트 애플리케이션(108)이 CREAM 게이트웨이(138)의 경계를 지나도록(예를 들면, 개인 영역에서 공개 영역으로 진행) 본원에서 나타내는 기술들을 이용하여 서버 애플리케이션(예컨대, 공개 호스트(150)에서)에 접속하는 경우 상호 작용에 관하여 제공된다. 이러한 일례에서, CREAM 클라이언트 애플리케이션(108)은 개인 네트워크(165) 내에 배치되고, 서버 애플리케이션은 인터넷(예를 들면, 공개 네트워크(160)) 내에 배치된다.
CREAM 클라이언트(105)의 개시 동안에 CREAM 클라이언트(105)는 CREAM 게이트웨이(138)(시퀀스 1 및 2)에서 그 자체를 등록한다.
공개 호스트(150)에서 서버 애플리케이션에 통신하기 위하여, 애플리케이션(108)은 CREAM 소켓(111)(시퀀스 3)을 생성한다. CREAM 소켓(111) 생성 이후에, 애플리케이션(108)은 서버(시퀀스4)에 접속하기 위하여 CREAM 소켓(111)을 사용한다. 애플리케이션(108)은, 임의 포트로부터 리모트 호스트(150)에 있는 서버 애플리케이션에 통신할 수 있기 때문에 CREAM 소켓(111)을 명확하게 결합하지 않는다. CREAM 소켓(111)이 실제로 리모트 호스트(150)에 접속하기 전에, 우선은 서버 애플리케이션이 개인 네트워크(165)에 또는 인터넷(예를 들면, 공개 네트워크(160)에 있는 지에 관한 점검이 행해져야 한다. 이러한 점검은, 이한 일례에서, 로컬 서브넷 리스트(112)를 사용하여 실행된다. 이 일례에 대하여, 목적지 IP 어드레스는, OUTBOUND_ACCESS_REQUEST가 실행되도록(시퀀스 5, 6), 공개이다. 성공적인 OUTBOUND_ACCESS_REQUEST 이후, connect0 방법에 관련된 디폴트 동작이 이제 실행될 수 있따. 애플리케이션(108)이 소스 측에서 CREAM 소켓(111)의 IP 어드레스 및 포트를 요청하는 경우에, 리싱된 IP 어드레스 및 포트 수는 리턴된다. 통상적으로, 리싱된 IP 어드레스 및 포트 수는 로컬 IP 어드레스와 상이하고, 심지어는 국부적으로 사용되는 포트와도 상이할 수 있다.
규칙적인 시간 간격에서, CREAM 게이트웨이(138)는 EXTENT_REGISTRATION_INDICATION(시퀀스 7)를 실행함으로써 리스 시간을 연장할 수 있고, 이것은 CREAM 클라이언트(105)로부터 EXTENT_REGISTRATION_INDICATION(시퀀 스 8)을 트리거링한다.
애플리케이션(108)이 서버(시퀀스9)에 데이터를 전송하는 경우, CREAM 소켓(111)은 IP, TCP/UDP 헤더들(시퀀스 10) 내에서 로컬 어드레싱 정보를 사용하여 서버 애플리케이션에 이 데이터를 전송한다. CREAM 게이트웨이(138)는 패킷을 차단하고 IP, TCP/UDP 헤더들(예를 들면, 헤더 어드레스 정보(123))(시퀀스11) 내에서 로컬 어드레싱 정보를 교체하고, 그것을 공개 리모트 호스트(150)(시퀀스 12)상의 서버 애플리케이션에 전송한다.
애플리케이션(108)이 CREAM 소켓(111)(시퀀스 13)을 폐쇄하는 경우 또는 심지어 OS(109)가 CREAM 소켓(111)을 폐쇄하는 경우에도, CREAM 소켓(111)은 리싱된 IP 어드레스 및 포트 결합(시퀀스 14, 15)을 자유롭게 한다.
CREAM 클라이언트(105)의 OS(109)가 섯다운되는 경우에, CREAM 클라이언트(105)는 CREAM 게이트웨이(138)(시퀀스 16, 17)에서 등록 해제한다.
도 11은 서버 애플리케이션(108) 사용에 관한 예시적인 오브젝트 상호 작용을 도시하고 있다. 이 도면 내에서, 일례는 서버 애플리케이션(108)이 청취 포트를 개방하고 가정내 클라이언트 애플리케이션(105-2) 및 공개 클라이언트 애플리케이션(150)이 이 서버 애플리케이션(108)에 접속하는 경우 상호 작용에 관하여 제공된다. 이 일례에서, 서버 애플리케이션(108)은 개인 네트워크(165)이고 로컬 호스트(105-1)의일부이며, 한 클라이언트 애플리케이션(공개 호스트(150)의 일부로서)이 인터넷(예를 들면, 공중 네트워크(160)) 내에 배치되고 한 클라이언트 애플리케이션(로컬 호스트(105-2)의 일부로서)이 개인 네트워크(165) 내에 배치된다. 단순 하게 하기 위하여, 공개 호스트(150)의 일부인 클라이언트 애플리케이션은 "클라이언트 애플리케이션(150)"으로 칭해지게 된다. 동일하게는, 로컬 호스트(105-2)의 일부인 클라이언트 애플리케이션은 "클라이언트 애플리케이션(105-2)"으로 칭해지게 된다. 서버 애플리케이션(108)은 인터넷 내에 배치된 클라이언트 애플리케이션(150)과 통신하도록 본원에 나타나는 기술을 사용한다.
OS(109) 개시시에, CREAM 클라이언트(105-1)는 CREAM 게이트웨이(138)(시퀀스 1,2)에 등록한다.
들어오는 통신을 수신하기 위하여, 서버 애플리케이션(108)은 통상적으로 CREAM 소켓(111)(시퀀스 3)을 생성한다. CREAM 소켓(111)의 생성 이후에, 서버 애플리케이션(108)은 특정 포트에서 들어오는 메세지를 청취하는데 CREAM 소켓(11)을 사용하며, 따라서 서버 애플리케이션(108)은 포트(시퀀스 4)에 CREAM 소켓(111)을 결합한다. CREAM 소켓(111)이 이러한 결합이 내부 포트 수, 외부 포트 수 또는 양자에서 발생하는 지를 결정할 수 없기 때문에, CREAM 소켓(111)은 내부 및 외부 포트 모두에 결합된다. CREAM 소켓(111)을 외부 포트에 결합하기 위하여, 포트 및 어드레스 결합은 CREAM 클라이언트(시퀀스5, 6)에 의해 CREAM 게이트웨이(138)에서 리싱된다. 포트 리싱에 사용되는 포트 수는 결합 요청 내에서 사용된 것과 동일하여, 알려진 포트 컨벤션은 파괴되지 않는다. 어떠한 포트 수도 명시되지 않은 경우에, CREAM 게이트웨이(138)는 포트 수를 할당한다. 내부 포트 및 외부 포트의 포트 수는 통상적으로 동일하게 유지되어, 잠재적인 포트 매핑 충돌이 제거된다.
규칙적인 시간 간격에서, CREAM 게이트웨이(138)는 EXTEND_REGISTRATION_INDICATION(시퀀스7)를 실행함으로써 리스 시간을 연장할 수 있다. 이것은 CREAM 클라이언트(105-1)로부터 EXTEND_REGISTRATION_INDICATION(시퀀스8)를 트리거링한다. 애플리케이션(108)은 청취 상태(시퀀스 9)에서 CREAM 소켓(111)을 세팅한다.
로컬 가정내 클라이언트 애플리케이션(105-2)은 서버 애플리케이션(108)(시퀀스 10)에 데이터를 전송한다. 이 통신은 로컬이다는 사실로 인해, 어떠한 어드레스 또는 포트 매핑도 실행되지 않는다. CREAM 소켓(111)은 패킷들을 그것의 버퍼(시퀀스 11)에 부가한다. 서버 애플리케이션(108)은 로컬 호스트(105-2)(시퀀스 12)로부터 로컬 클라이언트 애플리케이션과의 접속을 승인하는데 accept0 방법을 사용한다. 서버 애플리케이션(108)은 recv0 호출(시퀀스 13)을 사용하여 그것의 큐를 판독하고, CREAM 소켓(111)은 서버 애플리케이션(108)에 패킷을 제공하기 위하여 그것의 버퍼(시퀀스 14)로부터의 패킷을 제거한다.
공개 인터넷 내에서 클라이언트 애플리케이션(150)은 서버 애플리케이션(108)(시퀀스 15)에 데이터를 전송한다. IP, TCP/UDP 헤더들에 포함되는 리싱된 어드레스 및 포트 결합은 CREAM게이트웨이(138)(시퀀스 16)에 의한 로컬 어드레스 및 포트 결합에 매핑되고, 그 패킷은 로컬 서버 애플리케이션(108)(시퀀스17)에 전송된다. CREAM 소켓(111)은 그 버퍼(시퀀스 18)에 재매핑된 패킷을 부가한다. 서버 애플리케이션(108)은 공개 호스트(150)(시퀀스 19)로부터 공개 클라이언트 애플리케이션과의 접속을 승인하는데 accept0 방법을 사용한다. 서버 애플리케이션은 recv0(시퀀스 20)을 호출함으로써 큐로부터 데이터를 판독하고, CREAM 소켓(111)은 서버 애플리케이션(108)에 전송하기 위하여 그것의 버퍼(시퀀스 21)로부터의 패킷을 제거한다.
OS(109)가 셧다운되는 경우, CREAM 클라이언트(105-1)는 CREAM 게이트웨이(138)(시퀀스 22, 23)에서 재등록한다.
본 발명의 기술이 이로울 다른 예시적인 경우들이 있다. 몇가지 경우들이 이하에서 기술된다.
로컬 호스트 등록은 다음과 같이 실행될 수 있다. CREAM 클라이언트(105)의 OS(109) 개시 동안에, CREAM 클라이언트(105)는 통상적으로 CREAM 게이트웨이(138)에서 등록한다. CREAM 게이트웨이(138)는 등록을 승인하거나 또는 CREAM 클라이언트(105)가 이미 등록되어 있다는 것을 나타낸다.
첫번째 경우(예를 들면, 등록이 승이됨), 어떠한 리스도 CREAM 클라이언트(105)에 대하여 아직 행해지지 않는다. 마지막의 경우에(예를 들면, CREAM 클라이언트(105)는 이미 등록됨), CREAM 클라이언트(105)에 관련된 현행 리스에 어떠한 변경도 행해지지 않는다. 양자의 경우에, CREAM 클라이언트(105)는 등록된다. CREAM 클라이언트(105)가 등록된다. CREAM 클라이언트(105)의 OS(109)가 임의 기존 리스들을 인식하지 않는 경우, CREAM 클라이언트(105)는, CREAM 클라이언트(105)가 다시 등록하기 전에 리소스들이 자유롭게 되도록 우선 등록 해제한다.
본 발명의 예시적인 한 양상에서, 등록 확인 동안에 테이블은 로컬 어드레스 범위들을 표시하는 테이블이 리턴된다. 이 테이블은 또한 이미 등록된 표시동안에 포함된다.
로컬 호스트-등록 또는 셧다운의 일례는 다음과 같다. OS(109)의 셧다운 동안에, CREAM 클라이언트(105)는 CREAM 게이트웨이(138)에서 등록 해제하다. CREAM 게이트웨이(138)는 CREAM 클라이언트(105)가 등록 해제되었는지를 확인하거나 또는 CREAM 클라이언트(105)가 등록되지 않았는지를 표시한다. 양자의 경우에, 어떠한 리소들도 CREAM 게이트웨이(138)에서 CREAM 클라이언트(105)에 대하여 더이상 사용되지 않는다.
청취 포트는 다음과 같이 생성될 수 있다. CREAM 클라이언트(105)는 대역내 액세스를 위해 어드레스 및 포트 결합을 리싱하도록 CREAM 게이트웨이(138)에서 INBOUND_ACCESS_REQUEST를 확인한다. 로컬 포트 수 및 리싱된 포트 수는, 이것이 그 경우가 되지 않아도 CREAM 게이트웨이(138)에 의해 동일하게 가정된다.
CREAM 클라이언트(105)는 리싱된 포트 수(예를 들면 http 서버에 대하여 포트 80개)가 되도록 명시할 수 있고, 이 경우에 CREAM 게이트웨이(138)는 리스를 확인하거나 또는 그 리스를 거절한다.
CREAM 클라이언트(105)는 또한 어떠한 포트 수도 명시하지 않을 수 있다. 이 경우에, CREAM 게이트웨이(138)는 포트 수를 명시하고 그 리스를 확인한다. 동일한 로컬 포트 수가 이용 가능하지 않은 경우에, CREAM 클라이언트(105)는 리스를 자유롭게 하고 대역내 액세스 포트를 리싱하도록 재실행한다.
포트 리싱의 특성으로 인해, 포트는 TCP 타임 아웃 시간이후에 다시 리스에 이용 가능하게 되고, 이것은 TCP 접속들의 바람직하지 않은 재접속을 방지하는데 좋다.
송신 포트를 생성하는 일례를 다음과 같다. CREAM 로컬 호스트(105)는 대역외 액세스에 대하여 어드레스 및 포트 결합을 리싱하도록 CREAM 게이트웨이(138)에서 OUTBOUND_ACCESS_REQUEST를 실행한다. CREAM 로컬 호스트(105)는 포스 수를 리싱되도록 명시할 수 있으며, 이 경우에 CREAM 게이트웨이(138)는 리스를 확인하거나 또는 그 리스를 거절한다.
CREAM 로컬 호스트(105)는 또한 어떠한 포트 수도 명시하지 않을 수 있으며, 이 경우에 CREAM 게이트웨이(138)는 포스 수를 명시하고 그 리스를 확인한다.
포트 리싱 특성상, 포트는 TCP 타임 아웃 타임 이후에 다시 리스에 이용 가능하게 되며, 이것은 TCP 접속들의 바람직하지 않은 재접속을 방지하는데 바람직하다.
피어를 리솔브하는 일례는 다음과 같다. CREAM 로컬 호스트(105)는 등록 요청 내에 포함된 테이블을 사용하거나 또는 RESOLVE_PEER_REQUEST 기능을 사용하거나 또는 양자를 사용하여, 피어가 인터넷 또는 로컬 네트워크 내에서 배치되는 지를 결정한다.
선택된 리소스들을 자유롭게 하는 일례는 다음과 같다. 등록된 CREAM 로컬 호스트(105)는 매핑(들)과 관련된 리싱된 어드레스(들) 또는 포트(들)을 정의함으로써 하나 이상의 어드레스 및 포트 매핑을 자유롭게 하도록 CREAM 게이트웨이(138)를 요청할 수 있다. 또한, 모든 리소스들은 등록 해제 확인 이후에 자유롭게 된다.
예시적인 방법 정의들
이하에서 사용되는 정의들은 다음과 같다:
호스트 IP 어드레스를 가지는 임의 디바이스
CREAM 로컬 호스트 CREAM 프로토콜을 지원하는 호스트
CREAM 게이트웨이 CREAM 프로토콜을 지원하는 게이트웨이
리모트 호스트 공중 인터넷에 있는 호스트
로컬 호스트 개인 네트워크에 있는 호스트; 개인 영역 내에 IP
어드레스를 가짐
로컬 어드레스 개인 영역내의 IP 어드레스
공개 어드레스 인터넷의 공개 영역내의 IP 어드레스
이하에서 사용되는 두문자어 및 약어는 다음과 같다;
CREAM 클라이언트 요청 외부 어드레스 매핑
ALG 애플리케이션 레벨 게이트웨이
NAT 네트워크 어드레스 변환
NAPT 네트워크 어드레스 포트 변환
통상적인 표시법 관례들은 다음과 같다: 신택스에 대하여 이하의 표시법 관례들이 사용된다. 각각의 파라미터는 이하의 방법으로 정의된다.
통상적인 패킷 기술:
이름 값 바이트들의 수
이름1 값1 길이1 이름2 <값2> 길이2 이름3 <값3> <값2> <파라미터 1> %파라미터2%
표시법 관례들을 사용하여 패킷 부분은 이하의 신택스를 포함한다:
길이 1은 고정된 소정의 길이(예를 들면, 1x02)이다. 값1은 고정된 소정의 값(예를 들면, 0x01)이다. 이름1은 패킷 콘텐츠(예를 들면, My1stvariable)에 따라 상이하다. 이러한 정보를 사용하여 제1 2개 바이트들은; 바이트 0, 1; 고정 값(0x01) 및 고정 길이(0x02)와 함께 변수 My1stvariable를 포함한다.
제1 표시법의 일례:
이름 값 바이트들 수
My1stvariable 0x0001 0x02 이름2 <값2> 길이2 이름3 <값3> <값2> <파라미터1> %파라미터2%
길이2는 고정된 소정의 길이(예를 들면, 0x04)이다. 값2는 모난 괄호<>와 식별되는 변수(예를 들면, 문자열에서 다수의 문자들)이다. 그러나, 값은 그것의 신택스 및 의미에 따라 된다. 이름2는 패킷 콘텐츠(예를 들면, LengthOfName)에 따라 상이하다. 이러한 정보 바이트들 2 내지 5는 고정 길이(0x04)의 value#CharsString 과 함께 변수 LengthOfName을 포함한다.
제2 표시법의 일례:
이름 값 바이트들 수
My1stvariable 0x0001 0x02 LengthOfName <#CharsString> 0x04 이름3 <값3> <값2> <파라미터1> %파라미터2%
값2는 소정의 변수의 값이며, 이 경우에 변수 이름2(이전에 "LengthOfName"d으로 불리어진 문자열의 길이를 정의함)값이고, 이것은 모난 괄호<>들로 표시된다. 값3은 값이며, 길이(예를 들면, 값2 문자들을 가지는 문자열)에 따라 상이하다. 이름3은 파라민터의 이름을 나타낸다. 이름3은 패킷 콘텐츠(예를 들면, Local hostName)에 따라 상이하다. 이러한 정보를 사용하여, 바이트들 6 내지 #CharsString+5는 #CharsString 문자들 길이의 변수 Local hostName을 표시하는 문자열을 포함한다.
제2 표시법의 일례:
이름 값 바이트들 수
My1stvariable 0x0001 0x02 LengthOfName <#CharsString> 0x04 LocalhostName <로컬 호스트의 이름> <#CharsString> <파라미터1> %파라미터2%
파라미터1은 소정의 파라미터(예를 들면, 버젼)이다. 이 파라미터는 그들 자신의 내부 신택스 및 의미를 가진다. 백분률 부호들간의 파라미터들은 이 파라미터가 강제적임을 나타낸다. 이러한 정보를 사용하여, 변수 Local hostName은 파라미터 버젼이 수반된다.
제4 표시법의 일례:
이름 값 바이트들 수
My1stvariable 0x0001 0x02 LengthOfName <#CharsString> 0x04 LocalhostName <로컬 호스트의 이름> <#CharsString> <버젼> %파라미터2%
파라미터 2는 또한 소정의 파라미터(예를 들면, Address)이다. 그러나, 모난 괄호<>는 이 파라미터가 선택적임을 나타낸다. 이 정보를 사용하여, 버젼 파라미터는 Address 파라미터가 수반될 수 있다.
제5 표시법의 일례:
이름 값 바이트들 수
My1stvariable 0x0001 0x02 LengthOfName <#CharsString> 0x04 LocalhostName <로컬 호스트의 이름> <#CharsString> <버젼> %Address%
통상적인 파라미터 정의
CREAM내의 모든 파라미터들은 이하의 관례를 사용하여 정의된다:
이름 값 바이트들 수
타입 <타입> 0x01 길이 <길이> 0x02 값 <값> <길이 값>
타입 : 타입 값은 파라미터의 타입을 정의한다. 정확한 값은 파라미터의 타입에 따라 상이하고 파라미터 정의 사이에 명시된다.
길이 : 값을 포함한 바이트들의 개수를 정의한다. 값은 실제 파라미터 대이터를 포함한다; 길이는 타입 및 콘텐츠에 따라 상이하다.
버젼(0x00) : 버젼 필드는 CREAM 프로토콜의 버젼을 식별한다.
이름 값 바이트들 수
타입 0x00 0x01 길이 0x0001 0x02 버전 0x01 0x01
버젼 : 이 CREAM 프로토콜의 버젼을 포함한다. 현재, 오직 버젼 1만이 기술된다. 총 버젼 TLV의 길이는 고정되어 있으며 모든 버젼의 CREAM 프로토콜에 대하여 여전히 변경되지 않는다.
Address(0x01)
어드레스 필드는 어드레싱 정보를 포함한다. 이하의 어드레스 타입이 지원된다:
IPv4:
이름 값 바이트들 수
타입 0x01 0x01 길이 0x005 0x02 Address_Type 0x01 0x01 Address <IPv4address> 0x04
IPv4 netmask:
이름 값 바이트들 수
타입 0x01 0x01 길이 0x0005 0x02 Address_Type 0x02 0x01 Address <IPv4 netmask address> 0x04
IPv6:
이름 값 바이트들 수
타입 0x01 0x01 길이 0x0011 0x02 Address_Type 0x03 0x01 Address <IPv6 address> 0x10
FQDN:
이름 값 바이트들 수
타입 0x01 0x01 길이 0x0001+어드레스 길이 0x02 Address_Type 0x01 0x01 Address <ASCII String> <어드레스 길이>
FQDN은 어떠한 종료 문자도 포함되지 않은 ASCII 문자열로서 표시되게 된다.
포트(0x02): 포트 필드는 제로 또는 그 이상의 TCP 또는 UDP 포트들을 포함한다. 그 포트 파라미터내에서, Number_Of_Ports 필드는 포함된 포트들의 개수를 명시한다. Number_Of_Ports의 값은 길이 필드로부터 유도될 수 있다.
IPv4:
이름 값 바이트들 수
타입 0x01 0x01 길이 0x0001+2*ports 0x02 Number_Of_Ports <#ports> 0x01 {for(I=0;I<Number_Of_Ports;I++) Port I <포트 개수 I> 0x02 Protocol I} <프로토콜 I> 0x02
프로토콜들에 관한 이하의 값들은 다음과 같이 지원된다:
값 의미
0x0000 UDP 프로토콜
0x0001 TCP 프로토콜
포트 매핑(0x03):
포토 매핑 파라미터는 로컬 포트와 외부 포트간의 매핑을 포함한다. 포트 매핑 파라미터는 제로 또는 그 이상의 TCP 또는 UDP 포트 매핑들을 포함한다. 그 포트 매핑 파라미터 내에서 Number_Of_Mappings 필드는 포함되는 포트 매핑들의 개수를 명시한다. Numver_Of_Ports_Mapping은 길이 필드로부터 유도될 수 있다.
IPv4:
이름 값 바이트들 수
타입 0x03 0x01 길이 0x0001+6#ports mapping 0x02 Number_Of_Port_Mappings <#ports mappings> 0x01 {for(I=0;I<Number_Of_Ports_Mapping; I++) 로컬 포트 <포트 개수> 0x02 외부 포트 <포트 개수> 0x02 프로토콜 <프로토콜> 0x02 Status_Code <상태 코드> 0x02 }
이하의 상태 코드들은 다음과 같이 지원된다:
값 의미
0x0000 생성된 매핑(성공)
0x0001 이미 이용 가능한 매핑(성공)
0x1000 매핑 생성 불가능, 액세스 제한(실패)
0x1001 매핑 생성에 불가능, 이미 사용중인 포트(실패)
프로토콜 필드에 지원되는 값들은 포트 매핑(0x03)에서 프로토콜에 대한 값들에 관하여 상기 테이블에서 정의된다.
로컬 호스트 ID(0X04):
로컬 호스트 ID 파라미터는 CREAM 로컬 호스트 ID를 명시한다. 로컬 호스트 ID는 CREAM 로컬 호스트들간에 상이하도록 CREAM 게이트웨이에 의해 사용된다.
이름 값 바이트들 수
타입 0x04 0x01 길이 0x0004 0x02 로컬 호스트 ID <로컬 호스트 ID> 0x04
리스 ID(0x05):
리스 ID 파라미터는 CREAM 리스 ID를 명시한다. 리스 ID는 CREAM 로컬 호스트들 및 CREAM 게이트웨이에 의해 사용되어 CREAM 결합들 사이에서 상이하게 된다.
이름 값 바이트들 수
타입 0x04 0x01 길이 0x0004 0x02 Lease_ID <리스ID> 0x04
로컬 서브넷 리스트(0x06):
로컬 서브넷 리스트는 로컬 서브넷 세트의 목적지를 포함한다.
이름 값 바이트들 수
타입 0x04 0x01 길이 <나머지 길이> 0x02 Number_Local_Subnets <#로컬 서브넷> 0x02 for(I=0;I<Number_Local_Subnets;1+1) { 옵션 1: <어드레스(IPv4)> <어드레스(IPv4 넷마스트)> 옵션 2: <어드레스(IPx4)> ....CIDR_Routing_Bits <CIDR 표시된 라우팅 비트들> 0x01 }
메세지 타입(0x10):
메세지 타입은 메세지의 타입을 명시한다. 그 메세지에 따라서, 상기는 패킷의 콘텐츠를 정의하고 및/또는 이전에 전송된 패킷을 언급한다.
이름 값 바이트들 수
타입 0x04 0x01 길이 0x0001 0x02 Message_Type <메세지 타입> 0x01
이하의 메시지 타입들은 다음과 같이 정의된다:
값 의미
0x00 REGISTRATION_REQUEST
0x01 REGISTRATION_CONFIRM
0x02 EXTENDED_REGISTRATION_INDICATION
0x03 EXTENDED_REGISTRATION_RESPONSE
0x04 DE_REGISTRATION_REQUEST
0x05 DE_REGISTRATION_CONFIRM
0x06 INBOUND_ACCESS_REQUEST
0x07 INBOUND_ACCESS_CONFIRM
0x08 OUTBOUND_ACCESS_REQUEST
0x09 OUTBOUND_ACCESS_CONFIRM
0x0A FREE_LEASE_REQUEST
0x0B FREE_LEASE_CONFIRM
0xF0 ERR_INDICATION
0xFF 알려지지 않은 메세지 타입
메세지 타입 TLV의 길이는 고정되고 모든 CREAM 버젼에 관하여 여전히 변경되지 않는다.
REGISTRATION_REQUEST
기술:
이 메세지는 CREAM게이트웨이에서 CREAM 로컬 호스트를 등록하는데 사용된다.
신택스:
이름 값 바이트들 수
<버젼> <Message_Type (REGISTRATION_REQUEST)> 길이 0x00 0x02
의미들은 다음과 같다:
버젼 : 상기의 버젼 정보 참고
Message_Type : 메세지 타입은 REGISTRATION_REQUEST 메세지를 표시해야 한다.
길이 : 패키지의 총 나머지 길이는, 상기 버젼에 대하여 0x00으로 동일하다.
등록하기 위하여, CREAM 게이트웨이는 사용되는 CREAM 프로토콜의 타입 및 메세지의 콘텐츠(REGISTRATION_REQUEST)를 인지한다. CREAM 로컬 호스트는 로컬 호스트가 등록되지 않았을 때 REGISTRATION_REQUEST를 전송하도록 허용된다.
동작:
CREAM 게이트웨이는 REGISTRATION_CONFIRM 또는 ERROR_INDICATION 메세지에 응답해야 한다.
REGISTRATION_CONFIRM
기술:
이 메세지는 CREAM 로컬 호스트의 등록을 확인하는데 사용된다.
신택스:
이름 값 바이트들 수
<버젼> <Message_Type (REGISTRATION_CONFIRM)> 길이 <나머지 길이 0x02 <로컬 호스트 ID> <로컬 서브넷 리스트>
의미들:
버젼 : CREAM 프로토콜의 버젼을 정의한다.
메세지 타입 : 메세지 타입을 정의한다; 명시된 메세지는 REGISTRAION_CONFIRM이어야 한다.
길이 : 상기 메세지의 총 나머지 길이를 정의한다.
로컬 호스트 ID ; CREAM 게이트웨이에 의해 할당되는 로컬 호스트 ID를 정의한다. 상기 값은 CREAM 로컬 호스트와 CREAM 게이트웨이간의 또다른 통신에 사용 되어야 한다.
로컬 서브넷 리스트 : 어드레스 변환없이도 도달 가능한 로컬 서브넷을 정의한다. 일례 정의에 대하여 상기를 참고한다.
REGISTRAION_CONFIRM 메세지를 사용하여 CREAM 게이트웨이는 CREAM 로컬 호스트의 REGISTRAION_REQUEST를 인식한다. 그 메세지 내에서 로컬 호스트 ID는 CREAM 게이트웨이 및 CREAM 로컬 호스트간의 또다른 통신에 사용되도록 할당된다.
또한, 그 메세지 내에서 로컬 서브넷들 리스트는 정의된다. CREAM 로컬 호스트는 대역내/대역외 액세스 요청이 통신에 행해지는 지의 여부를 결정하는데 상기 리스트를 사용한다.
동작:
상기 메세지를 수신함으로써, 로컬 호스트는 CREAM 로컬 호스트를 등록 해제하고자 하는 경우에 등록 해제 요청을 전송해야 한다. 또한, 상기 메세지를 수신한 후에, 주기적 폴들은 CREAM 로컬 호스트의 수명을 점검하도록 기대될 수 있다.
EXTEND_ REGISTRAION_INDICATION
기술:
상기 메세지는 등록된 CREAM 로컬 호스트들의 수명을 폴링하는데 사용된다. 또한, 로컬 서브넷 리스트의 업데이트는 상기 메세지 내에 포함된다.
신택스:
이름 값 바이트들 수
<버젼> <Message_Type(EXTEND_REGISTRATION_INDICATION)> 길이 <나머지 길이> 0x02 <로컬 호스트 ID> {로컬 서브넷 리스트}
의미들:
버젼 : CREAM 프로토콜의 버젼을 정의한다.
메세지 타입 : 상기 메세지의 메세지 타입을 정의하고, EXTEND_REGISTRATION_INDICATION이어야 한다.
길이 : 상기 메세지의 총 나머지 길이는 수 바이트이다.
로컬 호스트 ID : 로컬 호스트 ID를 포함하며, 상기 CREAM 로컬 호스트에 이전에 할당된 로컬 호스트 ID와 동일한 값을 가져야 한다.
로컬 서브넷 리스트: 선택 파라미터. 포함된 경우 어드레스 변환을 요청하지 않는 로컬 서브넷의 새로운 리스트를 포함한다. 포함하지 않는 경우, 예전 리스트 현재 남아있다.
동작:
로컬 호스트 ID가 등록동안에 수신되는 것과 동일하고 로컬 호스트가 여전히 등록되어 있는 경우, CREAM 로컬 호스튼 EXTEND_REGISTRATION_RESPONSE 메세지와 함께 상기 메세지에 응답해야 한다.
로컬 서브넷 리스트 파라미터가 포함되는 경우 상기 새로운 리스트는 수신하는 순간에 액티브 상태가 된다. 그러나, 이미 부가된 로컬 서브넷들 내에서 호스트들과 개시된 통신은 여전히 어드레스 변환된 상태이다. 경합 상태의 존재로 인 해, CREAM 로컬 호스트가 새로운 로컬 서브넷을 인식하기 전에 로컬 호스트들에서 2개 호스트들간의 통신이 존재할 수 있다는 것에 주목해야 한다. 이 경우에, 통신은 바람직하게는 어드레스 변환 상태로 남아있다. 이것은 버클리 소켓 인터페이스의 의미를 가지는 차단을 방지하도록 행해진다.
EXTEND_REGISTRATION_RESPONSE
기술:
상기 메세지는 등록된 로컬 호스트의 수명의 성공적인 폴을 인지하는데 사용된다. 상기 메세지를 전송함으로써, CREAM 로컬 호스트는 그것이 등록되어 있음을 인지한다.
신택스:
이름 값 바이트들 수
<버젼> <Message_Type(EXTEND_REGISTRATION_RESPONSE)> 길이 <나머지 길이> 0x02 <로컬 호스트 ID>
의미들:
버젼 : CREAM 프로토콜의 버젼
메세지 타입 : 메세지 타입을 식별하며, EXTEND_REGISTRATION_RESPONSE이어야 한다.
길이 : 상기 메세지의 총 나머지 길이는 수 바이트이다.
로컬 호스트 ID : CREAM 로컬 호스트의 ID는 등록 동안에 할당된다.
동작 :
로컬 호스트는 정확한 EXTEND_REGISTRATION_INDICATION가 수신되는 경우에 EXTEND_REGISTRATION_RESPONSE를 전송해야 한다.
DE-REGISTRATION_REQUEST
기술:
상기 메세지는 CREAM게이트웨이에서 등록 해제하도록 CREAM 로컬 호스트에 의해 사용된다.
신택스:
이름 값 바이트들 수
<버젼> <Message_Type(DE_REGISTRATION_REQUEST)> 길이 <나머지 길이> 0x02 <로컬 호스트 ID>
의미들:
버젼 : CREAM 프로토콜의 버젼.
메세지 타입 : 메세지 타입을 식별하며, DE-REGISTRATION_REQUEST이어야 한다.
길이 : 상기 메세지의 총 나머지 길이는 수 바이트이다.
로컬 호스트 ID : CREAM 로컬 호스트의 ID는 등록 동안에 할당된다.
CREAM 로컬 호스트는 상기 메세지를 전송하기 위하여 등록되어야 한다. CREAM 로컬 호스트는 대응하는 DE-REGISTRATION_CONFIRM 또는 ERROR_INDICATION이 수신되기 까지 등록되어 있어야 한다.
동작:
상기 메세지는 DE-REGISTRATION_REQUEST에 의해 인지되거나 또는 거절 이유를 정의하는 ERROR_INDICATION에 의해 재사용되어야 한다.
DE-REGISTRATION_CONFIRM
기술 :
상기 메세지는 DE-REGISTRATION_REQUEST를 인식한다.
신택스:
이름 값 바이트들 수
<버젼> <Message_Type(DE_REGISTRATION_CONFIRM)> 길이 <나머지 길이> 0x02 <로컬 호스트 ID>
의미들:
버젼 : CREAM 프로토콜의 버젼.
메세지 타입 : 메세지의 타입을 식별하며, DE-REGISTRATION_CONFIRM이여야 한다.
길이 : 상기 메세지의 총 나머지 길이는 수 바이트이다.
로컬 호스트 ID : CREAM 로컬 호스트의 ID는 등록 동안에 할당된다.
상기 메세지를 수신한 후에, CREAM 로컬 호스트는 더이상 등록되지 않으며, 상기 로컬 호스트에 대한 모든 리스들은 제거되며(임의 경우에), CREAM 로컬 호스트는 DE-REGISTRATION_REQUEST를 전송하도록 제공된다.
동작;
상기 메세지가 DE-REGISTRATION_CONFIRM를 전송하지 않고도 수신되는 경우, 로컬 호스트는 ERROR_INDICATION을 전송하여야 한다.
INBOUND_ACCESS_REQUEST
기술 :
등록된 CREAM 로컬 호스트는 상기 메세지를 대역내 액세스 매핑을 요청하는데 사용한다.
신택스:
이름 값 바이트들 수
<버젼> <Message_Type(INBOUND_ACCESS_REQUEST)> 길이 <나머지 길이> 0x02 <로컬 호스트 ID> {어드레스(로컬)} {포트(로컬)}
의미들:
버젼: CREAM 프로토콜의 버젼
메세지 타입 : 메세지의 타입을 식별하고, INBOUND_ACCESS_REQUEST이어야 한다.
길이 : 상기 메세지의 나머지 길이는 수 바이트이다.
로컬 호스트 ID : CREAM 로컬 호스트의 ID는 등록 동안에 할당된다.
어드레스(로컬) : 이것은 대역내 액세스가 요청되는 로컬 네트워크 내에서 호스트의 로컬 어드레스이다. 이 파라미터는 선택적이며, 포함되지 않은 경우 CREAM 로컬 호스트의 로컬 어드레스는 CREAM 게이트웨이에 의해 가정된다. 주의: 상이한 로컬 어드레스를 명시함으로써, 로컬 호스는 또다를 로컬 호스트에 대하여 어드레스 매핑을 요청할 수 있다. CREAM 로컬 호스트는 그러나 리스 수명에 대하 여 여전히 책임이 있다.
포트(로컬) : 상기는 매핑이 요청되는 로컬 포트이다. 상기 파라미터는 선택적이다. 상기 파라미터가 포함되지 않은 경우에 한 매핑을 CREAM 게이트웨이에 의해 선택되게 된다.
대역내 포트 매핑을 요청함으로써, 호스트(로컬 어드레스에 명시된 CREAM 로컬 호스트 또는 다른 로컬 호스트)는 로컬 페이로드내의 어드레스 정보의 어드레스 변환에 책임이 있게 된다. 따라서, CREAM 로컬 호스트외에 다른 호스트들에 대한 대역내 액세스를 요청할 경우 주의를 요한다. 이러한 경우에, 페이로드에서 IP 어드레스 정보없이 NAT ALGs 또는 프로토콜들과 같은 기술들 사용이 사용되어야 한다.
대역내 액세스 요청에 대하여, CREAM 게이트웨이는 항상 1:1 매핑을 할당하며, CREAM 게이트웨이에서의 포트 x로부터 의도된 호스트에서의 포트 x로의 매핑을 의미하며, 여기서 x는 동일하다.
포트 파라미터가 포함되는 경우, CREAM 게이트웨이는 알려진 포트(예를 들면, 하이퍼텍스트 전송 프로토콜에 대해 80)로서 상기를 위협하고, 따라서 외부에서 동일 포트 개수를 할당하도록 시도한다. 상기 포트는 한 번만 할당될 수 있음에 주의한다.
동작:
INBOUND_ACCESS_REQUEST는 INBOUND_ACCESS_CONFIRM 또는 ERROR_INDICATION에 있어서 응답되어야 한다.
INBOUND_ACCESS_CONFIRM
기술 :
상기는 INBOUND_ACCESS_REQUEST에 관한 응답이다.
신택스:
이름 값 바이트들 수
<버젼> <Message_Type(INBOUND_ACCESS_CONFIRM)> 길이 <나머지 길이> 0x02 <로컬 호스트 ID> <리스 ID> <어드레스> <포트 매핑>
의미들:
버젼 : CREAM 프로토콜의 버젼
메세지 타입 : 메세지의 타입을 식별하고, INBOUND_ACCESS_CONFIRM이어야 한다.
길이 : 상기 메세지의 나머지 길이는 수 바이트이다.
로컬 호스트ID : CREAM 로컬 호스트의 ID는 등록 동안에 할당된다.
리스 ID : 상기 특정 포트 매핑 세트에 할다되는 리스 ID. 상기 ID는 다른 참조에 사용되어야 한다.
어드레스 : 외부 네트워크와의 통신에 사용되는 어드레스. 상기는 인터넷의 공개 영역내에서 유효한 어드레스이다.
포트 매핑 : 생성된 포트 매핑 세트.
포트 매핑 세트 내에서 적어오 하나의 유효 매핑이 포함되는 경우에, 리스 ID는 매핑이 더이상 요청되지 않는 경우에 상기 매핑을 자유롭게 하는데 사용되어야 한다. 유효 매핑은 성공적인 상태 코드를 이용하여 매핑으로서 정의된다. 상태 코드가 이미 이용 가능한 값 매핑을 정의하는 경우에, 상기 매핑은 CREAM이외에 또다른 방법(예를 들면, NAT ALG 또는 UPnP)을 사용하여 생성된다.
동작 :
리스 ID로 식별되는 모든 매핑 세트는 FREE_LEASE_REQUEST에 있어서 명확하게 자유롭게 된다.
INBOUND_ACCESS_CONFIRM이 그 CREAM 로컬 호스트에 의해 우선 대응하는 INBOUND_ACCESS_REQUEST를 전송하지 않고도 수신되는 경우, 대응하는 ERROR_INDICATION은 전송된다.
OUTBOUND_ACCESS_REQUEST
기술 :
등록된 CREAM 로컬 호스트는 대역외 액세스 포트 매핑을 요청하는데 상기 메세지를 사용한다.
신택스 :
이름 값 바이트들 수
<버젼> <Message_Type(OUTBOUND_ACCESS_REQUEST)> 길이 <나머지 길이> 0x02 <로컬 호스트 ID> {어드레스(로컬)} <포트(로컬)> {어드레스(리모트 호스트)} {포트(리모트 호스트)}
의미들:
버젼: CREAM 프로토콜의 버젼.
메세지_타입 : 메세지 타입을 식별하고, OUTBOUND_ACCESS_REQUEST이어야 한다.
메세지 길이 : 상기 메세지의 나머지 길이는 수 바이트이다.
로컬 호스트 ID : 등록동안에 CREAM 게이트웨이에 의해 할당되는 로컬 호스트 ID.
어드레스(로컬) : 선택적인 호스트 매핑의 로컬 어드레스에 대하여 매핑이 요청된다. 상기 파라미터가 포함되지 않는 경우, 매핑이 그 요청 CREAM 로컬 호스트에 대하여 생성된다.
포트(로컬) : 매핑이 요청되는 로컬 포트 수 세트가 요청된다.
어드레스(리모트 호스트) : 선택적인 리모트 호스트의 어드레스. 상기 파라미터가 포함되는 경우, 매핑된 포트 세트의 통신은 제공된 어드레스에 있어서만 실행될 수 있다.
포트(리모트 호스트) : 통신이 제한되는 선택적인 리모트 포트 수 세트. 상기 파라미터가 포함되는 경우에 통신은 정의된 포트 수에 제한된다.
동작 :
리모트 어드레스(IP 어드레스 또는 FQDN)가 명시되는 경우, 통신은 리모트 어드레스만을 가지는 리모트 호스트와 통신하도록 제한된다.
리모트 포트(포트들의 A 세트)가 명시되는 경우(예를 들면, {80,8080}), 명시된 세트 내에서 리모트 호스트들의 포트들에 통신하도록 제한된다. 리모트 어드 레스 및 리모트 포트의 결합을 사용함으로써, 제한은 포트들 및 특정 리모트 호스트 범위에 대하여 통신이 가능하다.
OUTBOUND_ACCESS_CONFIRM
기술 :
상기는 OUTBOUND_ACCESS_REQUEST에 관한 응답이다.
신택스 :
이름 값 바이트들 수
<버젼> <Message_Type(OUTBOUND_ACCESS_CONFIRM)> 길이 <나머지 길이> 0x02 <로컬 호스트 ID> <리스 ID> <어드레스> <포트 매핑>
의미들:
버젼 : CREAM 프로토콜의 버젼
메세지 타입 : 메세지의 타입을 식별하고, OUTBOUND_ACCESS_CONFIRM이어야 한다.
길이 : 상기 메세지의 나머지 길이는 수 바이트이다.
로컬 호스트 ID : 등록 동안에 할당되는 CREAM 로컬 호스트의 ID.
리스 ID : 상기 특정 포트 매핑 세트에 할당되는 리스 ID는 상기 ID는 또다른 참조를 위해 사용되어야 한다.
어드레스 : 외부 네트워크와의 통신에 사용되는 어드레스. 상기는 인터넷의 공개 영역 내에서 유효한 어드레스이다.
포트 매핑 : 생성되는 포트 매핑 세트. 동작
리스 ID로 식별되는 모든 포트 매핑 세트는 FREE_LEASE_REQUEST로 명확하게 자유롭게 되어야 한다.
OUTBOUND_ACCESS_CONFIRM이 그 CREAM 로컬 호스느에 의해 대응한 OUTBOUND_ACCESS_REQUEST를 전송하지 않고도 수신되는 경우, 대응하는 ERROR_INDICATION이 전송되어야 한다.
FREE_LEASE_REQUEST
기술:
등록된 CREAM 로컬 호스는 INBOUND ACCESS REQUEST 또는 OUTBOUND ACCESS REQUEST에 의해 생성되는 포트 매핑 세트를 자유롭게 하는데 상기 메세지를 사용하다.
신택스 :
이름 값 바이트들 수
<버젼> <Message_Type(FREE_LEASE_REQUEST)> 길이 <나머지 길이> 0x02 <로컬 호스트 ID> <리스 ID>
의미들:
버젼 : CREAM 프로토콜 버젼
메세지 타입 : 메세지의 타입을 식별하며, FREE_LEASE_REQUEST이어야 한다.
길이 : 수 바이트인 상기 메세지의 나머지 길이.
로컬 호스트 ID : 등록 동안에 할당되는 CREAM 로컬 호스트의 ID.
리스 ID : 자유롭게 되어야 하는 포트 매핑들의 상기 특정 세트에 할당되는 리싱된 ID
동작:
FREE_LEASE_REQUEST을 전송한 후에, CREAM 로컬 호스트는 송신 용도로 포트 매핑을 사용하는 것이 더이상 허용되지 않는다. 대응하는 FREE_LEASE_CONFIRM 수신 이후에, 어떠한 메세지들도 리스 ID에 관련된 경로를 이용하여 더 이상 수신되지 않을 것이 보증된다.
CREAM 게이트웨이가 등록되지 않은 CREAM 로컬 호스트로부터 FREE_LEASE_REQUEST를 수신하거나 또는 비알려진 리스 ID를 포함하는 경우에, 대응하는 ERROR_INDICATION이 전송된다.
FREE_LEASE_CONFIRM
기술 :
상기 메세지는 성공적인 FREE_LEASE_CONFIRM에 대한 응답이며 식별된 포트 매핑 세트가 자유롭게 됨을 확인한다.
신택스 :
이름 값 바이트들 수
<버젼> <Message_Type (FREE_LEASE_CONFIRM)> 길이 <나머지 길이> 0x02 <로컬 호스트 ID> <리스 ID>
의미들:
버젼 : CREAM 프로토콜 버젼
메세지 타입 : 메세지의 타입을 식별하며, FREE_LEASE_CONFIRM이어야 한다.
길이 : 수 바이트인 상기 메세지의 나머지 길이.
로컬 호스트 ID : 등록 동안에 할당되는 CREAM 로컬 호스트의 ID.
리스 ID : 자유롭게 되어야 하는 포트 매핑들 세트의 리스 ID
동작:
FREE_LEASE_CONFIRM을 수신한 후에, 관련된 포트 매핑들은 더 이상 존재하지 않는다. 따라서, 어떠한 패킷들도 식별되는 포트 매핑들에 관련되어 경로에 의해 도착하지 않는다. CREAM 로컬 호스트는 대응하는 FREE_LEASE_REQUEST를 전송하거나 또는 비알려진 로컬 호스트 또는 리스 ID를 포함하지 않고도 FREE_LEASE_CONFIRM을 수신하는 경우에, 대응하는 ERROR_INDICATION이 전송된다.
ERROR_INDICATION
기술 :
상기 메세지는 에러를 표시하고 CREAM 로컬 호스트 및 CREAM 게이트웨이에 의해 전송될 수 있다.
신택스 :
이름 값 바이트들 수
<버젼> <Message_Type ERROR_INDICATION)> 길이 <나머지 길이> 0x02 <Message_Type> Error_Response_Code <에러 응답 코드> 0x04 {로컬 호스트 ID} {Parameter_Type} <타입> 0x01
권장되는 에러 코드들의 테이블:
값 의미
0x00000000 알려지지 않은 로컬 호스트 ID
0x00000001 알려지지 않은 메시지 ID
0x00000002 알려지지 않은 파라미터 타입
0x00000003 부정확한 길이값
0x00000100 불명확한 파라미터값
0x00000101 불명확한 CREAM 버전
0x00010000 로컬 호스트가 이미 등록됨
0x00010001 로컬 호스트가 등록되지 않음
의미들:
버젼 : CREAM 프로토콜의 버젼
메세지 타입 : 메세지의 타입을 식별하며, ERROR_INDICATION이어야 한다.
길이 : 수 바이트인 상기 메세지의 나머지 길이.
메세제 타입은 에러를 야기하는 메세지 타입을 식별한다.
Error_Response_Code : 에러 응답 코드, 정의에 대해서는 상기 테이블을 참조.
로컬 호스트 ID : 등록 동안에 할당되는 선택적인 CREAM 로컬 호스트의 ID. 상기 메세지가 CREAM 게이트웨이에 의해 전송되는 경우에, 상기는 알려진 경우 동작을 야기하는 CREAM 로컬 호스트를 식별한다. 상기 메세지가 CREAM 로컬 호스트에 의해 전송되는 경우, 상기는 할당되는 경우에 로컬 호스트를 식별한다.
Parameter_Type : 에러를 야기하는 파라미터 타입을 식별.
동작 :
상기 메세지는 에러들을 표시한다.
본원에서 도시되고 기술되는 실시예들 및 변경들이 단지 상기 발명의 원리들을 기술하고 있으며 다양한 수정들이 본 발명의 범위 및 사상을 벗어나지 않는 범 위내에서 당업자에 의해 실행될 수 있다는 것을 이해하게 된다.

Claims (22)

  1. 클라이언트 요청 외부 어드레스 매핑 방법에 있어서,
    로컬 호스트로부터 공중 네트워크로의 액세스 요청을 수신하는 단계;
    상기 공중 네트워크에 액세스하는 데 사용될 공개 어드레스를 결정하는 단계;
    상기 로컬 호스트에 대응하는 로컬 어드레스를 상기 공개 어드레스에 매핑하는 단계; 및
    상기 로컬 호스트에 상기 공개 어드레스를 리턴시키는 단계를 포함하는, 클라이언트 요청 외부 어드레스 매핑 방법.
  2. 제1항에 있어서, 상기 요청되는 액세스는 상기 공중 네트워크로부터 상기 로컬 호스트로의 액세스인, 클라이언트 요청 외부 어드레스 매핑 방법.
  3. 제1항에 있어서, 상기 요청되는 액세스는 상기 로컬 호스트로부터 상기 공중 네트워크로의 액세스인, 클라이언트 요청 외부 어드레스 매핑 방법.
  4. 제1항에 있어서, 상기 공중 어드레스는 상기 공중 네트워크상의 리모트 호스트(remote host)에 대응하는 어드레스인, 클라이언트 요청 외부 어드레스 매핑 방법.
  5. 제1항에 있어서,
    하나 이상의 헤더들과 하나 이상의 페이로드 영역들을 가지는 패킷을 생성하는 단계로서, 상기 패킷은 상기 액세스에서 사용되는, 상기 패킷 생성 단계;
    하나 이상의 페이로드 영역들 중 주어진 영역에 적어도 상기 공개 어드레스를 위치시키는 단계를 더 포함하는, 클라이언트 요청 외부 어드레스 매핑 방법.
  6. 제5항에 있어서, 상기 하나 이상의 상기 헤더들과 상기 하나 이상의 페이로드 영역들 중에서 하나 이상이 암호화되는, 클라이언트 요청 외부 어드레스 매핑 방법.
  7. 제1항에 있어서, 상기 공중 네트워크는 하나 이상의 어드레스들의 세트들에 의해 정의되는, 클라이언트 요청 외부 어드레스 매핑 방법.
  8. 제7항에 있어서, 상기 하나 이상의 어드레스의 세트들은 하나 이상의 서브넷 리스트들(subnet lists)에 의해 정의되는, 클라이언트 요청 외부 어드레스 매핑 방법.
  9. 제1항에 있어서,
    상기 공개 어드레스를 결정하는 단계는 공개 포트를 결정하는 단계를 더 포 함하고;
    상기 매핑하는 단계는 상기 로컬 호스트에 상기 공개 포트를 매핑하는 단계를 더 포함하며;
    상기 공개 어드레스를 리턴시키는 단계는 상기 로컬 호스트에 상기 공개 포트를 리턴시키는 단계를 더 포함하는, 클라이언트 요청 외부 어드레스 매핑 방법.
  10. 제1항에 있어서,
    상기 공중 네트워크로의 액세스를 요청하는 단계는 상기 액세스 동안에 사용될 포트를 요청하는 단계를 더 포함하고;
    상기 매핑 단계는 상기 로컬 호스트에 상기 요청된 포트를 매핑하는 단계를 더 포함하며;
    상기 공개 어드레스를 리턴시키는 단계는 상기 로컬 호스트로 상기 요청된 포트를 리턴시키는 단계를 더 포함하는, 클라이언트 요청 외부 어드레스 매핑 방법.
  11. 제1항에 있어서, 상기 매핑하는 단계는, 상기 로컬 호스트에 대한 ID(identification)을 결정하는 단계 및 상기 로컬 호스트에 상기 식별을 리턴시키는 단계를 더 포함하는, 클라이언트 요청 외부 어드레스 매핑 방법.
  12. 제1항에 있어서, 상기 매핑 단계는 상기 로컬 호스트에 대한 로컬 서브넷 리 스트를 결정하는 단계 및 상기 로컬 호스트에 상기 로컬 서브넷 리스트를 리턴시키는 단계를 더 포함하는, 클라이언트 요청 외부 어드레스 매핑 방법.
  13. 제12항에 있어서, 상기 로컬 서브넷 리스트는 로컬 네트워크를 정의하고, 이로써 상기 공중 네트워크로부터 상기 로컬 네트워크를 식별하는, 클라이언트 요청 외부 어드레스 매핑 방법.
  14. 제1항에 있어서,
    상기 액세스는 상기 로컬 호스트로부터 상기 공중 네트워크로의 액세스이고;
    상기 액세스는 상기 로컬 어드레스 및 로컬 포트를 포함하며;
    상기 방법은:
    상기 공중 어드레스가 되도록 상기 로컬 어드레스를 수정하는 단계; 및
    필요한 경우, 공개 호스트에 대응하는 공개 포트가 되도록 상기 로컬 포트를 수정하는 단계를 더 포함하는, 클라이언트 요청 외부 어드레스 매핑 방법.
  15. 제1항에 있어서,
    상기 액세스는 상기 공중 네트워크로부터 상기 로컬 호스트로의 액세스이고;
    상기 액세스는 제2 공개 어드레스 및 공개 포트를 포함하며;
    상기 방법은:
    상기 로컬 어드레스가 되도록 상기 제2 공개 어드레스를 수정하는 단계; 및
    필요한 경우, 상기 로컬 호스트에 대응하는 로컬 포트가 되도록 상기 공개 포트를 수정하는 단계를 더 포함하는, 클라이언트 요청 외부 어드레스 매핑 방법.
  16. 클라이언트 요청 외부 어드레스 매핑을 위한 시스템에 있어서,
    메모리; 및
    상기 메모리에 연결되는 적어도 하나의 프로세서를 포함하고, 상기 프로세서는:
    로컬 호스트로부터 공중 네트워크로의 액세스 요청을 수신하고;
    상기 공중 네트워크로의 상기 액세스에 사용될 공개 어드레스를 결정하며;
    상기 로컬 호스트에 대응하는 로컬 어드레스를 상기 공개 어드레스에 매핑하고;
    상기 로컬 호스트에 상기 공개 어드레스를 리턴시키도록 동작하는, 클라이언트 요청 외부 어드레스 매핑 시스템.
  17. 클라이언트 요청 외부 어드레스 매핑 방법에 있어서,
    대역외 액세스(outbound access)가 로컬 네트워크 또는 공중 네트워크로의 액세스 인지를 결정하는 단계; 및
    상기 대역외 액세스가 공중 네트워크로의 액세스일 경우,
    상기 공중 네트워크로 액세스를 요청하는 단계;
    상기 요청에 응답하여 공개 정보를 수신하는 단계; 및
    상기 대역외 액세스 동안에 생성된 하나 이상의 패킷들의 하나 이상의 페이로드 부분들에 상기 공개 정보를 위치시키는 단계를 수행하는 단계를 포함하는, 클라이언트 요청 외부 어드레스 매핑 방법.
  18. 제17항에 있어서, 상기 공개 정보는 공개 어드레스를 포함하는, 클라이언트 요청 외부 어드레스 매핑 방법.
  19. 제17항에 있어서, 상기 공개 정보는 공개 포트를 포함하는, 클라이언트 요청 외부 어드레스 매핑 방법.
  20. 제17항에 있어서, 상기 공중 네트워크로 액세스를 요청하는 상기 단계는, 로컬 포트를 요청하는 단계를 더 포함하며, 상기 페이로드에 상기 공개 정보를 위치시키는 상기 단계는 상기 페이로드에 상기 요청된 로컬 포트를 위치시키는 단계를 더 포함하는, 클라이언트 요청 외부 어드레스 매핑 방법.
  21. 제17항에 있어서, 상기 공중 네트워크로 상기 대역외 액세스를 수행하는 단계를 더 포함하며, 상기 대역외 액세스는: 파일 전송 프로토콜(file transfer protocol; FTP) 코멘트 요청(request for comment; RFC) 959; H.323 국제 원거리통신 연합(international telecommunications union; ITU) 표준; 세션 개시 프로토콜(session initiation protocol; SIP) RFC(2543); 리소스 예약 프로토콜(resource reservation protocol; RSIP) RFC 2205; 인터넷 프로토콜 캡슐 보안 프로토콜(internet protocol encapsulation security protocol; IPsec-ESP) RFC 2402; 커버로스(kerberos) 4 ; 커버로스 5; 텔레넷 RFC 854; 및 알로그인(rlogin) RFC 1282 중 하나 이상을 사용하는, 클라이언트 요청 외부 어드레스 매핑 방법.
  22. 제17항에 있어서, 애플리케이션은 결정하는 단계, 요청하는 단계, 수신하는 단계, 배치하는 단계를 수행하며, 상기 애플리케이션은 피어-투-피어 애플리케이션; 어드레스 매핑의 보유를 필요로 하는 애플리케이션; 리모트 셀(remote shell; RSH) 애플리케이션; X 윈도 시스템 애플리케이션; X-텀 애플리케이션(X-term application) 중 하나 이상인, 클라이언트 요청 외부 어드레스 매핑 방법.
KR1020067006250A 2003-09-30 2004-09-27 클라이언트 요청 외부 어드레스 매핑 KR20060093704A (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US50728603P 2003-09-30 2003-09-30
US60/507,286 2003-09-30

Publications (1)

Publication Number Publication Date
KR20060093704A true KR20060093704A (ko) 2006-08-25

Family

ID=34393229

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020067006250A KR20060093704A (ko) 2003-09-30 2004-09-27 클라이언트 요청 외부 어드레스 매핑

Country Status (6)

Country Link
US (1) US20070058642A1 (ko)
EP (1) EP1671469A1 (ko)
JP (1) JP2007507962A (ko)
KR (1) KR20060093704A (ko)
CN (1) CN1860768A (ko)
WO (1) WO2005032106A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101428138B1 (ko) * 2007-12-18 2014-08-07 알까뗄 루슨트 통신 방법 및 디바이스

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7535878B2 (en) 2003-03-28 2009-05-19 Intel Corporation Method, apparatus and system for ensuring reliable access to a roaming mobile node
US7580396B2 (en) 2003-11-05 2009-08-25 Intel Corporation Method, apparatus and system for obtaining and retaining a mobile node home address
US20050111380A1 (en) * 2003-11-25 2005-05-26 Farid Adrangi Method, apparatus and system for mobile nodes to dynamically discover configuration information
US20050113109A1 (en) * 2003-11-25 2005-05-26 Farid Adrangi Method, apparatus and system for context-based registrations based on intelligent location detection
US20050111454A1 (en) * 2003-11-25 2005-05-26 Narjala Ranjit S. Method, apparatus and system for intelligently and dynamically routing mobile internet protocol packets
US20050136924A1 (en) * 2003-12-04 2005-06-23 Farid Adrangi Method, apparatus and system for enabling roaming mobile nodes to utilize private home IP addresses
US7782902B2 (en) * 2004-07-14 2010-08-24 Audiocodes, Inc. Apparatus and method for mapping overlapping internet protocol addresses in layer two tunneling protocols
US7483393B2 (en) * 2004-12-07 2009-01-27 Cisco Technology, Inc. Method and apparatus for discovering internet addresses
JP4898168B2 (ja) * 2005-03-18 2012-03-14 キヤノン株式会社 通信システム、通信装置、通信方法、及びプログラム
US8705550B2 (en) * 2005-08-08 2014-04-22 Qualcomm Incorporated Device interface architecture and protocol
US8381297B2 (en) 2005-12-13 2013-02-19 Yoggie Security Systems Ltd. System and method for providing network security to mobile devices
US8869270B2 (en) 2008-03-26 2014-10-21 Cupp Computing As System and method for implementing content and network security inside a chip
US20080276302A1 (en) 2005-12-13 2008-11-06 Yoggie Security Systems Ltd. System and Method for Providing Data and Device Security Between External and Host Devices
US8331263B2 (en) * 2006-01-23 2012-12-11 Microsoft Corporation Discovery of network nodes and routable addresses
US8365272B2 (en) 2007-05-30 2013-01-29 Yoggie Security Systems Ltd. System and method for providing network and computer firewall protection with dynamic address isolation to a device
US8458338B2 (en) * 2007-06-15 2013-06-04 Nec Corporation Address translation device and address translation method
JP5207270B2 (ja) * 2007-07-12 2013-06-12 Ｎｅｃインフロンティア株式会社 複数のネットワーク間の通信システム
US8631488B2 (en) 2008-08-04 2014-01-14 Cupp Computing As Systems and methods for providing security services during power management mode
US20110209000A1 (en) * 2008-10-07 2011-08-25 Telefonaktiebolaget L M Ericsson (Publ) Systems and Methods for Allocating Network Resources From One Address Realm to Clients in a Different Address Realm
US8789202B2 (en) 2008-11-19 2014-07-22 Cupp Computing As Systems and methods for providing real time access monitoring of a removable media device
US8750112B2 (en) * 2009-03-16 2014-06-10 Echostar Technologies L.L.C. Method and node for employing network connections over a connectionless transport layer protocol
KR20130018708A (ko) * 2010-03-05 2013-02-25 브래스 몽키, 인크. 웹 브라우저에서의 양방향 통신 및 컨텐츠의 제어를 하기 위한 시스템 및 방법
US8902743B2 (en) * 2010-06-28 2014-12-02 Microsoft Corporation Distributed and scalable network address translation
EP2907043B1 (en) 2012-10-09 2018-09-12 Cupp Computing As Transaction security systems and methods
US11157976B2 (en) 2013-07-08 2021-10-26 Cupp Computing As Systems and methods for providing digital content marketplace security
WO2015123611A2 (en) 2014-02-13 2015-08-20 Cupp Computing As Systems and methods for providing network security using a secure digital device
US10594829B2 (en) * 2017-05-24 2020-03-17 At&T Intellectual Property I, L.P. Cloud workload proxy as link-local service configured to access a service proxy gateway via a link-local IP address to communicate with an external target service via a private network
CN110365560B (zh) * 2019-07-15 2021-09-24 上海市共进通信技术有限公司 家庭网关中实现服务端口自适应的控制方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6618757B1 (en) * 2000-05-17 2003-09-09 Nortel Networks Limited System and method for dynamic IP address management
US6944167B1 (en) * 2000-10-24 2005-09-13 Sprint Communications Company L.P. Method and apparatus for dynamic allocation of private address space based upon domain name service queries
US7139841B1 (en) * 2002-07-24 2006-11-21 Cisco Technology, Inc. Method and apparatus for handling embedded address in data sent through multiple network address translation (NAT) devices
DE60202863T2 (de) * 2002-08-30 2005-06-30 Errikos Pitsos Verfahren, Gateway und System zur Datenübertragung zwischen einer Netzwerkvorrichtung in einem öffentlichen Netzwerk und einer Netzwerkvorrichtung in einem privaten Netzwerk
KR100886550B1 (ko) * 2002-09-17 2009-03-02 삼성전자주식회사 아이피 어드레스 할당 장치 및 방법
JP2004186814A (ja) * 2002-11-29 2004-07-02 Fujitsu Ltd 共通鍵暗号化通信システム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101428138B1 (ko) * 2007-12-18 2014-08-07 알까뗄 루슨트 통신 방법 및 디바이스

Also Published As

Publication number Publication date
WO2005032106A1 (en) 2005-04-07
CN1860768A (zh) 2006-11-08
US20070058642A1 (en) 2007-03-15
EP1671469A1 (en) 2006-06-21
JP2007507962A (ja) 2007-03-29

Similar Documents

Publication Publication Date Title
KR20060093704A (ko) 클라이언트 요청 외부 어드레스 매핑
Cheshire et al. Nat port mapping protocol (nat-pmp)
US8451797B2 (en) Method and system for mobility across heterogeneous address spaces
US7908651B2 (en) Method of network communication
EP2360879B1 (en) Data package forwarding method, system and device
US7657642B2 (en) IP network node and middleware for establishing connectivity to both the IPv4 and IPv6 networks
US8457014B2 (en) Method for configuring control tunnel and direct tunnel in IPv4 network-based IPv6 service providing system
US8078735B2 (en) Information processing system, tunnel communication device, tunnel communication method, and program
US6996621B1 (en) Method for supporting secondary address delivery on remote access servers
US9705844B2 (en) Address management in a connectivity platform
US20090138611A1 (en) System And Method For Connection Of Hosts Behind NATs
US20090182858A1 (en) Method for assigning address to the intelligent information household appliance and the sub-equipment in the household network
US8194683B2 (en) Teredo connectivity between clients behind symmetric NATs
JP5520928B2 (ja) ネットワークにおけるデータパケットのルーティング方法および関連デバイス
US20140372499A1 (en) Methods and Systems for Enabling NAT Traversal
US9509659B2 (en) Connectivity platform
US7693091B2 (en) Teredo connectivity between clients behind symmetric NATs
WO2008069504A1 (en) Method for configuring control tunnel and direct tunnel in ipv4 network-based ipv6 service providing system
Cheshire et al. RFC 6886: Nat port mapping protocol (NAT-PMP)
US20140351453A1 (en) Node in a Network
US20140379785A1 (en) Server Communication
KR20030057095A (ko) 게이트키퍼와 ｎａｔ－ｐｔ 연동을 위한 서로 상이한ｉｐ 주소 연동 방법
WO2004100499A1 (en) A communication network, a network element and communication protocol and method of address auto-configuration therefor
Simons-Nikolova et al. PF 41-packet forwarding for seamless use of IPv6 devices behind IPv4-only NAT gateways
Madhavan NAT TRAVERSAL THROUGH TUNNELING

Legal Events

Date Code Title Description
WITN Application deemed withdrawn, e.g. because no request for examination was filed or no examination fee was paid