Dec 31, 2008

Intra-Cluster Communication Signaling (ICCS)

Intra-Cluster Communication Signaling (ICCS), which provides the communications with the Cisco CallManager Service process that is at the heart of the call processing in each server or node within the cluster.

The intra-cluster traffic between the servers consists of the following:
  • Database traffic from the IBM Informix Dynamic Server (IDS) database that provides the main configuration information. The IDS database is replicated from the publisher server to all other servers in the cluster using best-effort. The IDS traffic may be re-prioritized in line with Cisco QoS recommendations to a higher priority data service (for example, IP Precedence 1 if required by the particular business needs). An example of this is extensive use of Extension Mobility, which relies on IDS database configuration.

  • Firewall management traffic, which is used to authenticate the subscribers to the publisher to access the publisher's database. The management traffic flows between all servers in a cluster. The management traffic may be prioritized in line with Cisco QoS recommendations to a higher priority data service (for example, IP Precedence 1 if required by the particular business needs).

  • ICCS real-time traffic, which consists of signaling, call admission control, and other information regarding calls as they are initiated and completed. ICCS uses a Transmission Control Protocol (TCP) connection between all servers that have the Cisco CallManager Service enabled. The connections are a full mesh between these servers. Because only eight servers may have the Cisco CallManager Service enabled in a cluster, there may be up to seven connections on each server. This traffic is priority ICCS traffic and is marked dependant on release and service parameter configuration.

  • CTI Manager real-time traffic is used for CTI devices involved in calls or for controlling or monitoring other third-party devices on the Unified CM servers. This traffic is marked as priority ICCS traffic and exists between the Unified CM server with the CTI Manager and the Unified CM server with the CTI device.

Shared Line Appearance(SLA) vs Bridged Line Appearance(BLA)

  • Shared Line Appearances:
    SLAs allow you to place a call on hold at one set and pick it up easily at another set. SLA is also known as SCA: Shared Call Appearance. You can join an existing conversation be pressing the corresponding line button. Typically the phones will have dedicated buttons with LEDs for each of the shared lines.

  • Bridged Line Appearance:
    BLA allows multiple devices to share a single directory number.

Facebook使用人數持續擴增(活躍使用者帳戶已達到1.4億個)

自從我接觸了Facebook之後,我就把Plaxo, Linkist, LinkedIn等社群網站冷落了,因為我觀察出來我的朋友對於Facebook接受程度遠大於其他社群網站,我認為其中有一個很大的原因,那就是Facebook的localize程度相當完整,完整到讓人以為Facebook是來自於local language的網站。以我周遭的朋友為例,我以往利用plaxo來維持人際關係,希望可以利用plaxo來隨時追蹤朋友的聯繫資料(與outlook 聯絡人同步),但是通常發出的邀請大約只有2/5會有回應,大約只有不到1/10的人會真的註冊到plaxo上。很多人跟我說他們看到英文信就砍了根本連內容都沒看...(沒錯,這是部份台灣人或是部份非西方語系國家的悲哀,他們拒絕接受英文相關資訊,因為有的人是看不懂有的人是懶得去翻譯)。

反觀Facebook,它不但中文化程度相當完整(唯一的缺點,雖然都是繁體中文,但是香港中文用語跟台灣中文用語有所差異…有時真的有看沒有懂,甚至不知道怎麼唸),它有著其他社群網站不同的特色,內建IM(這可以取代MSN/Yahoo Messenger)及web online game(有愈來愈多人從web online game找到朋友,而不用再去買online game軟體、買點數、安裝軟體等),讓許多人之間透過另一個朋友漸漸地認識到另外一群人或是N群人,只是因為某人在Facebook上發文或是進行其他的動作,造成了更多人的互動,這是以往IM及其他社群網站所沒有作到的(不過也有一些類似的社群網站出現,像是plurk or twitter,可惜他們不如Facebook收容這麼豐富的應用(也可以import許多其他社群資訊,甚至是提供無限量的照片上傳空間,因此Facebook社群會造成一種吸引力,讓你用了Facebook 之後就離不開它)。

不過Facebook也有缺點,那就是主頁介面過於複雜不容易上手,尤其是對於年紀稍長的35歲以上的網路使用者,很容易因為不知該如何使用Facebook或是來自太多方面的訊息flooding而放棄Facebook。但是相對地對於出生於網際網路世代的年輕人來說,Facebook是一個很方便的工具,隨時可以接收到各方的訊息,因為他們自小就已習慣數位訊息接收,所以相對地很容易接受新科技玩意,這也是Facebook上的年紀層遠低於LinkedIn平均年齡的原因。

=================================================================

ZDNet新聞專區:Caroline McCarthy
2008/12/19 14:07:02 

社群網站Facebook仍像野火燎原般快速擴張,據稱活躍使用者帳戶已達到1.4億個。

「Inside Facebook」部落客Justin Smith指出,拿來跟Facebook會員數達到1.3億人的日期相比,可估算出Facebook的使用者人數必定以每天增加六、七十萬人的速度持續遞增。

今年稍早,Facebook估計該公司的網路平均每天增加25萬名使用者。 

統計公司如Nielsen、ComScore和Compete.com等,都發現Facebook的美國使用者人數大概介於4,700萬與5,000萬之間--仍比MySpace的6,000多萬美國訪客來得少。不過,現在 Facebook的成長大致來自美國境外,國際使用者人數增加才是推升Facebook會員數目扶搖直上的主力。

但Facebook的營收能不能跟上這麼高速的成長?

特別是在海外,伺服器效能所費不貲。Facebook已募集可觀的創業資本,據說還在募資中,自稱財務狀況良好。然而,這令人質疑,Facebook擴張的速度是不是超出自己的意料之外。
(唐慧文/譯)

Wireless AP SSID Cloaking

Remember in Star Trek when the Enterprise was "cloaked" but somehow the Klingons found the ship anyway? Well there is a way to "cloak" your wireless network.

Your SOHO wireless device should have a setting called "Closed Network" or "Broadcast SSID". By either enabling a closed network or disabling the broadcast SSID feature you can hide or cloak your network. The SSID (network name) is transmitted in the air by your device in a broadcast called a "Beacon". Also, many wireless cards client utilities transmit empty "Probe Requests" looking for your device.

There is a very popular and freely available software program called Network Stumbler that is used by individuals to discover wireless networks. Network Stumbler also sends out blank Probe Requests looking for wireless access points.

When you implement a closed network, the SSID is no longer in the BEACON and your wireless gateway will not respond to blank Probe Requests. Effectively, your wireless network is temporarily invisible.

It should be noted that more professional tools can still discover your network because there are other transmissions from your home device that will eventually expose your SSID.

Cloaking is a great way to hide your network, but any experienced hacker will still find the SSID.

IEEE 802.11b 封包的種類

1. Beacon 封包
一般的無線 AP, 都會不斷的傳輸 Beacon 封包, Beacon 封包內會包含
SSID 訊息, 支援的傳輸速率, 此無線 AP 的 MAC 位址.
一般的 Beacon 封包速率是在 6~10 Beacon packets/sec.

為了安全性, 現在無線 AP 也提供了不包含 SSID 值的 Beacon 功能,
這種 SSID cloaking 的立意在於: 用戶端除非事先知道所使用 SSID,
否則無法使用這個無線 AP. 但是聰明的讀者一定想到了, 等到有用戶
要連接時, 就算有 WEP, 還是可以聽到所使用的 SSID :)
(ref: dedicated sniffing)

*另外也可以利用強波干擾 802.11b 的 2.4GHz 頻率(請參考 FCC
規範),當干擾強到無線 AP 或無線網卡需要重新 re-join, 此時就
可以主動聽到 SSID;這種方法造成的斷線情形,對用戶而言也可當
作是可能被探測的警訊 :)


2. Probe response 封包
當用戶端想要連上網路時,他會依據收到的 Beacon 封包,送出 probe
response 封包,其中會包含: 所要加入網域的 SSID、所使用的傳輸
速率。

3. Data 封包
通常是封裝在 802.11b frames 中的 TCP/IP 封包

4. Ad hoc 封包
和 Data 封包相同, 但屬於網卡對網卡傳輸不需繞經無線 AP.

BSSID: mac address of the BSS
SSID: 辨示該 BSS 的 32 bytes 字串
DATA RATE: 包括 1Mbps 2Mbps 5.5Mbps 11Mbps
HR/DSSS: High Rate Direct Sequence Spread Spectrum

Dec 30, 2008

威邁思延攬周勝鄰 明年第二季開台

威邁思延攬周勝鄰 明年第二季開台

WiMAX北區業者威邁思,延攬前工研院資通所副所長周勝鄰為技術長,瞄準明年第一季要完成200個基地台的建設,以期在明年第二季開台,目前測試中的USB有友訊、華碩、三星與中興,同時明基與技嘉的手持式裝置(MID)也列為下波測試的產品。

威邁思的技術長彭集友離職後,初期網路建置是重頭戲,因此公司延攬周勝鄰為技術長,周勝鄰擅長於寬頻網路與網路電話,之前曾在東元集團擔任顧問,頗獲肯定,此次則是投入WiMAX 的領域,為威邁思籌建網路,威邁思的股東有東元、東訊、威寶與英特爾。

威邁思已經決定設備採購商,將由韓國三星與以色列奧維通兩家業者,拿下基地台等設備採購商機,三星已經完成簽約,奧維通還在洽談細節,三星之前已經為威寶建設基地台,已有合作基礎,奧維通則是之前曾下單東訊,更加深合作關係。這兩家業者都有和東訊簽訂WiMAX無線基地台製造合作意向書。三星也是Sprint-Nextel、日本UQ等業者的設備商。

威邁思初期將建設台北市200座基地台,由於北市既有3.5G網路覆蓋率完整,也促使威邁思必須強化網路建設,才能一別苗頭。

在終端設備上,目前測試中的USB有友訊、華碩、大陸的中興與三星,下一波也將導入MID產品,例如明基與技嘉。

目前取得WiMAX執照的業者紛紛延後開台時程,遠傳開台日期延後到明年底前,威邁思計畫在明年第二季,威達延到明年6月開台,全球一動在明年第三季開台,業者評估,WiMAX終端設備至今互通性仍有問題,價錢又太貴,再加上政府對於通訊監察的規範遲未出爐,讓WiMAX開台時程受到阻礙。

Dec 29, 2008

為什麼Traceroute時沒有發生packet lost但是總會出現 * 呢?

說實話,關於這個問題我自己也常常覺得很納悶,剛好最近PacketLife.net(我真的愈來愈喜歡這個網站了,只要上過我課程的學生應該不陌生,給各位同學的cheatsheet都是從PacketLife上抓下來的)把這個issue提出來並且作了一份packet analyze報告,請參考!

Traceroute timeouts

Posted by stretch in Networking on Monday, 29 Dec 2008 at 2:26 a.m. GMT

If you spend a lot of time performing traceroutes to Cisco routers you've probably noticed that they usually end like this:


R1# traceroute 10.0.34.4
Type escape sequence to abort.
Tracing the route to 10.0.34.4
1 10.0.12.2 16 msec 8 msec 12 msec
2 10.0.23.3 16 msec 16 msec 16 msec
3 10.0.34.4 16 msec * 20 msec

Notice that the second reply from the last hop has timed out. This is easily repeated with subsequent traceroutes, and it is always the second attempt which times out. Strange, eh?

The reason for this is IOS' default ICMP rate limiting. Back in May I wrote an article explaining the common "U.U.U" response that results from pinging an unreachable destination, and the same logic is at work here. Inspecting the default ICMP rate limits reveals that ICMP unreachable messages are only sent every 500ms:


R4# show ip icmp rate-limit
DF bit unreachables All other nreachables
Interval (millisecond) 500 500

Interface # DF bit unreachables # All other unreachables
--------- --------------------- ------------------------
FastEthernet0/1 0 3

Greatest number of unreachables on FastEthernet0/1

This rate limiting configuration effectively ignores every other traceroute packet (see the timeline illustration in the previous article). Makes sense, but why do all the requests to routers prior to the last hop receive replies without this problem?

Those replies are of a different ICMP type, namely the "TTL exceeded" type. Remember that traceroute works by sequentially incrementing the TTL of UDP (or ICMP on Windows) packets destined for a host and recording the replies received from intermediate routers. All hops except the last one will (or should) return a "TTL exceeded in transit" message, whereas the last hop should return a "destination unreachable/port unreachable" message indicating that it cannot handle the received traffic (UDP traceroute packets are typically addressed to a pseudorandom high port on which the end host is not likely to be listening).

Traceroute flow

The packet capture attached at the end of this article includes the traffic from the traceroute demonstrated above.

Interestingly, we can remove the ICMP rate limit with no ip icmp rate-limit:


R4(config)# no ip icmp rate-limit unreachable
R4(config)# ^Z
R4# show ip icmp rate-limit

Now our traceroute from R1 completes fully:
R1# traceroute 10.0.34.4
Type escape sequence to abort.
Tracing the route to 10.0.34.4
1 10.0.12.2 32 msec 12 msec 20 msec
2 10.0.23.3 60 msec 56 msec 24 msec
3 10.0.34.4 32 msec 44 msec 36 msec

However, removing the ICMP rate-limit may open an avenue for denial of service attacks on your routers, so in practice you probably want to leave it applied.

安全傳輸協定(Security Transport Protocols, SRTP)

安全傳輸協定(Security Transport Protocols)除了可應用在金融交易資料外,亦可應用於網路瀏覽所涉及之相關機密資料。在數位多媒體內容保護技術中,目前有數種安全協定可供使用在資料流(Data Traffic)的保護上,如作用在網路層(Network Level)的IP保護安全協議標準(Internet Protocol Security, IPSec);作用在傳送層(Transport Level)的安全傳輸層(Transport Layer Security)安全協定(Security Protocols)。但上述安全協定不一定適用各種型態的資料流。為了滿足異質環境(Heterogeneous Environment)及即時應用(Real-time Applications)上之需求,應用層(Application Level)上的安全協定運作更是當務之急。

數位多媒體在傳送的需求大致如上所述,但能應用一般資料安全傳送協定的媒體種類有限,如靜態圖檔或一般媒體檔案利用HTTP方式下載。但是對於如使用RTSP傳送協定的即時串流媒體而言,這些現有的資料安全傳送協定不見得適用。因為即時串流媒體對頻寬(Bandwidth)限制、傳送錯誤敏感性(Transmission-error Sensitivity)、延遲(Delay)與行動終端的運算複雜度等問題,皆異常敏感且容忍性低。也是即時串流媒體在是目前異質環境與即時應用上面對的四個主要問題。

目前關於上述問題的相關IP解決方案,均非針對異質性環境的需求所設計,尤其較少關注到頻寬的消耗與訊號傳遞的來回次數問題。這問題在無線3G網路上會更突顯,因為無線網路的資源有限且頻寬稀有,若使用目前標準IP上的安全協定,可能增加系統營運成本外,還可能無法達到預期的效果。換句話說,以標準IP傳送方式來傳送語音資料(Audio data),在一個典型的即時傳輸協定(Realtime Transport Protocol, RTP)語音費用負載約為33位元組的情況下,在頻寬使用上是缺乏效率的。

SRTP高彈性擴充解決適用性問題

SRTP的設計架構保留彈性的擴充功能以延長協定可使用的壽命,因此SRTP一開始設計時並非定位為單一產品,其乃以基礎建設骨架(Framework)的方式進行設計。所以在SRTP架構中可以獨立分開實作編碼部分與整合性保護部分,因為在SRTP中並未編碼保護RTP,因此對RTP標頭進行壓縮運作以保留頻寬。另外,在SRTP預定義轉換(Predefined Transforms)中亦提供加密套件,以因應不同異質性環境或即時應用的需求,藉此改善加密套件之間的互通(Interoperability)。

SRTP定義兩種編碼轉換(Encryption Transforms),一是H. Lipmaa、D. Wagner與P. Rogaway所提議的Counter模式;另一為f8模式。這兩種編碼轉換是基於AES的串流加密器(Stream Ciphers)之區塊式編碼器,避免位元錯誤而波及其他傳送位元。而其預定義的驗證轉換(Authentication Transforms)為HMAC/SHA-1,這兩種驗證方法是經過多重考驗的成熟雜湊架構(Hash-based)函數。

但對於群播(Multicast)用戶而言,其屬性與僅傳送單一用戶者不同。若在群播裡提供原始資料驗證,將花費高成本,目前此方面有效的驗證方法尚未健全。所以SRTP在群組(Groups)應用上,並未提供原始資料驗證的功能選項。群播問題屬較複雜的管理環節,若資料串流又加上編碼或驗證等工作,無疑加重既有系統的負擔。因為每個安全協定都需要「密鑰管理協定(Key Management Protocol, KMP)」以確保未來密鑰交換的安全及規範成員間的安全參數(Security Parameters),不同的媒體遞送方式,其使用的KMP技術可能存在彼此適用問題。

在群播的管理安全問題上,核心環繞在群組鑰匙管理的機制面。造成該問題複雜化的因素,在於群組內的會員變動率大且架構傾向浮動所致。因此群播(Multicast)中的群組鑰匙管理問題,是目前DRM系統或是媒體本身編碼、驗證機制所共同面對的難題。

在一群播基礎架構裡,每一個遞送資料的通訊區段(Session)安全主要由兩個元件所控制,一個是鑰匙伺服器(Key Server, KS),另一為群組控制者(Group Controller, GC)」。KS負責維護、散播群組所需要編碼/驗證的密鑰;GC則負責群播會員的驗證、認證與存取控制。KS與GC的功能可實作在同一台實體裝置,亦可分開實作。

在群播腳本裡,為確保群播通訊區段的機密性,傳送者(Source)會與合法會員分享一對稱式密鑰(Symmetric Key),此對稱式加密系統的密鑰便是流量編碼鑰匙(Traffic Encryption Key, TEK),此鑰匙可解開編碼後的群播流量資訊。因此,傳送者會先用TEK將訊息編碼後才進行機密傳送。

因群播會員具有較大流動性,為確保離開的會員不得再觀看機密訊息,KS會重新產生一個新的TEK並遞送給現存會員,往後的機密訊息就以新TEK進行編碼與解碼,此過程即所謂「重發鑰匙(Re-keying)」過程。整個群組密鑰的重新更新與編碼管理過程,稱為「群組密鑰管理(Group Key Management, GKM)」。群組密鑰的管理會隨著會員的增加而趨於複雜,換句話說,會員越大,群組的密鑰更新成本隨之增高。

一個有效的群組密鑰管理需求可分成四大主要類別,分別是鑰匙伺服器需求、安全需求、服務品質(Quality of Service, QoS)需求及群組成員需求。每一個類別下另各有其次要需求,依據Y. Challal及H. Seba看法,這些次要需求可歸納如表1。

對群組鑰匙管理協定(Group Key Management Protocol, GKMP)的描述,在目前常用的集中化、去集中化與分散式三種不同的群組鑰匙管理技術中,哪一個群組鑰匙管理協定才適用?事實上並無一定標準,不過可參考Y. Challal及H. Seba所提的四項需求中,何者能滿足最多次需求者即是。
為使SRTP更加完備,其KMP須滿足SRTP所支援的各種應用需求。但在許多即時應用(Real-time Applications)裡面易存在延遲問題,尤其在無線應用環境裡面,因其環境運算資源(Computational Resources)有限,一旦這些安全協定技術被應用進去,不管協定多有效率,都將會額外耗損端點運算資源或網路頻寬等系統資源,因此若要在無線應用環境裡面運用,其程式大小與運算成本須獲得適當控制。

在系統與端點(End Points)的密鑰常見的協調方式有兩種,一種是以用戶端對用戶端(P2P)的協調方式;另一種是利用KMP方式來發送密鑰及安全參數。前者提供點對點式的便利,但其缺點在設定與運作上會較複雜;後者提供較一致的整體安全控制,不過缺點則是整個系統的運作成本會比前者高。適用哪一種密鑰協調方式,端視應用種類、目的與商業價值而定。因此一個安全協定,意味著高運算資源的消耗,在發展SRTP時,高通透量(High Throughput)與異質環境的滿足是其主要設計核心原則。不過在設計STP的同時,也要設計安全實時控制協定(Secure Real-Time Control Protocol, SRTCP),RTCP為RTP的控制協定,在設計SRTCP時其所遵循的標準亦比照SRTP的設計標準進行。

基於上述限制,難以將已發展成熟的一般IP安全協定直接套用在無線終端設備,如要在這些行動裝置上面執行公鑰編碼鑰匙(Public Key)運算,將犧牲龐大運算成本,因此在多數情況下對加密系統的選用上,「對稱式編碼(Symmetric Encryption)」方法仍是首選。

串流加密器簡化錯誤位元處理

欲將加密系統用在無線環境,另需注意位元錯誤發生的問題。在某些應用型態,如音訊裡面,錯誤可合理被處理。但若該訊息是被驗證的,即使是一個位元的錯誤也會導致整個封包的丟棄,這對接受端來說,將導致整體感官品質(Perceived Quality)下降。不過即使訊息未經驗證要求,在密碼系統層級上,尤其在加密層面(Decryption Phase)也可能出現位元錯誤問題。因此,接受端的傳播錯誤控制(Propagate Errors Control)是一關鍵的控制技術。

至於一個訊息的錯誤傳播與錯誤位元的發生位置,須看當時所選擇的解碼器種類而定,基於上述理由,串流加密器(Stream Cipher)或許是即時串流應用中較佳選擇,因為這種串流加密器不會像DES和AES區塊加密器一樣,以整批的方式處理傳播錯誤的問題。一個區塊式加密系統與串流式加密系統的運作示意圖如圖2。

SRTP設計優先考量頻寬

因為封包加密/驗證的需求,往往會無形之中增加頻寬的消耗,因此在SRTP的設計理念裡面,頻寬的保留(Bandwidth Preservation)是主要的核心任務之。而頻寬保留的常見作法,通常是使用「封包序號(Package Sequence Number, Packet SN)」來同步化安全演算法(Security Algorithms)。RTP的序號通常位於封包的標頭位置,當系統陸續送出封包時,序號會以單調遞增的方式,如同排隊抽號碼牌的情形一般。陸續增加號碼。SRTP使用的是RTP原有的序號,因此它在同步化(Synchronization)上面並不需要其他額外的欄位。不過遺憾的是RTP序號只有16位元大小,因此當此大小容量被填滿時,RTP序號就會被迫重新計算,如此一來,SRTP所使用的密鑰也要重新加以改變。對應重新計數的SN之密鑰,或許就須要重新執行一次密鑰管理協定(Key Management Protocol, KMP),這過程就是所謂的「重發行密鑰(Re-keying)」。

在SRTP的基本架構內,一般情況下並不會於RTP封包內加入任何額外的位元,不過在「重發行密鑰」時,除了整合保護所需要的驗證標籤(Authentication Tag)外,還需要一個「主密鑰識別器(Master Key Identifier, MKI)」加入RTP封包,不過此欄位是一選擇性的可變長度欄位(Variable Length Field)。為了頻寬保留,封包的驗證標籤會被切為四位元組大,此作法雖會犧牲一些安全性,但在即時應用上可被接受。

SRTP與實際的密鑰管理協定(KMP)兩者互為獨立運作, SRTP為提供足夠安全功能,其所需要的密鑰數目須依據其所提供的安全功能數目而定。另外,SRTP亦使用主要密鑰(Master Key)與通訊區段密鑰(Session Key)的觀念,由密鑰管理系統負責交換主要密鑰,但通訊區段密鑰則衍生自主要密鑰,亦為實際用於編碼或驗證的密鑰。

為保持SRTP的安全強度,SRTP提供「密鑰更新(Key Refresh)」功能。若此選項一旦啟動,會依據主要密鑰定期產生新的通訊區段密鑰,因為新的通訊區段密鑰乃依據原有主要密鑰而產生,所以啟動此功能並不造成密鑰管理系統的負擔增加。所以一個主要密鑰可能為多個SRTP串流所共享,其並儲存在多媒體通訊區段內以降低密鑰交換數目。

為達共享的目的,應注意避免重複使用密鑰串流。避免重複使用密鑰串流,SRTP提供不同且唯一的起始向量(Initialization Vector, IV)到每一個串流加密器,若無法提供不同且唯一的起始向量至不同加密器,就應使用不同的主要密鑰。另外一種關於有限RTP序號的解決方法,是直接利用RTP的序號來重發行密鑰,但這種方法欠缺前者具備的彈性。此外,執行重發行密鑰過程時會大量消耗系統資源,因此避免一個長時間的通訊區段不斷發出重發行密鑰的要求,所以SRTP在局部使用了一個三十二位元的紀錄器,稱為「反覆計數器(Rollover Counter)」,用以加大原本RTP序號使用的序號數量空間。

商業周刊:傳統即時通訊軟件的沒落

《商業周刊》網站日前發表分析文章稱,傳統即時通訊(以下簡稱『IM』)正在走向沒落。曾經在電腦桌面上風光無限的IM視窗正在讓位於一種使用更方便的即時聊天工具,互聯網公司希望借這種工具提高網站的粘性。

  微軟11月13日宣布將更緊密地集成IM、Windows Live電子郵件和社交網站,就是這一趨勢的一個例証。在使用Hotmail時,用戶無需打開一個新視窗,下載客戶端軟件,就可以與其他用戶即時聊天了。

  微軟是根據消費者需求的變化採取這一舉措的:用戶對獨立IM工具的興趣在日益減退,希望喜歡的站點集成有聊天功能。與電子郵件、遊戲和其他類型軟件一樣,IM也在向Web靠攏,用戶可以在任何電腦上使用網頁IM,而又不會占用硬盤空間。

  嵌入式IM

  據美國市場研究公司comScore稱,截至2008年9月份的一年中,AOL旗下AIM軟件獨立訪問用戶數量下滑了4%。同期內AOL旗下另外一款IM軟件ICQ和騰訊QQ的用戶使用時間也出現了滑坡。

  互聯網用戶對傳統IM聊天視窗已經失去了興趣,紛紛『湧向』Facebook和Gmail等站點,這些站點的一個共同特徵是都集成有IM功能。對於互聯網公司而言,嵌入式IM增加了用戶訪問站點的時間,對廣告客戶也更有吸引力。

  AOL People Networks高級副總裁大衛‧劉(David Liu)表示,大多數20歲以上網民最早使用的是AOL的IM軟件,但其他IM軟件削弱了AOL旗下IM軟件的競爭力,『AIM的用戶數量在下滑,因此我們需要增強AIM的社交特性。』AOL的舉措之一是將AIM與該公司旗下社交網站Bebo結合起來。AOL計劃2009年初在Bebo上發布一款IM面板,賣點就是AIM的3000萬用戶可以方便地訪問好友的Bebo網頁。

  Facebook聊天工具條

  Facebook也考慮到了IM。Facebook今年早些時候發布了一款工具條,用戶在瀏覽Facebook時可與其他用戶進行一對一的聊天。據Facebook產品經理彼得‧鄧(Peter Deng)表示,約7500萬人試用了這款工具條,相當於逾60%的Facebook活躍用戶。鄧說,『我們認為讓用戶進行一對一的聊天是非常必要的,這為朋友之間保持聯繫提供了一種渠道。』

  一些小型社交網站也意識到了聊天的吸引力。電影粉絲社交網站Flixster CEO喬‧格林斯坦(Joe Greenstein)今年早些時候指出,用戶更喜歡彼此之間uH即時方式討論和推薦電影,而不是先發帖子然後再等待其他用戶跟帖。Flixster 10月份發布了一款網頁IM工具條,用戶可以查看哪些好友在線,並與他們進行一對一的聊天。

  嵌入式廣告

  Flixster的工具條是由硅谷創業公司Meebo開發的。Meebo計劃未來6個月內為19個其他網站開發類似的網頁IM工具條。Meebo CEO塞斯‧斯特恩伯格(Seth Sternberg)表示,網頁IM提高了網站粘性,『如果用戶原來在一個網站上停留3分鐘,我們就能夠讓用戶停留6分鐘。』

  Flixster和Meebo的其他合作伙伴最終將在IM工具條,甚至用戶聊天過程中嵌入廣告。斯特恩伯格說,這將是在IM中發布廣告的一個新機遇。例如,用戶可以在聊天視窗中觀看電影預告片的同時與好友討論正在觀看的預告片。

  交互式營銷機構Deep Focus媒體副總裁埃里克‧唐肯米勒(Eric Druckenmiller)表示,互聯網公司需要給IM注入新的活力了。他說,與IM相比,許多其他網路廣告發布渠道規模就相形見絀了,但自1990年代末以來,IM沒有受到足夠的重視。Deep Focus在Meebo的IM站點上進行的一項試驗表明,IM的廣告潛力很大。

  谷歌和雅虎在網頁IM領域已經走在了微軟前邊。在過去的兩年來,為了將自己打造為一站式網路通訊站點,谷歌和雅虎在網站上集成了IM工具,目的是提高內容和服務的粘性。

  雅虎在IM廣告領域的大膽探索

  谷歌在Google Talk桌面軟件、Gmail Chat、Google Docs和widget中提供了聊天功能。Google Talk產品經理塞斯‧德姆賽(Seth Demsey)說,『我們希望用戶能夠在需要的地方與其他用戶聊天。』

  雅虎的獨立IM軟件擁有1.16億名用戶,遠遠超過了Google Talk的600萬。雅虎在通過IM發布廣告方面進行了大膽的探索,例如展示廣告、關聯廣告,甚至在IM視窗中集成了一款迷你可口可樂足球遊戲。

  有業界人士預測,IM用戶越來越希望拆除各種平台間的圍牆,在一個地方看到自己的所有好友,這個地方可能是工具條、電子郵件服務或者是桌面軟件。(清泉)

Dec 27, 2008

Check Point宣佈收購Nokia資訊安全設備業務

2008.12.26 下午 12:55:12

Check Point軟體技術有限公司宣佈,與Nokia簽署協議收購其資訊安全設備(security appliance)部門。Check Point與Nokia已合作長達十年之久,並共同致力研發領導產業的企業安全解決方案。透過此次收購,Check Point將可增強其在資安硬體設備的支援和發展,擴大其在全球資安市場的版圖。

Check Point軟體技術有限公司首席執行長Gil Shwed表示,Nokia的資訊安全設備部門一直是Check Point重要的策略合作夥伴,更曾協助Check Point早一步成為安全設備的領導者。把Nokia深受市場肯定的資訊安全設備,整合到Check Point的強大安全解決方案中,是雙方長期合作下來必然的結果。

Check Point與Nokia長期提供客戶在關鍵環境中,擁有最高效能的資安解決方案。Nokia的資訊安全設備,為Check Point的防火牆、虛擬私人網路(VPN)和統一威脅管理系統(UTM),提供最有效的安全平台。目前財星雜誌500大企業中已有85%購買Nokia安全設備,超過220,000個Nokia安全設備,被全球逾23,000個客戶安裝使用。

而Check Point擁有多樣的安全閘道解決方案,如Check Point UTM-1 appliances和Check Point Power-1 appliances等,能夠帶給小型公司及大型企業完整的資料保護。目前,已有超過700,000個Check Point安全閘道授權給全球逾100,000個企業使用,Check Point客戶群包含100%的財星雜誌前100大企業,及98%的財星雜誌500大企業。

Check Point與Nokia的收購案,預計2009年第一季完成所有交易程序;詳細交易資料將不對外公開。

Check Point台灣區總經理簡淑真表示,Check Point期盼透過此次收購案,除拓展全球的資安市場外,Check Point也將繼續在台提供企業客戶與合作夥伴們優質的服務,及安全設備產品。

Dec 25, 2008

QoS Bandwidth/Priority Remaining Percent 保留頻寬計算

很多人在學習QoS LLQ & CBWFQ的時候,遇到了頻寬保留分配問題都會有一些不太確定的感覺,因為Cisco在課程中並沒有非常詳細的說明不同的指令參數之間的搭配,會得到什麼樣的後果,所以我把這個問題在這邊提出來(這要感謝課堂上的同學問我這個問題,也順便釐清了這個不確定因素)。

假設我們現在在P1R1上有一路Serial頻寬為512k,現在我們要進行頻寬分配,分配的條件如下:

  • Class TEST1使用LLQ(10%)
  • Class TEST2使用CBWFQ剩下可用頻寬的(30%)
  • Class TEST3使用CBWFQ剩下可用頻寬的(20%)

這個問題看似簡單,但是如果從來沒有認真去注意到的話就可以會有不同的解讀,到底TEST3可以使用多少的保留頻寬?

正確答案是:

  • Class TEST1 LLQ使用頻寬上限=512k * 10%=51.2k
  • Class TEST2 CBWFQ保留頻寬 = [(512k * 75%預設最大可分配的頻寬) - 51.2k] * 30%
  • Class TEST3 CBWFQ保留頻寬 = [(512k * 75%預設最大可分配的頻寬) - 51.2k] * 20%

也就是說最後所有使用bandwidth percent remaining指令的總和不得超過100%

還有一點很重要的是,在這邊所謂的remaining並非指interface上現在實際流量的剩餘頻寬,Cisco QoS的指令在MQC中沒有這麼厲害可以隨時去監控現行使用流量來進行等比例的動態保留(maybe in the future)

為了證明真的是這個樣子,我進行了以下的實驗:

P1R1(config)#policy-map TEST
P1R1(config-pmap)#class TEST1
P1R1(config-pmap-c)#priority percent 10
P1R1(config-pmap-c)#class TEST2
P1R1(config-pmap-c)#bandwidth remaining percent 30
P1R1(config-pmap-c)#class TEST3
P1R1(config-pmap-c)#bandwidth remaining percent 80
Sum total of class bandwidths exceeds 100 percent

結果Cisco Router回應了以上的訊息,這表示bandwidth remaining percent指令是一視同仁,大家共同使用扣除之前並非使用remaining參數進行保留頻寬動作之後的可用頻寬再來均分;而不是每一行的bandwidth remaining percent都要把之前所有已保留頻寬動作都扣除之後再來計算比例。

附上一張Cisco Slide希望各位可以看得更清楚!


Dec 24, 2008

Management Plane Protection(MPP)

The Management Plane Protection (MPP) feature in Cisco IOS software provides the capability to restrict the interfaces on which network management packets are allowed to enter a device. The MPP feature allows a network operator to designate one or more router interfaces as management interfaces. Device management traffic is permitted to enter a device only through these management interfaces. After MPP is enabled, no interfaces except designated management interfaces will accept network management traffic destined to the device.

Restricting management packets to designated interfaces provides greater control over management of a device, providing more security for that device. Other benefits include improved performance for data packets on nonmanagement interfaces, support for network scalability, need for fewer access control lists (ACLs) to restrict access to a device, and management packet floods on switching and routing interfaces are prevented from reaching the CPU.

In-Band Management Interface

An in-band management interface is a Cisco IOS physical or logical interface that processes management as well as data-forwarding packets. Loopback interfaces commonly are used as the primary port for network management packets. External applications communicating with a networking device direct network management requests to the loopback port. An in-band management interface is also called a shared management interface.

Control Plane Protection Overview

A control plane is a collection of processes that run at the process level on a route processor and collectively provide high-level control for most Cisco IOS software functions. All traffic directly or indirectly destined to a router is handled by the control plane.

Control Plane Policing (CoPP) is a Cisco IOS control-plane feature that offers rate limiting of all control-plane traffic. CoPP allows you to configure a quality of service (QoS) filter that manages the traffic flow of control plane packets. This QoS filter helps to protect the control plane of Cisco IOS routers and switches against denial-of-service (DoS) attacks and helps to maintain packet forwarding and protocol states during an attack or during heavy traffic loads.

Control Plane Protection is a framework that encompasses all policing and protection features in the control plane. The Control Plane Protection feature extends the policing functionality of the CoPP feature by allowing finer policing granularity. Control Plane Protection also includes a traffic classifier, which intercepts control-plane traffic and classifies it in control-plane categories. Management Plane Protection operates within the Control Plane Protection infrastructure.

Management Plane

The management plane is the logical path of all traffic related to the management of a routing platform. One of three planes in a communication architecture that is structured in layers and planes, the management plane performs management functions for a network and coordinates functions among all the planes (management, control, data). The management plane also is used to manage a device through its connection to the network.

Examples of protocols processed in the management plane are Simple Network Management Protocol (SNMP), Telnet, HTTP, Secure HTTP (HTTPS), and SSH. These management protocols are used for monitoring and for CLI access. Restricting access to devices to internal sources (trusted networks) is critical.

Management Plane Protection Feature

The MPP feature in Cisco IOS software provides the capability to restrict the interfaces on which network management packets are allowed to enter a device. The MPP feature allows a network operator to designate one or more router interfaces as management interfaces. Device management traffic is permitted to enter a device through these management interfaces. After MPP is enabled, no interfaces except designated management interfaces will accept network management traffic destined to the device. Restricting management packets to designated interfaces provides greater control over management of a device.

The MPP feature is disabled by default. When you enable the feature, you must designate one or more interfaces as management interfaces and configure the management protocols that will be allowed on those interfaces. The feature does not provide a default management interface. Using a single CLI command, you can configure, modify, or delete a management interface.When you configure a management interface, no interfaces except that management interface will accept network management packets destined to the device. When the last configured interface is deleted, the feature turns itself off.

Following are the management protocols that the MPP feature supports. These management protocols are also the only protocols affected when MPP is enabled.

  • Blocks Extensible Exchange Protocol (BEEP)
  • FTP
  • HTTP
  • HTTPS
  • SSH, v1 and v2
  • SNMP, all versions
  • Telnet
  • TFTP

Cisco IOS features enabled on management interfaces remain available when the MPP feature is enabled. Nonmanagement packets such as routing and Address Resolution Protocol (ARP) messages for in-band management interfaces are not affected.

This feature generates a syslog for the following events:

  • When the feature is enabled or disabled
  • When a management interface fails.

For example, a failure will occur when the management interface cannot successfully receive or process packets destined for the control plane for reasons other than resource exhaustion.

Benefits of the Management Plane Protection Feature

Implementing the MPP feature provides the following benefits:

  • Greater access control for managing a device than allowing management protocols on all interfaces
  • Improved performance for data packets on nonmanagement interfaces
  • Support for network scalability
  • Simplifies the task of using per-interface ACLs to restrict management access to the device
  • Fewer ACLs needed to restrict access to the device
  • Management packet floods on switching and routing interfaces are prevented from reaching the CPU

Configuring a Device for Management Plane Protection

Perform this task to configure a device that you have just added to your network or a device already operating in your network. This task shows how to configure MPP where SSH and SNMP are allowed to access the router only through the FastEthernet 0/0 interface.

Prerequisites

  • IP Cisco Express Forwarding must be enabled before a management interface can be configured.

SUMMARY STEPS

1. enable

2. configure terminal

3. control-plane host

4. management-interface interface allow protocols

5. Ctrl-z

6. show management-interface [interface | protocol protocol-name

Examples

The configuration in this example shows MPP configured to allow SSH and SNMP to access the router only through the FastEthernet 0/0 interface. This configuration results in all protocols in the remaining subset of supported management protocols to be dropped on all interfaces unless explicitly permitted. BEEP, FTP, HTTP, HTTPS, Telnet, and TFTP will not be permitted to access the router through any interfaces, including FastEthernet 0/0. Additionally, SNMP and SSH will be dropped on all interfaces except FastEthernet 0/0, where it is explicitly allowed.

To allow other supported management protocols to access the router, you must explicitly allow these protocols by adding them to the protocol list for the FastEthernet 0/0 interface or enabling additional management interfaces and protocols.

Router# configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z. 
Router(config)# control-plane host 
Router(config-cp-host)# management-interface FastEthernet 0/0 allow ssh snmp 
Router(config-cp-host)# 
.Aug  2 15:25:32.846: %CP-5-FEATURE: Management-Interface feature enabled on Control plane  host path 
Router(config-cp-host)# 

The following is output from the show management-interface command issued after configuring MPP in the previous example. The show management-interface command is useful for verifying your configuration.

Router# show management-interface 

Management interface FastEthernet0/0 
        Protocol        Packets processed 
             ssh                0 
            snmp                0 

Router# 

Configuration Examples for Management Plane Protection

This section provides the following configuration example:

Configuring Management Plane Protection on Gigabit Ethernet Interfaces: Example

The following example shows how to configure MPP where only SSH, SNMP, and HTTP are allowed to access the router through the Gigabit Ethernet 0/3 interface and only HTTP is allowed to access the router through the Gigabit Ethernet 0/2 interface.

Router# configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z. 
Router(config)# control-plane host 
Router(config-cp-host)# management-interface GigabitEthernet 0/3 allow http ssh snmp        
Router(config-cp-host)# 
.Aug  2 17:00:24.511: %CP-5-FEATURE: Management-Interface feature enabled on Control plane  host path 
Router(config-cp-host)# management-interface GigabitEthernet 0/2 allow http 
Router(config-cp-host)# 

The following is output from the show management-interface command issued after configuring MPP in the previous example. The show management-interface command is useful for verifying your configuration.

Router# show management-interface  
Management interface GigabitEthernet0/2 
        Protocol        Packets processed 
            http                0 

Management interface GigabitEthernet0/3 
        Protocol        Packets processed 
            http                0 
             ssh                0 
            snmp                0 

The Steps of QoS Preclassification Configuration with IPSec and GRE

The qos pre-classify mechanism allows Cisco routers to make a copy of the inner IP header and to run a QoS classification before encryption based on fields in the inner IP header. Without this feature, the classification engine sees only a single encrypted and tunneled flow since all packets that traverse across the same tunnel have the same tunnel header and receive the same treatment in the event of congestion.

If your classification policy matches with the ToS byte, you do not need to use the qos pre-classify command since the ToS value is copied to the outer header by default. You can create a simple QoS policy which sorts traffic into classes based on IP precedence. However, to differentiate traffic within a class and to separate it into multiple flow-based queues, the qos pre-classify command is required.

Note: ToS byte copying is done by the tunneling mechanism and not by the qos pre-classify command.

The qos pre-classify command can be applied at various points in your configuration, as illustrated here.

  • GRE only - Configure the qos pre-classify command on the tunnel interface.

    interface Tunnel0   ip address 1.1.1.1 255.255.255.252   qos pre-classify   tunnel source 12.2.2.8   tunnel destination 12.2.2.6 ! interface serial 0/0   ip address 12.2.2.8 255.255.255.0   fair-queue
  • IPSec only - Configure the qos pre-classify command under the crypto map.

    crypto map TEST 10 ipsec-isakmp   set peer 5.5.5.5   set transform-set SET   match address Test   qos pre-classify ! interface serial 0/0   ip address 5.5.5.4 255.255.255.0   crypto map TEST   random-detect   random-detect flow
  • IPSec and GRE - Configure the qos pre-classify command on the tunnel interface and under the crypto map.

    crypto map TEST 10 ipsec-isakmp   set peer 12.2.2.6   set transform-set SET   match address Test   qos pre-classify ! interface Tunnel0   ip address 1.1.1.1 255.255.255.252   qos pre-classify   tunnel source 12.2.2.8   tunnel destination 12.2.2.6   crypto map TEST ! interface serial 0/0   ip address 12.2.2.8 255.255.255.0   service-policy out matchPORTnumbers   crypto map TEST

Complete these steps to configure QoS preclassification with IPSec and GRE.

  1. Configure a crypto map and specify the qos pre-classify command in map configuration mode.

    crypto map cryptomap_gre1 10 ipsec-isakmp  set peer 172.32.241.9  set transform-set transf_GRE1_transport  match address 130  qos pre-classify
  2. Use the show crypto map command to confirm your configuration.

    2621vpn1#show crypto map Crypto Map: "cryptomap_gre1" idb: Loopback0 local address: 172.31.247.1 Crypto Map "cryptomap_gre1" 10 ipsec-isakmp         Description: Crypto map on GRE1 tunnel mode transport - 10.240.252.0->3/30         Peer = 172.32.241.9         Extended IP access list 130             access-list 130 permit gre host 172.31.247.1 host 172.32.241.9         Current peer: 172.32.241.9         Security association lifetime: 4608000 kilobytes/3600 seconds         PFS (Y/N): N         Transform sets={ transf_GRE1_transport, }         QOS pre-classification
  3. Define a GRE tunnel interface and apply the crypto map and qos pre-classify commands.

    interface Tunnel0 ip address 10.240.252.1 255.255.255.252 qos pre-classify tunnel source Loopback0 tunnel destination 172.32.241.9 crypto map cryptomap_gre1
  4. Use the show interface tunnel 0 command to confirm that QoS preclassification is enabled.

    2621vpn1#show interface tunnel 0 Tunnel0 is up, line protocol is up   Hardware is Tunnel   Description: VPN resilience test - 1st GRE tunnel Interface mode transport - 10.240.252.0->3/3   Internet address is 10.240.252.1/30   Tunnel source 172.31.247.1 (Loopback0), destination 172.32.241.9   Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled   Checksumming of packets disabled,  fast tunneling enabled   Last input 00:00:04, output 00:00:04, output hang never   Last clearing of "show interface" counters 00:00:51   Queueing strategy: fifo (QOS pre-classification)   Output queue 0/0, 0 drops; input queue 0/75, 0 drops

The above output illustrates that the tunnel interface continues to use first in, first out (FIFO) as the queuing strategy even with QoS preclassification and fancy queuing enabled. This is illustrated in the show command output with the line Queueing strategy: fifo (QOS pre-classification). Both GRE and IPSec tunnels require FIFO queuing since a destination device drops IPSec packets that arrive out of order.

In a VPN environment, you can apply a QoS service policy to the tunnel interface or to the underlying physical interface. The decision of whether you need to configure the qos pre-classify command depends on which header and which header values you want to use for classification.

  • If you want to classify packets based on the inner header, apply the policy to the tunnel interface without the qos pre-classify command.

  • If you want to classify packets based on the outer header, apply the policy to the physical interface without the qos pre-classify command.

  • If you want to classify packets based on the inner header and apply the policy to the physical interface since the physical interface may be a congestion point, apply the policy to a physical interface and enable the qos pre-classify command.

Dec 19, 2008

「給我快!其餘免談!」 20M光纖上網服務98年登場

記者林睿康/台北報導

為了在明年能擴大光世代使用戶數量達180萬戶,中華電信除了推出10M光纖服務促銷方案外,中華電信數據通信分公司協理劉伴和今(19)天表示,明年第一季或第二季,中華電信將推出20M的光纖上網服務,以滿足需要高速飆網快感的消費者。

劉伴和說明,目前中華電信提供的光纖服務分為3M、10M、50M和100M四種。50M和100M以企業用戶為主要訴求對象,月租費從1700元起跳,至於3M的光纖服務,因速度和售價都與ADSL服務太貼近,較難吸引用戶採用,因此目前光世代用戶中,有九成以上都是採用10M的光纖服務。 劉伴和表示,因有消費者反應,10M的速度還不夠快,所以為了能讓9成以上的10M用戶能體驗更飆網的快感,中華電信預計在明年第一季或第二季,向國家傳播委員會提出申請審核通過後,就會推出20M的光纖上網服務。

劉伴和說,只要從中華電信交換機房拉出光纖網路,或者由路邊交接箱拉進大樓裡,現有的10M用戶都能夠提出申請,輕鬆升級為20M。 至於20M/2M收費多少,劉伴和表示,目前資費還沒確定,不過依照目前光纖10M/2M每月990元及50M每月1700元來看,20M/2M收費將介於兩者之間。

光纖上網是中華電信在2006年6月宣佈力推的網路建設,價格攻勢讓中華電信的網路市場上告捷,根據資策會公布的資料,台灣的光纖用戶數從2007年20萬戶快速增加到55萬戶,2008年更逼近100萬戶,也讓中華電信期望在2009年突破180萬戶。而根據光纖協會所發表針對全球各國光纖滲透率調查結果,台灣因光纖普及率逐年增加,已從去年第5名進步到第4名。

Dec 16, 2008

【好書推薦】軟技巧,還是硬道理? — 你會感謝有人告訴你的職場生存術

工作了十幾年,看到許多同事來來去去,不同的職場人際關係導致截然不同的工作際遇,所以其實在共同工作的環境下,擁有基本的實力是應該的,但是了解人與人之間的交際溝通卻遠比實力更加地的重要,除非你離開這個大社會獨自一人生活,否則這本書是每個人在現在社會上打拼時都應該要先學習的"通識教育"!

曾經有人告訴我:"他"因為怕被別人罵"笨"而不敢問一些笨問題;也曾經有人告訴過我,"他"一切行事要求低調,不論事情好壞…,其實在這本書中都有很明白的述論,這些問題背後可能會引發其他人對這類行為處事的看法,甚至會影響到個人工作發展,所以一言一行都應該適時適度,而非一眛盲從所謂的"謙虛美德"、"沈默是金"這類我們自小耳濡目染的良好品德。因為時代在變社會在變人心也在變,美國總統都變黑人了,台灣總統都被羈押了,還有什麼事情不可能發生,唯有要求自己隨著時代變化而變化,才有辦法繼續生存下去!


【內容簡介】

最頂尖光鮮的律師、醫師、工程師、教授、新聞記者,以及成功主管都說,職場上應該要學會但也最難學的就是──軟技巧。

為什麼沒有人早點告訴我?
◆在職場上有熱情、天分和領悟力,成功的大門就會為你而開?
錯!沒認清自己,你不可能會心甘情願花八~十個小時做一份工作。

◆待在同一家公司的年資很久是你的優勢?
錯!現在企業徵人只要看到有人在同一個地方待十年,心裡就會開始狂拉警報。

◆怕主管和同事嫌我笨,所以不要問比較好?
錯!問蠢問題讓人嫌笨還算事小,沒搞清楚自己在說什麼或做什麼就悶著頭做,才真的是蠢到了極點。

◆在職場上,我只想當好人?
錯!你不用當每一個人最好的朋友,那是上帝派給狗的任務。

◆達到一點業績就到處宣傳,誰在乎啊?
錯!老闆很在乎。學會老王賣瓜的藝術才能將你的成就深深印在老闆心中。

◆我的技能與專才受到大家的肯定,我當主管應該沒有問題?
錯!就算你有當管理者的天賦,管理的技巧還是需要「一分天才加上九十九分的努力」。

談到軟技巧,多半人想到的是熱情而立場模糊的人。沒錯,做人技巧的確不可或缺,但那只是開場白而已。所謂硬邦邦的基本功,是指工作時所需要擁有的技術及認知能力,然而軟技巧則可以讓人更有效率地運用技術及知識。這些技巧包含了個人的、社交的、人際間的,以及自我管理的行為,而這些行為所含括的能力及特色範圍很大:要有自知之明、要值得信賴、要認真負責、要可以通融、要能提綱挈領、要有看法、要主動進取、要有同情心、要有自信心、要正直、要能自制、要有組織概念、要討人喜歡、要有影響力、要可承受風險、要可解決問題、要有領導才能、要能作好時間管理等等。一大堆對吧?這些所謂的軟技巧與基本功搭配起來相得益彰,在亂成一團的工作環境中,這是成功的必要項目。你可以找來全世界的專家,但如果你不能把點子推銷出去,不能跟別人好好相處,或是及時交付任務,你肯定是會被綁手綁腳、跨不出門的。
本書教我們如何在職場上以一些實用的方法與技巧來運用軟技巧,像是:
● 別擋在自己的路上
● 學會工作堅持與放手的時機
● 問蠢問題時,放聰明點
● 面對搶你功勞的人
● 搞清楚辦公室檯面下的遊戲規則
● 領軍作戰

所以,請你繼續讀下去,你才會發現這些軟技巧帶給你的效益,幾乎可以全面涵蓋一切,讓你百尺竿頭,更上一步。而這個,也就是所謂的硬道理。
在紛亂的工作環境中要突破重圍,請把佩姬‧克勞絲教給財星五百大企業執行長一定要學的軟技巧聽進去,下次碰到前途不明、原地打轉或失去方向時,別再重複一些人過去常問的問題:「為什麼沒有人告訴我……?」因為這本書已經把硬道理告訴你了!

Dec 12, 2008

Received Signal Strength Indication(RSSI)

In telecommunications, Received Signal Strength Indication (RSSI) is a measurement of the power present in a received radio signal.

RSSI is generic radio receiver technology metric, which is usually invisible to the user of device containing the receiver, but is directly known to users of wireless networking of IEEE 802.11 protocol family.

RSSI is often done in the intermediate frequency (IF) stage before the IF amplifier. In zero-IF systems, it is done in the baseband signal chain, before the baseband amplifier. RSSI output is often a DC analog level. It can also be sampled by an internal ADC and the resulting codes available directly or via peripheral or internal processor bus.

RSSI in 802.11 implementations
In an IEEE 802.11 system RSSI is the received signal strength in a wireless environment, in arbitrary units. RSSI can be used internally in a wireless networking card to determine when the amount of radio energy in the channel is below a certain threshold at which point the network card is clear to send (CTS). Once the card is clear to send, a packet of information can be sent. The end-user will likely observe an RSSI value when measuring the signal strength of a wireless network through the use of a wireless network monitoring tool like Network Stumbler or Inssider (for Windows Vista).

RSSI measurements will vary from 0 to a maximum of 255 depending on the vendor. It consists of a one-byte integer value. A value of 1 will indicate the minimum signal strength detectable by the wireless card, while 0 indicates no signal. The value has a maximum of RSSI_Max. For example, Cisco Systems cards will return an RSSI of 0 to 100. In this case, the RSSI_Max is 100. The Cisco card can report 101 distinct power levels. Another popular Wi-Fi chipset is made by Atheros. An Atheros based card will return an RSSI value of 0 to 127 and a value of 0x80 indicates an invalid number

The subtlety of 802.11 RSSI comes from how it's sampled; RSSI is acquired during the preamble stage of receiving an 802.11 frame. To this extent 802.11 RSSI has (for the most part) been replaced with RCPI; a functional measurement covering the entire received frame with defined absolute levels of accuracy and resolution.

RSSI is stored on TX/RX descriptor and was measured by baseband and PHY for each individual packet.

Simple Object Access Protocol(SOAP)

SOAP的全名為Simple Object Access Protocol(簡易物件通訊協定),是一種以XML為基礎的通訊協定,其作用是編譯網路服務所需的要求或回應後,再將編譯後的訊息送出到網路,簡單來說就是應用程式和用戶之間傳輸資料的一種機制。

SOAP的全名為Simple Object Access Protocol(簡易物件通訊協定),是一種以XML為基礎的通訊協定,其作用是編譯網路服務所需的要求或回應後,再將編譯後的訊息送出到網路,簡單來說就是應用程式和用戶之間傳輸資料的一種機制。

SOAP是一個獨立的訊息,可以獨自運作在不同的作業系統與網路上面,例如在微軟的Windows或Linux的建構下運作,並可以使用各種不同的通訊方式來作傳輸,例如SMTP、MIME,或是HTTP等。

近來W3C對於建立網路服務的協定不遺於力,尤其W3C對於SOAP的1.2版更新工作更是已經接近完工的階段。在SOAP1.2版中,包含了一個用於簡化網路的工具包,這個工具包擁有許多1.1版未有的工具,例如可讓開發者建立管理SOAP訊息規則的「處理模型」,以及包含簡易管理大量的XML文檔功能。

不過因為SOAP還未到達完成的階段,所以W3C現今只定位SOAP1.2版為「建議性的網路服務開發工具」。

SOAP的架構為:Envelope、Header、Body,和Fault四個部份;其組織架構是與XML的語法相結合應用,換句話說SOAP是由XML語法所寫而成。

SOAP不但可以在不同的網路上運作,更可以在不同的網路間作傳輸,如圖3所示,SOAP可以透過HTTP發送訊息,再透過TCP、MSMQ,最後由SMTP收到訊息,途中可以透過四個不同的傳輸點傳達訊息。由此我們可以見到SOAP的透通性與實用性,遠比一般的通訊協定更為有彈性。

Dec 11, 2008

Cipher Block Chaining Message Authentication Code Protocol (CCMP)

Counter Mode with Cipher Block Chaining Message Authentication Code Protocol (CCMP) is an encryption protocol that forms part of the 802.11i standard for wireless local area networks (WLANs), particularly those using WiMax technology. The CCMP algorithm is based on the U.S. federal government's Advanced Encryption Standard (AES).
CCMP offers enhanced security compared with similar technologies such as Temporal Key Integrity Protocol (TKIP). CCMP employs 128-bit keys and a 48-bit initialization vector that minimizes vulnerability to replay attacks. The Counter Mode component provides data privacy. The Cipher Block Chaining Message Authentication Code component provides data integrity and authentication. The enhanced privacy and security of CCMP compared with TKIP requires additional processing power, often necessitating new or upgraded hardware.

802.11i is a standard for WLANs that provides encryption for networks that use the 802.11a, 802.11b and 802.11g standards. The AES is an encryption algorithm for securing sensitive but unclassified material by government agencies. It may eventually become the de facto encryption standard for commercial transactions in the private sector.

Proactive Key Caching(PKC)

PKC is an IEEE 802.11i extension that allows for the proactive caching (before the client roaming event) of the WPA/WPA2 PMK that is derived during a client IEEE 802.1 x/EAP authentication at the AP. If a PMK (for a given WLAN client) is already present at an AP when presented by the associating client, full IEEE 802.1X/EAP authentication is not required. Instead, the WLAN client can simply use the WPA 4-way handshake process to securely derive a new session encryption key for communication with that AP.

Note PKC is an IEEE 802.11i extension and so is supported in WPA2—not WPA.

Basic Service Set(BSS)



The Basic Service Set is a term used to describe the collection of Stations which may communicate together within an 802.11 WLAN (Wireless Local Area Network).

The BSS may or may not include AP (Access Point) which provide a connection onto a fixed distribution system such as an Ethernet network. Two types of BSS exist; IBSS (Independent Basic Service Set) and Infrastructure Basic Service Set.

EAP-TTLS(Extensible Authentication Protocol-Tunneled Transport Layer Security)

EAP-Tunneled Transport Layer Security, or EAP-TTLS is an EAP protocol that extends TLS. It was co-developed by Funk Software and Certicom. It is widely supported across platforms, although there is no native OS support for this EAP protocol in Microsoft Windows, it requires the installation of small extra programs such as SecureW2.

EAP-TTLS offers very good security. The client does not need be authenticated via a CA-signed PKI certificate to the server, but only the server to the client. This greatly simplifies the setup procedure as a certificate does not need to be installed on every client.

After the server is securely authenticated to the client via its CA certificate, the server can then use the established secure connection ("tunnel") to authenticate the client. It can use an existing and widely deployed authentication protocol and infrastructure, incorporating legacy password mechanisms and authentication databases, while the secure tunnel provides protection from eavesdropping and man-in-the-middle attack. Note that the user's name is never transmitted in unencrypted cleartext, thus improving privacy.

EAP TTLS is described in RFC 5281.

EAP-MD5(Extensible Authentication Protocol-Message Digest 5)

EAP-MD5, defined in RFC 3748, is the only IETF Standards Track based EAP method. It offers minimal security; the MD5 hash function is vulnerable to dictionary attacks, and does not support key generation, which makes it unsuitable for use with dynamic WEP, or WPA/WPA2 enterprise. EAP-MD5 differs from other EAP methods in that it only provides authentication of the EAP peer to the EAP server but not mutual authentication. By not providing EAP server authentication, this EAP method is vulnerable to man-in-the-middle attacks.

EAP-SIM(Extensible Authentication Protocol-Subscriber Identity Module)

Extensible Authentication Protocol Method for GSM Subscriber Identity, or EAP-SIM, is an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the Global System for Mobile Communications (GSM) Subscriber Identity Module (SIM). EAP-SIM is described in RFC 4186.

Public Key Infrastructure(PKI)

In cryptography, a public key infrastructure (PKI) is an arrangement that binds public keys with respective user identities by means of a certificate authority (CA). The user identity must be unique for each CA. The binding is established through the registration and issuance process, which, depending on the level of assurance the binding has, may be carried out by software at a CA, or under human supervision. The PKI role that assures this binding is called the Registration Authority (RA) . For each user, the user identity, the public key, their binding, validity conditions and other attributes are made unforgeable in public key certificates issued by the CA.

The term trusted third party (TTP) may also be used for certificate authority (CA). The term PKI is sometimes erroneously used to denote public key algorithms, which do not require the use of a CA.

Protected Access Credentials(PAC)

Protected Access Credentials (PACs) are credentials that are distributed to clients for optimized network authentication. PACs can be used to establish an authentication tunnel between the client and the authentication server (the first phase of authentication as described in the "Two-Phase Tunneled Authentication" section). A PAC consists of, at most, three components: a shared secret, an opaque element, and other information.

The shared secret component contains the pre-shared key between the client and authentication server. Called the PAC-Key, this pre-shared key establishes the tunnel in the first phase of authentication.

The opaque component is provided to the client and is presented to the authentication server when the client wants to obtain access to network resources. Called the PAC-Opaque, this component is a variable length field that is sent to the authentication server during tunnel establishment. The EAP server interprets the PAC-Opaque to obtain the required information to validate the client's identity and authentication. The PAC-Opaque includes the PAC-Key and may contain the PAC's client identity.

The PAC might contain other information. Called PAC-Info, this component is a variable length field that is used to provide, at a minimum, the authority identity of the PAC issuer (the server that created the PAC). Other useful but not mandatory information, such as the PAC-Key lifetime, can also be conveyed by the PAC-issuing server to the client during PAC provisioning or refreshment.

PACs are created and issued by a PAC authority, such as Cisco Secure ACS, and are identified by an ID. A user obtains his or her own copy of a PAC from a server, and the ID links the PAC to a profile.

Persistent PACs, such as machine PACs, are stored in the EAP-FAST registry and encrypted. These PACs are also protected with access control lists (ACLs) so only designated users (the owners of the PACs) and members of privileged user groups (for example, administrators) can access them. Machine PACs are stored globally so that all users of a machine can use the PACs.

All PACs are encrypted and tied to the host machine with Microsoft Crypto API (CryptoProtectData). PACs cannot be copied and used on other machines.

All non-persistent PACs, such as User Authorization PACs, are stored in volatile memory and do not persist after reboot or after a user has logged off.

Cisco Centralized Key Management(CCKM)

CCKM is a term used in wireless networks. It stands for Cisco Centralized Key Management, which is a form of Fast Roaming. When a wireless LAN is configured for fast reconnection, a LEAP enabled client device can roam from one access point to another without involving the main server. Using Cisco (TM) Centralized Key Management (CCKM), an access point configured to provide Wireless Domain Services (WDS) takes the place of the RADIUS server and authenticates the client without perceptible delay in voice or other time-sensitive applications.

Actually, the WDS (which can be run as a service on a Cisco Access Point or on various router modules) caches the user credentials after the initial log-on. The user must authenticate with the Radius server the first time - then he can roam between access points using cached credentials. This saves time in the roaming process, especially valuable for IP Telephones.

The current implementation of CCKM requires Cisco compatible hardware and either LEAP, EAP-Fast (CCXv3) or PEAP-GTC, PEAP-MSCHAP, EAP-TLS (CCXv4).

Dec 10, 2008

Network Access Identifier(NAI) - RFC2486

RFC2486 - The Network Access Identifier

Network Working Group B. Aboba
Request for Comments: 2486 Microsoft
Category: Standards Track M. Beadles
WorldCom Advanced Networks
January 1999

The Network Access Identifier

Status of this Memo

This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (1999). All Rights Reserved.

1. Abstract

In order to enhance the interoperability of roaming and tunneling
services, it is desirable to have a standardized method for
identifying users. This document proposes syntax for the Network
Access Identifier (NAI), the userID submitted by the client during
PPP authentication. It is expected that this will be of interest for
support of roaming as well as tunneling. "Roaming capability" may be
loosely defined as the ability to use any one of multiple Internet
service providers (ISPs), while maintaining a formal, customer-vendor
relationship with only one. Examples of where roaming capabilities
might be required include ISP "confederations" and ISP-provided
corporate network access support.

2. Introduction

Considerable interest has arisen recently in a set of features that
fit within the general category of "roaming capability" for dialup
Internet users. Interested parties have included:

Regional Internet Service Providers (ISPs) operating within a
particular state or province, looking to combine their efforts
with those of other regional providers to offer dialup service
over a wider area.

National ISPs wishing to combine their operations with those of
one or more ISPs in another nation to offer more comprehensive
dialup service in a group of countries or on a continent.

Businesses desiring to offer their employees a comprehensive
package of dialup services on a global basis. Those services
may include Internet access as well as secure access to
corporate intranets via a Virtual Private Network (VPN), enabled
by tunneling protocols such as PPTP, L2F, L2TP, and IPSEC tunnel
mode.

In order to enhance the interoperability of roaming and tunneling
services, it is desirable to have a standardized method for
identifying users. This document proposes syntax for the Network
Access Identifier (NAI). Examples of implementations that use the
NAI, and descriptions of its semantics, can be found in [1].

2.1. Terminology

This document frequently uses the following terms:

Network Access Identifier
The Network Access Identifier (NAI) is the userID submitted
by the client during PPP authentication. In roaming, the
purpose of the NAI is to identify the user as well as to
assist in the routing of the authentication request.
Please note that the NAI may not necessarily be the same as
the user's e-mail address or the userID submitted in an
application layer authentication.

Network Access Server
The Network Access Server (NAS) is the device that clients
dial in order to get access to the network. In PPTP
terminology this is referred to as the PPTP Access
Concentrator (PAC), and in L2TP terminology, it is referred
to as the L2TP Access Concentrator (LAC).

Roaming Capability
Roaming capability can be loosely defined as the ability to
use any one of multiple Internet service providers (ISPs),
while maintaining a formal, customer-vendor relationship
with only one. Examples of cases where roaming capability
might be required include ISP "confederations" and ISP-
provided corporate network access support.

Tunneling Service
A tunneling service is any network service enabled by
tunneling protocols such as PPTP, L2F, L2TP, and IPSEC
tunnel mode. One example of a tunneling service is secure
access to corporate intranets via a Virtual Private Network
(VPN).

2.2. Requirements language

In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [9].

2.3. Purpose

As described in [1], there are now a number of services implementing
dialup roaming, and the number of Internet Service Providers involved
in roaming consortia is increasing rapidly.

In order to be able to offer roaming capability, one of the
requirements is to be able to identify the user's home authentication
server. For use in roaming, this function is accomplished via the
Network Access Identifier (NAI) submitted by the user to the NAS in
the initial PPP authentication. It is also expected that NASes will
use the NAI as part of the process of opening a new tunnel, in order
to determine the tunnel endpoint.

2.4. Notes for Implementors

As proposed in this document, the Network Access Identifier is of the
form user@realm. Please note that while the user portion of the NAI
conforms to the BNF described in [5], the BNF of the realm portion
allows the realm to begin with a digit, which is not permitted by the
BNF described in [4]. This change was made to reflect current
practice; although not permitted by the BNF described in [4], FQDNs
such as 3com.com are commonly used, and accepted by current software.

Please note that NAS vendors may need to modify their devices so as
to support the NAI as described in this document. Devices handling
NAIs MUST support an NAI length of at least 72 octets.

3. Formal definition of the NAI

The grammar for the NAI is given below, described in ABNF as
documented in [7]. The grammar for the username is taken from [5],
and the grammar for the realm is an updated version of [4].

nai = username / ( username "@" realm )

username = dot-string

realm = realm "." label

label = let-dig * (ldh-str)

ldh-str = *( Alpha / Digit / "-" ) let-dig

dot-string = string / ( dot-string "." string )

string = char / ( string char )

char = c / ( "\" x )

let-dig = Alpha / Digit

Alpha = %x41-5A / %x61-7A ; A-Z / a-z

Digit = %x30-39 ;0-9

c = < any one of the 128 ASCII characters, but
not any special or SP >

x = %x00-7F
; all 127 ASCII characters, no exception

SP = %x20 ; Space character

special = "<" / ">" / "(" / ")" / "[" / "]" / "\" / "."
/ "," / ";" / ":" / "@" / %x22 / Ctl

Ctl = %x00-1F / %x7F
; the control characters (ASCII codes 0 through 31
; inclusive and 127)

Examples of valid Network Access Identifiers include:

fred@3com.com
fred@foo-9.com
fred_smith@big-co.com
fred=?#$&*+-/^smith@bigco.com
fred@bigco.com
nancy@eng.bigu.edu
eng!nancy@bigu.edu
eng%nancy@bigu.edu

Examples of invalid Network Access Identifiers include:

fred@foo
fred@foo_9.com
@howard.edu
fred@bigco.com@smallco.com
eng:nancy@bigu.edu
eng;nancy@bigu.edu
@bigu.edu

4. References

[1] Aboba, B., Lu J., Alsop J., Ding J. and W. Wang, "Review of
Roaming Implementations", RFC 2194, September 1997.

[2] Rigney C., Rubens A., Simpson W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2138, April
1997.

[3] Rigney C., "RADIUS Accounting", RFC 2139, April 1997.

[4] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.

[5] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
August 1982.

[6] Gulbrandsen A. and P. Vixie, "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2052, October 1996.

[7] Crocker, D. and P. Overrell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.

[8] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.

[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

5. Security Considerations

Since an NAI reveals the home affiliation of a user, it may assist an
attacker in further probing the username space. Typically this
problem is of most concern in protocols which transmit the user name
in clear-text across the Internet, such as in RADIUS, described in
[2] and [3]. In order to prevent snooping of the user name,
protocols may use confidentiality services provided by IPSEC,
described in [8].

6. IANA Considerations

This document defines a new namespace that will need to be
administered, namely the NAI realm namespace. In order to to avoid
creating any new administrative procedures, administration of the NAI
realm namespace will piggyback on the administration of the DNS
namespace.

NAI realm names are required to be unique and the rights to use a
given NAI realm for roaming purposes are obtained coincident with
acquiring the rights to use a particular fully qualified domain name
(FQDN). Those wishing to use an NAI realm name should first acquire
the rights to use the corresponding FQDN. Using an NAI realm without
ownership of the corresponding FQDN creates the possibility of
conflict and therefore is to be discouraged.

Note that the use of an FQDN as the realm name does not imply use of
the DNS for location of the authentication server or for
authentication routing. Since to date roaming has been implemented
on a relatively small scale, existing implementations typically
handle location of authentication servers within a domain and perform
authentication routing based on local knowledge expressed in proxy
configuration files. The implementations described in [1] have not
found a need for use of DNS for location of the authentication server
within a domain, although this can be accomplished via use of the DNS
SRV record, described in [6]. Similarly, existing implementations
have not found a need for dynamic routing protocols, or propagation
of global routing information. Note also that there is no
requirement that the NAI represent a valid email address.

7. Acknowledgements

Thanks to Glen Zorn of Microsoft for many useful discussions of
this problem space.

8. Authors' Addresses

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

Phone: 425-936-6605
EMail: bernarda@microsoft.com

Mark A. Beadles
WorldCom Advanced Networks
5000 Britton Rd.
Hilliard, OH 43026

Phone: 614-723-1941
EMail: mbeadles@wcom.net

9. Full Copyright Statement

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

070網路電話的牛肉在哪?!


蔡宜秀 2008/12/09 06:00:00
歷經多年延宕,強調可與公眾電信網路(PSTN)互通的070網路電話(VoIP)終於上個月(11月)由遠傳電信率先開通。


別於Skype及IPOX 070等網路電話,由國家傳播委員會(NCC)審議通過的070網路電話除有11個號碼(指070-BCDE-FGHI)外,由於070網路電話是走國際電信聯盟(ITU)的E.164通信編碼格式,因此可與同走E.164格式的公眾電信網路(PSTN)互通,如市話等。


070網路電話之於企業,究竟有何意義?可讓企業大幅降低通訊成本,抑或是其他?答案是,若070網路電話可與企業既有的網路電話(VoIP)互通,確實有助於企業降低通話費,畢竟,企業已部署的網路電話只能撥出(Out-bound)無法撥入(In-bound),而070網路電話則無此問題。


但若070網路電話業者欲以有助降低通訊成本一點吸引企業轉使用070網路電話,有其困難性,理由是,企業除得先整合070網路電話與企業內的VoIP PBX等外,還必需進一步向員工宣導與改變其使用習慣等,在這樣的狀況下,建議取得070網路電話執照的業者在祭出各項優惠通話費率之外,如070網路電話使用者可以極低費用撥接行動電話等,亦需要提供更多元的加值服務。


加值服務最為關鍵
為何加值服務對於070網路電話業者來說,極為重要?我想,這可從以下兩個層面來看:

第一,費率競爭將日趨激烈。為吸引企業客戶青睞,遠傳在推出070網路電話之後,即祭出可整合ADSL與MVPN行動服務、免費贈送遠傳070軟體電話,以及享網路閘道器(IP Gateway)免租金、免設定及安裝費等優惠的「遠傳070企業方案」,由這,不難預測,是方通訊等070網路電話業者為弭補晚入070網路電話市場一事,即可能提供更優惠的費資方案,如可與非E.164網路電話互通等。


第二,市場趨勢使然。從美國、日本、南韓、新加坡與香港等地的070網路電話(非每個國家都是以070為網路電話號碼的前綴碼,如下述的Yahoo!BB網路電話的前綴碼即為050)推動狀況來看,加值服務已成為E.164網路電話業者擴大業務範疇的關鍵作法,如日本的第一大網路電話業者Yahoo!BB為擴大事業版圖,繼推出隨選視訊(MOD)─BBTV後,還與微軟及日本電信(Japan Telecom)合作推出整合網路電話、電子郵件(E-mail)與即時通訊(IM)的整合通訊服務(UC)。


從上述兩件事情來看,雖然台灣的070網路電話才剛起步,但如欲以其他通訊業者做出市場區隔、提升市場佔有率,如Skype等,尤其是企業市場這塊,建議070網路電話業者加緊腳步規劃出夠誘人的加值服務包。


導入070網路電話前的兩三事
心動不如馬上行動?對070網路電話業者提出的通話費率方案心動的企業在行動前,得先仔細評估以下兩件事情:


第一,企業頻寬是否足夠承載員工接撥070網路電話。由於070網路電話可以支援撥出與撥入,為避免員工以070網路電話接聽客戶來電時因網路不穩而導致斷線等窘境發生,企業資訊人員得先確認既有網際網路頻寬可以支援。


第二,070網路電話業者的服務動能。雖然企業早就開始透過部署網路電話等方式進行通話節費,但因各企業所部署的網路電話等網通架構不一,因此,無論070網路電話業者提出多優惠的通話費率與加值服務方案,若是其無法提供專屬企業的技術支援服務,那麼,企業怎確定070網路電話可與既有的網通架構無礙介接。
舉例來說,雖然有不少業者提出,070網路電話就像是1條SIP Trunk,只要企業的IP交換機(IP PBX)、VoIP Gateway可支援SIP Trunk,即可向業者申請1個070號碼,將該號碼註冊到IP PBX上,即可完成互通與轉接整合......但誰都不曉得,事情是否真如業者所言,不會有任何「萬一」發生。


第三,回撥070網路電話的資費較高。在070網路電話業者所提出的眾多資費方案中,是以網內互打免費這點最吸引人,不過,對早已部署網路電話或即時通訊(IM)軟體的企業來說,網內互打免費的吸引力略顯不足,理由是,企業不可能要求上下游合作夥伴與客戶申請、使用同一家070網路電話,對以歐美等地為主要銷售市場的企業來說,尤甚如此,再加上以市話或行動回撥070網路電話的資費較高(雖然國家通訊傳播委員會已要求中華電信調降資費),即可能導致台灣的合作夥伴或客戶拒絕回撥070網路電話,若是這樣,企業又何必申請使用070網路電話。

Dec 3, 2008

How to calculate fragment size or fragment delay (FRF.12 or MLPPP)?

Serialization Delay = frame size (bits) / link bandwidth (bits per second [bps])

在QoS中我們可以利用LLQ(Low Latency Queueing)來提供VoIP封包低延遲(delay)及減少抖動(jitter)發生的情況。雖然VoIP封包總是傳送到software queue的前端,serialization delay(Layer 2 Frame encoded into Layer 1 Bits)的問題仍無可避免。一個大型封包可能正在hardware queue中使用FIFO。當VoIP封包被傳送至software queue的前端,在hardware transmit queue中的大型封包進行serialization時會導致VoIP封包必須等待一段較長的時間之後才能被傳送出去。

這時我們就可以使用fragment將大型封包切割成許多的小型封包,同時搭配interleaving的方式,將VoIP封包穿插在這些被切割之後的小型封包之間,藉此減少抖動(jitter)情況的發生。

當你在某鏈結上要設置適合的fragment size(切割尺寸)時,比較常見的目標是使得最大serialization delay維持在10~15ms之間。

假設實體連接埠線路速度為512Kpbs,所需要的serialization delay不應該超過10ms(記住,fragment size是根據實體連接埠線路速度而計算出來的!),fragment size(切割尺寸)必須設定為:
512000(bps)/8*0.01(sec)=640 bytes

我們可以使用下列指令來進行設置:
Router(config-if)# ppp multilink fragment 640
or
Router(config-map-class)# frame-relay fragment 640



如果在Cisco IOS CLI上如果今天要使用的是fragment delay數值(milliseconds),那就必須再乘上所使用的interface頻寬(假設MLPPP virtual-template上的頻寬為384Kbps)。

因此,我們使用virtual-template interface上的頻寬(384Kpbs)並且調整delay來確保fragment size 符合實體介面速度(512Kpbs)。在此例中,有效延遲數值應該被設定為:
640*8/384 = 13ms (Fragment_Size/CIR*8)

我們可以使用下列指令來進行設置:
Router(config-if)# ppp multilink fragment delay 13
or
Router(config-map-class)# frame-relay fragment delay 13

IP RTP Priority

在還沒有發明LLQ(Low Latency Queue)之前,我們要在interface上調整Voice RTP的保留頻寬,只能使用

Router(config-if)# ip rtp priority starting-rtp-port-number port-number-range bandwidth

設定完成之後,我們可以使用以下的指令來檢查我們的配置:

Router# show queue interface-type interface-number

以下是Cisco官網上的說明:

Feature Overview
The IP RTP Priority feature provides a strict priority queueing scheme for delay-sensitive data such as voice. Voice traffic can be identified by its Real-Time Transport Protocol (RTP) port numbers and classified into a priority queue configured by the ip rtp priority command. The result is that voice is serviced as strict priority in preference to other nonvoice traffic.

The IP RTP Priority feature extends and improves on the functionality offered by the ip rtp reserve command by allowing you to specify a range of User Datagram Protocol (UDP)/RTP ports whose traffic is guaranteed strict priority service over any other queues or classes using the same output interface. Strict priority means that if packets exist in the priority queue, they are dequeued and sent first—that is, before packets in other queues are dequeued. We recommend that you use the ip rtp priority command instead of the ip rtp reserve command for voice configurations.

The IP RTP Priority feature does not require that you know the port of a voice call. Rather, the feature gives you the ability to identify a range of ports whose traffic is put into the priority queue. Moreover, you can specify the entire voice port range—16384 to 32767—to ensure that all voice traffic is given strict priority service. IP RTP Priority is especially useful on slow-speed links whose speed is less than 1.544 Mbps.

This feature can be used in conjunction with either Weighted Fair Queueing (WFQ) or Class-Based WFQ (CBWFQ) on the same outgoing interface. In either case, traffic matching the range of ports specified for the priority queue is guaranteed strict priority over other CBWFQ classes or WFQ flows; packets in the priority queue are always serviced first.
  • When used in conjunction with WFQ, the ip rtp priority command provides strict priority to voice, and WFQ scheduling is applied to the remaining queues.
  • When used in conjunction with CBWFQ, the ip rtp priority command provides strict priority to voice. CBWFQ can be used to set up classes for other types of traffic (such as Systems Network Architecture [SNA]) that needs dedicated bandwidth and needs to be treated better than best effort and not as strict priority; the nonvoice traffic is serviced fairly based on the weights assigned to the enqueued packets. CBWFQ can also support flow-based WFQ within the default CBWFQ class if so configured.

Because voice packets are small in size and the interface also can have large packets going out, the Link Fragmentation and Interleaving (LFI) feature should also be configured on lower speed interfaces. When you enable LFI, the large data packets are broken up so that the small voice packets can be interleaved between the data fragments that make up a large data packet. LFI prevents a voice packet from needing to wait until a large packet is sent. Instead, the voice packet can be sent in a shorter amount of time.


How IP RTP Priority Works
If you want to understand its behavior and properly use the IP RTP Priority feature, it is important to consider its admission control and policing characteristics. When you use the ip rtp priority command to configure the priority queue for voice, you specify a strict bandwidth limitation. This amount of bandwidth is guaranteed to voice traffic enqueued in the priority queue. (This is the case whether you use the IP RTP Priority feature with CBWFQ or WFQ.)

IP RTP Priority closely polices use of bandwidth for the priority queue, ensuring that the allocated amount is not exceeded in the event of congestion. In fact, IP RTP Priority polices the flow every second. IP RTP Priority prohibits transmission of additional packets once the allocated bandwidth is consumed. If it discovers that the configured amount of bandwidth is exceeded, IP RTP Priority drops packets, an event that is poorly tolerated by voice traffic. (Enable debugging to watch for this condition.) Close policing allows for fair treatment of other data packets enqueued in other CBWFQ or WFQ queues. To avoid packet drop, be certain to allocate to the priority queue the most optimum amount of bandwidth, taking into consideration the type of codec used and interface characteristics. IP RTP Priority will not allow traffic beyond the allocated amount.


It is always safest to allocate to the priority queue slightly more than the known required amount of bandwidth. For example, suppose you allocated 24 kbps bandwidth, the standard amount required for voice transmission, to the priority queue. This allocation seems safe because transmission of voice packets occurs at a constant bit rate. However, because the network and the router or switch can use some of the bandwidth and introduce jitter and delay, allocating slightly more than the required amount of bandwidth (such as 25 kbps) ensures constancy and availability.


The IP RTP Priority admission control policy takes RTP header compression into account. Therefore, while configuring the bandwidth parameter of the ip rtp priority command you only need to configure for the bandwidth of the compressed call. For example, if a G.729 voice call requires 24 kbps uncompressed bandwidth (not including Layer 2 payload) but only 12 kbps compressed bandwidth, you only need to configure a bandwidth of 12 kbps. You need to allocate enough bandwidth for all calls if there will be more than one call.


The sum of all bandwidth allocation for voice and data flows on the interface cannot exceed 75 percent of the total available bandwidth. Bandwidth allocation for voice packets takes into account the payload plus the IP, RTP, and UDP headers, but again, not the Layer 2 header. Allowing 25 percent bandwidth for other overhead is conservative and safe. On a PPP link, for instance, overhead for Layer 2 headers assumes 4 kbps. The amount of configurable bandwidth for IP RTP Priority can be changed using the max-reserved-bandwidth command on the interface.


If you know how much bandwidth is required for additional overhead on a link, under aggressive circumstances in which you want to give voice traffic as much bandwidth as possible, you can override the 75 percent maximum allocation for the bandwidth sum allocated to all classes or flows by using the max-reserved-bandwidth command. If you want to override the fixed amount of bandwidth, exercise caution and ensure that you allow enough remaining bandwidth to support best-effort and control traffic, and Layer 2 overhead.


As another alternative, if the importance of voice traffic far exceeds that of data, you can allocate most of the 75 percent bandwidth used for flows and classes to the voice priority queue. Unused bandwidth at any given point will be made available to the other flows or classes.


CBWFQ Configuration
The following example first defines a CBWFQ configuration and then reserves a strict priority queue:

! The following commands define a class map:
router(config)# class-map class1
router(config-cmap)# match access-group 101
router(config-cmap)# exit


! The following commands create and attach a policy map:
router(config)# policy-map policy1
router(config-pmap)# class class1
router(config-pmap-c)# bandwidth 3000
router(config-pmap-c)# queue-limit 30
router(config-pmap-c)# random-detect
router(config-pmap-c)# random-detect precedence 0 32 256 100
router(config-pmap-c)# exit
router(config)# interface Serial1
router(config-if)# service-policy output policy1


! The following command reserves a strict priority queue:
router(config-if)# ip rtp priority 16384 16383 40

The queue-limit and random-detect commands are optional commands for CBWFQ configurations. The queue-limit command is used for configuring tail drop limits for a class queue. The random-detect command is used for configuring RED drop limits for a class queue, similar to the random-detect command available on an interface.

Virtual Template Configuration
The following example configures a strict priority queue in a virtual template configuration with CBWFQ. The max-reserved-bandwidth command changes the maximum reserved bandwidth allocated for CBWFQ and IP RTP Priority from the default (75 percent) to 80 percent.

router(config)# multilink virtual-template 1
router(config)# interface virtual-template 1
router(config-if)# ip address 172.16.1.1 255.255.255.0
router(config-if)# no ip directed-broadcast
router(config-if)# ip rtp priority 16384 16383 25
router(config-if)# service-policy output policy1
router(config-if)# ppp multilink
router(config-if)# ppp multilink fragment-delay 20
router(config-if)# ppp multilink interleave
router(config-if)# max-reserved-bandwidth 80
router(config-if)# end
router(config)# interface Serial0/1
router(config-if)# bandwidth 64
router(config-if)# ip address 1.1.1.2 255.255.255.0
router(config-if)# no ip directed-broadcast
router(config-if)# encapsulation ppp
router(config-if)# ppp multilink
router(config-if)# end


Multilink Bundle Configuration
The following example configures a strict priority queue in a multilink bundle configuration with WFQ. The advantage to using multilink bundles is that you can specify different ip rtp priority parameters on different interfaces.

The following commands create multilink bundle 1, which is configured for a maximum ip rtp priority bandwidth of 200 kbps. The max-reserved-bandwidth command changes the maximum reserved bandwidth allocated for WFQ and IP RTP Priority.

router(config)# interface multilink 1
router(config-if)# ip address 172.17.254.161 255.255.255.248
router(config-if)# no ip directed-broadcast
router(config-if)# ip rtp priority 16384 16383 200
router(config-if)# no ip mroute-cache
router(config-if)# fair-queue 64 256 0
router(config-if)# ppp multilink
router(config-if)# ppp multilink fragment-delay 20
router(config-if)# ppp multilink interleave
router(config-if)# max-reserved-bandwidth 80


The following commands create multilink bundle 2, which is configured for a maximum ip rtp priority bandwidth of 100 kbps:

router(config)# interface multilink 2
router(config-if)# ip address 172.17.254.162 255.255.255.248
router(config-if)# no ip directed-broadcast
router(config-if)# ip rtp priority 16384 16383 100
router(config-if)# no ip mroute-cache
router(config-if)# fair-queue 64 256 0
router(config-if)# ppp multilink
router(config-if)# ppp multilink fragment-delay 20
router(config-if)# ppp multilink interleave


In the next part of the example, the multilink-group command configures serial interface 2/0 to be part of multilink bundle 1.

router(config)# interface serial 2/0
router(config-if)# bandwidth 256
router(config-if)# no ip address
router(config-if)# no ip directed-broadcast
router(config-if)# encapsulation ppp
router(config-if)# no ip mroute-cache
router(config-if)# no fair-queue
router(config-if)# clockrate 256000
router(config-if)# ppp multilink
router(config-if)# multilink-group 1


Next, serial interface 2/1 is configured to be part of multilink bundle 2.

router(config)# interface serial 2/1
router(config-if)# bandwidth 128
router(config-if)# no ip address
router(config-if)# no ip directed-broadcast
router(config-if)# encapsulation ppp
router(config-if)# no ip mroute-cache
router(config-if)# no fair-queue
router(config-if)# clockrate 128000
router(config-if)# ppp multilink
router(config-if)# multilink-group 2